Resumen ejecutivo
Okta Privileged Access (OPA) Workload Identity for Automation se integra con Google Cloud Platform (GCP) mediante el intercambio de tokens web JSON (JWT) OIDC firmados por la plataforma por certificados SSH efímeros y de corta duración. Una máquina virtual de ejecución automatizada consulta su servidor de metadatos local de GCP para obtener un JWT firmado por Google, lo envía a OPA a través de la CLI de sft para autenticarse y recibe un certificado SSH basado en el tiempo para acceder a los servidores de destino, eliminando así las claves SSH estáticas, los tokens de API y los archivos JSON de cuentas de servicio.
Todos los ingenieros de automatización se han enfrentado al mismo momento incómodo: necesitas que tu secuencia de comandos se conecte a un servidor, así que generas una credencial, la pegas en un archivo de configuración y sigues adelante. Semanas después, esa credencial está en tres archivos de configuración, dos pipelines de CI/CD y un mensaje de Slack que alguien envió para “probar algo rápidamente”. Nadie sabe cuáles siguen activas. Nadie quiere ser quien interrumpa la producción al rotarlas.
En esta entrada del blog, explicamos una solución completa y funcional: usar Okta Privileged Access (OPA) Workload Identity para la automatización con Google Cloud Platform (GCP) para permitir que un script de automatización se conecte mediante Secure Shell (SSH) a un servidor de destino sin almacenar ninguna credencial en el disco.
Cómo las identidades de carga de trabajo de OPA y GCP eliminan las credenciales estáticas
Objetivo principal: Eliminar las credenciales estáticas (claves API, claves SSH estáticas y archivos JSON de cuentas de servicio) en el acceso automatizado a servidores mediante el uso de pruebas de identidad firmadas por la plataforma.
Cero credenciales almacenadas: No hay secretos que residan en el disco, en los archivos de configuración ni en las variables de CI/CD.
Certificados efímeros de corta duración: Emisión de certificados SSH válidos durante 15 minutos, eliminando el riesgo operativo de rotación.
Validación criptográfica de extremo a extremo: Okta Privileged Access, que actúa como intermediario de confianza para validar los tokens web JSON (JWT) emitidos por GCP.
Registro de auditoría automatizado: Trazabilidad completa de la identidad en todas las actividades de intercambio de tokens y sesiones SSH en el Okta System Log.
El problema: las credenciales estáticas representan una deuda de seguridad, no características de infraestructura.
Cuando una tarea automatizada (un manual de estrategias de Ansible, una secuencia de comandos de despliegue o un ejecutor de CI/CD) necesita acceder a un recurso privilegiado, requiere una forma de demostrar su identidad. El método tradicional consiste en proporcionarle una credencial estática: una clave de API, una clave privada SSH o un archivo JSON de cuenta de servicio. Esa credencial se almacena en algún lugar, y ese lugar se convierte en un objetivo.
Las consecuencias se desarrollan de forma predecible:
Las credenciales dejan de ser útiles para su propósito original: una clave de cuenta de servicio creada para una tarea de implementación puntual sigue siendo válida durante años. El ingeniero que lo creó se marcha. La clave se queda. Nadie lo audita. Con el tiempo, acumula permisos porque es más fácil añadir acceso que investigar qué se puede eliminar sin riesgo. Estas son las “credenciales zombi” que permanecen en su entorno mucho después de que la carga de trabajo que las necesitaba haya desaparecido.
La rotación se convierte en un simulacro de crisis: cuando una credencial está insertada en docenas de pipelines y archivos de configuración, rotarla implica encontrar primero todas las referencias. Los equipos descubren las referencias observando cómo se rompen las cosas después de la rotación. Esto no es una estrategia de rotación; es una interrupción controlada.
El problema de fondo es arquitectónico: las credenciales estáticas son un modelo de identidad diseñado para humanos, no para máquinas. Una persona puede cambiar su contraseña y recordar la nueva. Una máquina solo necesita saber: “¿Soy quien digo ser?”, y una plataforma en la nube puede responder a esa pregunta criptográficamente, sin almacenar ningún secreto.
La solución: tokens de corta duración, seguridad permanente
Okta Privileged Access Workload Identity for Automation resuelve el problema del “secreto cero”, que consiste en necesitar una clave inicial para obtener otras credenciales seguras, al reemplazar las credenciales estáticas con pruebas de identidad firmadas por la plataforma.
La conclusión es sencilla: una máquina virtual (VM) de GCP ya tiene una identidad criptográfica. Cuando se asocia una cuenta de servicio a una máquina virtual, GCP puede emitir un JWT firmado con la clave privada de Google que, en efecto, dice: "Yo soy esta máquina virtual, que se ejecuta con esta cuenta de servicio, y se me ha emitido este token en este momento específico". Nadie puede falsificar ese token sin la clave privada de Google. Caduca automáticamente y no se puede reutilizar en otro sistema.
OPA actúa como intermediario de confianza. Se configura una sola vez para que diga: "Confío en los JWT firmados por Google para la cuenta de servicio X". A partir de ese momento, cualquier carga de trabajo que se ejecute con esa cuenta de servicio puede demostrar su identidad a OPA presentando su JWT emitido por GCP, y OPA lo intercambiará por un token de acceso de corta duración. Ese token se utiliza posteriormente para obtener un certificado SSH efímero, válido durante minutos, no durante años, para conectarse a un servidor de destino.
Esto no supone un cambio en el funcionamiento de SSH. Se trata de un cambio en la forma en que se establece la identidad antes de que comience SSH.
Arquitectura del sistema y mapeo de componentes
El flujo de trabajo de autenticación se basa en un patrón de diseño de intermediario de confianza en el que OPA valida las declaraciones de identidad generadas criptográficamente por GCP.
| Componente | Función de seguridad | Ubicación |
|---|---|---|
servidor de metadatos de GCP | Extremo interno de GCP que emite JWT firmados a cualquier máquina virtual a petición | Infraestructura de GCP (no su máquina virtual) |
Conexión de carga de trabajo | Objeto de configuración de OPA que define la confianza con GCP, especificando qué JWT aceptar y qué reclamos verificar | Panel de control de OPA |
Rol de carga de trabajo | Entidad de autorización OPA que asigna una identidad de carga de trabajo verificada a un nombre de usuario de Linux en los servidores de destino | Panel de control de OPA |
Política y regla | Define qué roles de carga de trabajo pueden acceder a qué servidores y mediante qué método. | Panel de control de OPA |
sft (cliente OPA) | Binario de interfaz de línea de comandos (CLI) que gestiona la autenticación de la carga de trabajo y la emisión de certificados SSH | Máquina virtual del runner |
sftd (agente OPA) | Demonio que registra el servidor de destino en OPA y configura SSH para que confíe en la autoridad de certificación de OPA | Máquina virtual de destino |
Arquitectura y flujo de autenticación
Fundamentos del diseño de seguridad
Enlace de público OPA: Se solicita el JWT de GCP con la URL OPA como público. Aunque sea interceptado, no podrá reproducirse en ningún otro sistema.
Verificación criptográfica: OPA obtiene las claves públicas de Google y verifica la firma JWT antes de emitir cualquier token. Un JWT falsificado o manipulado falla.
Caducidad estricta del tiempo de vida (TTL): El JWT de GCP caduca después de una hora. El token OPA permanece activo durante la duración de la sesión. El certificado SSH es válido durante el período definido. Nada persiste.
Cómo configurar una conexión de carga de trabajo de Okta Privileged Access para GCP
Requisitos y prerrequisitos
Cuenta de GCP: Debe tener la facturación habilitada y derechos de propietario o editor en el proyecto.
gcloud CLI: Instalado y autenticado en la estación de trabajo local.
Inquilino de OPA: Okta Privileged Access con licencia y accesible a través de la URL de su inquilino (por ejemplo, [https://YOUR-TEAM.pam.okta.com]).
Rol de administrador de DevOps: necesario en OPA para crear la conexión de la carga de trabajo.
Rol de administrador de seguridad: Necesario en OPA para activar la conexión, crear el rol de carga de trabajo y crear la política.
Paso 1: Crear la infraestructura de GCP
Ejecute estos comandos en su estación de trabajo local.
1.1 Crear proyecto y habilitar las API (GCP)
PROJECT_ID="SU_ID_PROYECTO"
ZONE="VM_LOCATION"
gcloud projects create "$PROJECT_ID" --name="YOUR_PROJECT_ID"
gcloud config set project "$PROJECT_ID"
gcloud services enable compute.googleapis.com iam.googleapis.com
11.2 Crear una cuenta de servicio para la máquina virtual de ejecución (GCP)
Esta cuenta de servicio es la identidad de la máquina del ejecutor. No se genera ningún archivo de clave; la conexión de la máquina virtual a esta cuenta en el momento de su creación constituye la prueba de identidad.
gcloud iam service-accounts create opa-runner-sa \
--display-name="Cuenta de servicio de OPA Runner" \
--project="$PROJECT_ID"
Correo electrónico de la cuenta de servicio generada: opa-runner-sa@<YOUR_PROJECT_ID>.iam.gserviceaccount.com
1.3 Crear instancias de ejecución y de computación de destino (GCP)
# Máquina virtual del ejecutor
gcloud compute instances create runner-vm \
--zone="$ZONE" \
--machine-type=e2-medium \
--image-family=ubuntu-2204-lts \
--image-project=ubuntu-os-cloud \
--service-account=opa-runner-sa@${PROJECT_ID}.iam.gserviceaccount.com \
--scopes=https://www.googleapis.com/auth/cloud-platform \
--tags=opa-runner
# Máquina virtual de destino
gcloud compute instances create target-vm \
--zone="$ZONE" \
--machine-type=e2-medium \
--image-family=ubuntu-2204-lts \
--image-project=ubuntu-os-cloud \
--tags=opa-target
Nota: Los servidores anteriores están configurados utilizando “machine-type”: “e2-medium ” y “image-family”: “ubuntu-2204-lts”. Puede elegir el tipo de máquina y la familia de imágenes que prefiera.
1.4 Configurar reglas de firewall (GCP)
# Permitir el acceso SSH interno del ejecutor al objetivo
gcloud compute firewall-rules create allow-runner-to-target \
--allow=tcp:22 \
--source-tags=opa-runner \
--target-tags=opa-target \
--project="$PROJECT_ID"
# Permitir HTTPS saliente desde el destino para la comunicación del agente OPA
gcloud compute firewall-rules create allow-egress-opa \
--direction=EGRESS \
--allow=tcp:443 \
--target-tags=opa-target \
--project="$PROJECT_ID"
Paso 2: Configurar la máquina virtual de ejecución (GCP)
La máquina virtual de ejecución solo requiere el binario sft. No está registrado para ningún usuario en OPA.
# Conéctese por SSH a la máquina virtual Runner
gcloud compute ssh runner-vm --zone="$ZONE"
# Instalar dependencias y el binario del cliente sft
# Instalar la clave del repositorio y agregar el repositorio PAM de Okta
curl -fsSL https://dist.scaleft.com/GPG-KEY-OktaPAM-2023 | gpg --dearmor | sudo tee /usr/share/keyrings/oktapam-2023-archive-keyring.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/oktapam-2023-archive-keyring.gpg] https://dist.scaleft.com/repos/deb $(lsb_release -cs) okta" | sudo tee /etc/apt/sources.list.d/oktapam-stable.list
# Actualizar el repositorio e instalar las herramientas del cliente SFT
sudo apt-get update && sudo apt-get install -y scaleft-client-tools
# Confirme el documento de identidad adjunto
curl -sf -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/email"
# Salida esperada: opa-runner-sa@opa-workload-demo.iam.gserviceaccount.com
salida
Paso 3: Configurar la máquina virtual de destino
3.1 Configurar el panel de control de OPA y generar el token de inscripción del servidor (Okta)
- Vaya al Panel de control de OPA → Administración de recursos → Gestión de recursos → Crear grupo de recursos → Crear proyecto o Grupo de recursos existente → Guardar
- Nombre: GCP_Servers_Proj
- Descripción: servidores de destino de GCP para la demo de carga de trabajo
- Navegue a GCP_Servers_Proj → Proyecto → Tipo de recurso - Servidores → Configuración → Token de inscripción → Ver → Crear token de inscripción
- Select OS: Linux
- Copie el token de inscripcióngenerado
3.2 Instalar e iniciar el agente sftd en la máquina virtual de destino (basada en GCP)
# Conéctese por SSH a la máquina virtual de destino
gcloud compute ssh target-vm --zone="$ZONE"
# Instalar dependencias y el demonio sftd
# Instalar la clave del repositorio y agregar el repositorio PAM de Okta
curl -fsSL https://dist.scaleft.com/GPG-KEY-OktaPAM-2023 | gpg --dearmor | sudo tee /usr/share/keyrings/oktapam-2023-archive-keyring.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/oktapam-2023-archive-keyring.gpg] https://dist.scaleft.com/repos/deb $(lsb_release -cs) okta" | sudo tee /etc/apt/sources.list.d/oktapam-stable.list
# Actualizar el repositorio e instalar las herramientas del servidor SFT
sudo apt-get update && sudo apt-get install -y scaleft-server-tools
# Guardar token de configuración de inscripción
sudo mkdir -p /var/lib/sftd
echo "SU TOKEN DE INSCRIPCIÓN AQUÍ" | sudo tee /var/lib/sftd/enrollment.token > /dev/null
# Restringir los permisos de archivo por motivos de seguridad
sudo chmod 600 /var/lib/sftd/enrollment.token
# Habilitar y verificar el estado del demonio
sudo systemctl enable sftd && sudo systemctl start sftd
dormir 5
sudo systemctl status sftd --no-pager
salida
3.3 Verificar la inscripción
Compruebe el panel de control de OPA para verificar que el estado muestre Inscrito: Panel de control de OPA → GCP_Servers_Proj → Servidores → target-vm (Estado: Inscrito) ✓
Paso 4: Configurar la conexión y los roles de la carga de trabajo OPA (Okta)
4.1 Crear y activar la conexión de carga de trabajo (administrador de DevOps y administrador de seguridad)
En el panel de control de OPA, vaya a Administración de DevOps → Conexiones de carga de trabajo → Crear conexión de carga de trabajo.
Seleccione Google Cloud Provider.
Introduzca los detalles del ID de cliente de la aplicación:
ID de cliente de la aplicación: Introduzca su ID de cliente de la aplicación (la cuenta de servicio creada en el paso anterior dentro del proyecto de GCP).
Marque Scope to Email (el correo electrónico se genera automáticamente)
Definir parámetros:
Nombre de la conexión: OKTA-OPA-Demo
Tiempo de vida del token: 3600 segundos
Reclamaciones requeridas: aud = [https://YOUR-TEAM.pam.okta.com] y iss = [https://accounts.google.com]
Haga clic en Crear conexión de carga de trabajo.
- Cambiar a administrador de DevOps: Abrir OKTA-OPA-Demo → Acciones → Activar.
4.2 Crear rol de carga de trabajo (Administrador de seguridad)
Vaya a Administración de seguridad → Roles de carga de trabajo → Crear rol de carga de trabajo.
Configurar atributos:
Nombre: OKTA-OPA-WR
Conexión de carga de trabajo: OKTA-OPA-Demo
Haga clic en Guardar rol de carga de trabajo. OPA asigna automáticamente un nombre de usuario de Linux (wl_okta_opa_wr).
4.3 Configurar políticas y reglas (administrador de seguridad)
Vaya a Administración de seguridad → Políticas → Crear política → Predeterminada
Nombre: Acceso al servidor NHI
Seleccionar grupos de recursos: Todos los grupos de recursos
En Agregar entidades principales, agregue el rol de carga de trabajo OKTA-OPA-WR.
En Agregar regla a la política, seleccione Regla del servidor:
Nombre dela regla: Permitir SSH para el rol de carga de trabajo
Tipo desesión: Sesión SSH del servidor
Cuentas: Habilitar Select cuentas por nombre → Destino: target-vm / root
Fundamental: NO habilite la autenticación multifactor ni Access Requests (los procesos sin interfaz gráfica no pueden responder a las indicaciones interactivas).
Haga clic en Guardar política y luego vaya a Acciones → Publicar.
Paso 5: verificar y probar la ejecución (basada en GCP)
5.1 Preparar la secuencia de comandos de automatización de la verificación
Vuelva a conectarse a runner-vm mediante SSH y prepare la secuencia de comandos de automatización:
gcloud compute ssh runner-vm --zone="$ZONE"
#!/bin/bash
#
# OPA Workload Identity demo secuencia de comandos
# Basado en: Okta Privileged Access - Introducción a las identidades de cargas de trabajo
#
# ─── ESTABLECER VARIABLES DE ENTORNO ──────────────────────────────────────────────
# público = su dirección OPA (debe coincidir con la declaración aud que OPA espera)
AUDIENCE="https://opa-gcp.pam.okta.com"
# URL de metadatos de GCP para obtener el JWT
METADATA_URL="http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=${AUDIENCE}&format=full"
# Equipo y dirección de OPA (sft lee estos datos del entorno)
export SFT_TEAM="opa-gcp"
export OPA_ADDR="https://demo-opa-gcp-demo.pam.okta.com"
# Los nombres deben coincidir exactamente con lo que creó en el panel de control de OPA
NOMBRE_DE_CONEXIÓN="okta-opa-demo"
ROLE_NAME="okta_opa_wr"
# Nombre del servidor de destino (tal como está registrado en OPA: el nombre de host)
TARGET_SERVER="target-vm"
# ─── PASO 1: OBTENER EL JWT DE IDENTIDAD DE GCP ───────────────────────────────────────────
echo "------------------------------------------------------------"
echo "PASO 1: Obtener JWT del servidor de metadatos de GCP"
echo "------------------------------------------------------------"
ID_TOKEN=$(curl -s -H "Metadata-Flavor: Google" "$METADATA_URL" | tr -d '\n\r')
if [[ "$ID_TOKEN" == eyJ* ]]; then
GCP_JWT="$ID_TOKEN"
# Decodificar y mostrar la ventana de validez
PAYLOAD=$(echo "$GCP_JWT" | cut -d. -f2 | base64 --decode 2>/dev/null)
EXP=$(echo "$PAYLOAD" | jq -r '.exp')
ISS=$(echo "$PAYLOAD" | jq -r '.iss')
EMAIL=$(echo "$PAYLOAD" | jq -r '.email')
NOW=$(date +%s)
DIFF=$((EXP - NOW))
echo "Emisor : $ISS"
echo "Correo electrónico: $EMAIL"
echo "público : $AUDIENCE"
echo ""
echo "VALOR DE GCP_JWT:"
echo "${GCP_JWT:0:80}... (truncado)"
echo ""
echo "Éxito: JWT obtenido."
echo "El token es válido durante otros $DIFF segundos (aproximadamente $((DIFF / 60)) minutos)."
demás
echo "ERROR: No se pudo obtener el JWT del servidor de metadatos."
echo "Asegúrese de que esta secuencia de comandos se esté ejecutando en una máquina virtual de GCP con una cuenta de servicio adjunta."
exit 1
fi
# Exportar para uso de sft
export GCP_TOKEN="$GCP_JWT"
eco "&"
# ─── PASO 2: INTERCAMBIAR JWT DE GCP POR TOKEN OPA ──────────────────────────────────
echo "------------------------------------------------------------"
echo "PASO 2: Autenticar la carga de trabajo con OPA para obtener OPA_TOKEN"
echo "------------------------------------------------------------"
echo "Ejecutando:"
echo "sft wl authenticate --team $SFT_TEAM \\"
echo " --connection $CONNECTION_NAME \\"
echo " --role-hint $ROLE_NAME \\"
echo " --jwt-env GCP_TOKEN"
eco "&"
OPA_TOKEN=$(sft wl authenticate \
--team "$SFT_TEAM" \
--conexión "$CONNECTION_NAME" \
--role-hint "$ROLE_NAME" \
--jwt-env GCP_TOKEN 2>&1 | tr -d '\n\r')
export OPA_TOKEN
if [[ "$OPA_TOKEN" == *"error"* ]] || [[ -z "$OPA_TOKEN" ]]; then
echo "ERROR: No se pudo obtener OPA_TOKEN."
echo "Detalle: $OPA_TOKEN"
echo ""
eco "Lista de verificación:"
echo " 1. ¿El estado de la conexión de carga de trabajo es ACTIVO (no Borrador)?"
echo " 2. ¿Coincide exactamente el nombre de conexión '$CONNECTION_NAME'?"
echo " 3. ¿La afirmación de la audiencia equivale a '$AUDIENCIA'?
echo " 4. ¿Coincide el reclamo de correo electrónico con la SA en la Conexión de carga de trabajo?"
exit 1
demás
echo "ÉXITO: OPA_TOKEN obtenido."
echo ""
echo "VALOR DE OPA_TOKEN:"
echo "${OPA_TOKEN:0:80}... (truncado)"
fi
eco "&"
# ─── PASO 3: UTILICE EL TOKEN OPA PARA ACCEDER AL SERVIDOR DE DESTINO ───────────────────────
echo "------------------------------------------------------------"
echo "PASO 3: Probando OPA_TOKEN con comandos sft"
echo "------------------------------------------------------------"
eco "&"
echo "3a. Listado de servidores a los que puede acceder esta carga de trabajo:"
sft list-servers
eco "&"
echo "3b. Conectando con $TARGET_SERVER como root y ejecutando un comando:"
sft ssh --command "hostname &&whoami &&date &&echo 'Acceso a la carga de trabajo EXITOSO'" \
"$TARGET_SERVER"
eco "&"
echo "------------------------------------------------------------"
echo "HECHO: demo de identidad de carga de trabajo completada."
echo "Compruebe el Okta System Log para ver si hay dos eventos:"
echo " 1. Intercambio de tokens (autenticación)"
echo " 2. Inicio de sesión SSH en el servidor"
echo "------------------------------------------------------------"
5.2 Ejecutar la secuencia de comandos de automatización
Ejecute la secuencia de comandos de automatización:
$ bash ~/opa-workload-test.sh
5.3 Resultados esperados y registros de auditoría
Tras la ejecución, la terminal devuelve:
El resultado muestra un flujo de autenticación SSH completo sin credenciales en tres pasos:
Recuperación de identidad de GCP: La máquina virtual ejecutora solicita un JWT firmado por la plataforma directamente desde los metadatos de Google Cloud (accounts.google.com) para la cuenta de servicio opa-runner-sa, lo que establece su identidad sin secretos almacenados.
Intercambio de SToken: El secuencia de comandos pasa el JWT de GCP a Okta Privileged Access a través de sft wl authenticate. OPA verifica la firma criptográfica de Google y emite un OPA_TOKEN asociado al rol okta_opa_wr.
Ejecución sin contraseña: OPA descubre la máquina virtual de destino y utiliza un certificado SSH efímero basado en el tiempo para ejecutar comandos en el servidor remoto.
La respuesta del servidor de destino muestra su nombre de host (target-vm), el usuario de carga de trabajo asignado por el sistema (wl_okta_opa_wr) y la marca de tiempo de ejecución. Esto confirma un acceso SSH completo y auditable, basado íntegramente en pruebas de plataforma en tiempo de ejecución en lugar de claves estáticas.
Auditabilidad y registros del sistema
Cada ciclo de autenticación genera eventos estructurados en el Okta System Log (Consola de administración de Okta → Informes → Registro del sistema).
Puede aplicar el siguiente filtro para ver los registros de sistema necesarios:
eventType eq "pam.user_creds.issue" and actor.type eq "WorkloadPrincipal"
Elimine los secretos estáticos de su infraestructura de automatización
Al sustituir las claves SSH permanentes y los archivos de cuenta de servicio por pruebas de identidad criptográficas firmadas por la plataforma, sus equipos de seguridad e ingeniería pueden lograr un acceso al servidor de Zero Trust sin interrumpir los pipelines de automatización. Okta Privileged Access simplifica la gestión de identidades y accesos no humanos al unir la federación dinámica de cargas de trabajo, la emisión de certificados efímeros y la auditabilidad integral en un único plano de control.
Descubra cómo Okta Privileged Access protege las identidades de máquinas y personas en todos sus recursos en la nube.
