Introducción
Si audita los almacenes de secretos de la mayoría de las plataformas CI/CD hoy en día, encontrará un cementerio de credenciales de larga duración: claves de acceso de AWS creadas hace años, claves JSON de cuentas de servicio de GCP compartidas entre docenas de pipelines, Personal Access Tokens de GitHub con alcances amplios y contraseñas de bases de datos que nunca han sido rotadas. Estos secretos estáticos son el vector de ataque más común en las vulneraciones de CI/CD.
La razón es directa. Una credencial de larga duración es una llave maestra. Una vez que un atacante la obtiene — a través de un log filtrado, una dependencia comprometida, un almacén de secretos mal configurado o un ataque a la cadena de suministro de la propia plataforma CI — tiene acceso persistente, a menudo con privilegios excesivos, a la infraestructura de producción. No hay un reloj de expiración en marcha. No hay una revocación automática. El atacante puede usar esa credencial desde cualquier IP, cualquier contexto, durante todo el tiempo que le tome al equipo defensor darse cuenta.
Workload Identity Federation cambia la ecuación por completo. En lugar de inyectar secretos estáticos en las ejecuciones del pipeline, la propia plataforma CI se convierte en un proveedor de identidad. Cada ejecución del pipeline recibe un token de corta duración, firmado criptográficamente, que demuestra qué se está ejecutando (qué repositorio, qué rama, qué workflow, qué entorno). Los proveedores de nube validan ese token y emiten credenciales temporales con el alcance exacto de los permisos necesarios — credenciales que expiran en minutos, no en meses.
Esta guía recorre el problema en detalle, explica cómo funciona Workload Identity Federation a nivel de protocolo, proporciona ejemplos funcionales completos para GitHub Actions y GitLab CI en AWS, GCP y Azure, cubre patrones avanzados e incluye una guía práctica de migración para equipos listos para eliminar sus secretos de larga duración.
El Problema con las Credenciales de Larga Duración
Antes de profundizar en la solución, vale la pena entender exactamente por qué las credenciales de larga duración son tan peligrosas en contextos de CI/CD específicamente — no solo en general.
Sin Expiración ni Rotación Automática
Una clave de acceso de AWS IAM, una vez creada, es válida para siempre a menos que se revoque explícitamente. Una clave JSON de cuenta de servicio de GCP no tiene fecha de expiración. Un PAT de GitHub puede configurarse para no expirar nunca. En la práctica, la mayoría de los equipos crean estas credenciales una vez durante la configuración inicial y nunca las vuelven a tocar. La edad media de un secreto de CI/CD en la mayoría de las organizaciones se mide en años.
Esto significa que incluso si una credencial se filtró hace seis meses, sigue siendo válida hoy. Los atacantes lo saben y escanean rutinariamente repositorios públicos, imágenes Docker y logs de CI en busca de credenciales que pueden haberse expuesto en cualquier momento de la historia.
Amplio Radio de Impacto
Las credenciales de CI/CD tienden a tener privilegios excesivos porque necesitan realizar tareas diversas: construir contenedores, hacer push a registros, desplegar infraestructura, ejecutar migraciones de bases de datos, invalidar cachés. En lugar de crear credenciales con alcance limitado para cada tarea, los equipos típicamente crean una credencial poderosa y la reutilizan en todas partes. Una sola clave filtrada puede otorgar acceso a bases de datos de producción, infraestructura en la nube y pipelines de despliegue simultáneamente.
Difícil de Auditar
Cuando la misma clave de cuenta de servicio se usa en 50 repositorios, 200 pipelines y tres entornos, se vuelve casi imposible responder preguntas básicas de seguridad:
- ¿Qué pipeline hizo esta llamada API a producción a las 3 AM?
- ¿Se usó esta credencial desde un runner CI autorizado o desde la máquina de un atacante?
- ¿Qué repositorios aún dependen de esta clave si necesitamos rotarla?
Las credenciales de larga duración no proporcionan información contextual sobre quién o qué las está usando. Cada uso se ve idéntico en los logs de auditoría.
Almacenadas en los Almacenes de Secretos de la Plataforma CI
Las plataformas CI como GitHub Actions, GitLab CI y Jenkins almacenan secretos en sus propias bóvedas. Estos son objetivos valiosos. Una sola brecha en el almacén de secretos de la plataforma CI expone cada credencial de cada proyecto. La brecha de CircleCI en enero de 2023 es un ejemplo de libro de texto: los atacantes comprometieron los sistemas internos de CircleCI y exfiltraron los secretos de los clientes, obligando a cada cliente de CircleCI a rotar cada secreto almacenado en la plataforma.
Brechas en el Mundo Real
El patrón se repite en toda la industria:
- Codecov (2021): Los atacantes modificaron el Codecov Bash Uploader para exfiltrar variables de entorno — incluidos secretos de CI/CD — de los pipelines de miles de clientes. Las credenciales de larga duración almacenadas como variables de entorno fueron enviadas a servidores controlados por los atacantes.
- CircleCI (2023): Un laptop comprometido de un empleado llevó a la exfiltración de secretos de clientes del almacenamiento de secretos de CircleCI. Se aconsejó a todos los clientes que rotaran todos los secretos inmediatamente.
- Travis CI (2021): Una vulnerabilidad expuso secretos de las compilaciones de repositorios públicos, incluyendo claves de AWS, tokens de GitHub y credenciales de Docker Hub.
- Uber (2022): Un atacante obtuvo acceso a sistemas internos a través de un pipeline CI/CD comprometido, aprovechando credenciales hardcodeadas encontradas en scripts de PowerShell.
En cada caso, la causa raíz fue la misma: credenciales de larga duración almacenadas en entornos CI proporcionaron acceso persistente y con privilegios excesivos que los atacantes pudieron explotar mucho después del compromiso inicial.
Cómo Funciona Workload Identity Federation
Workload Identity Federation reemplaza las credenciales estáticas con un flujo de autenticación dinámico basado en tokens, construido sobre OpenID Connect (OIDC). Así es como funciona a nivel de protocolo.
El Flujo OIDC
El flujo de autenticación involucra tres partes: la plataforma CI (proveedor de identidad), el proveedor de nube (parte confiante) y la ejecución del pipeline (workload).
- Emisión del token: Cuando un job del pipeline comienza, la plataforma CI genera un JWT (JSON Web Token) firmado para esa ejecución específica. Este token contiene claims sobre el workload: qué repositorio lo activó, qué rama, qué workflow, qué actor y el entorno.
- Intercambio del token: El pipeline presenta este JWT al Security Token Service (STS) del proveedor de nube y solicita credenciales temporales.
- Validación: El proveedor de nube obtiene el documento de descubrimiento OIDC público de la plataforma CI y las claves de firma. Valida la firma del JWT, verifica que el token no haya expirado y comprueba que los claims coincidan con la política de confianza configurada.
- Emisión de credenciales: Si la validación es exitosa, el proveedor de nube emite credenciales de corta duración (típicamente válidas por 1 hora o menos) con el alcance del rol IAM o cuenta de servicio configurado en la política de confianza.
El contenido completo de este artículo continúa con secciones detalladas sobre la relación de confianza, el alcance basado en claims, la configuración de OIDC Federation en GitHub Actions y GitLab CI con AWS, GCP y Azure, patrones avanzados incluyendo encadenamiento de OIDC con Vault, identidades por entorno, Kubernetes Workload Identity, patrones de acceso entre cuentas, combinación con Terraform, consideraciones de seguridad, y una guía completa de migración desde credenciales de larga duración a credenciales de corta duración.
Conclusión
Workload Identity Federation es el cambio de mayor impacto que la mayoría de los equipos pueden hacer en su postura de seguridad CI/CD. Elimina el vector de ataque más común — las credenciales de larga duración — y lo reemplaza con un sistema que es más seguro por defecto: de corta duración, con alcance automático, auditable y resistente al movimiento lateral.
El camino de migración es directo. Comience con un pipeline y un proveedor de nube. Configure la relación de confianza OIDC, actualice el workflow para usar autenticación federada, valide que funciona y pase al siguiente pipeline. En unas pocas semanas, puede eliminar cada credencial de nube de larga duración de su plataforma CI/CD.
No hay razón para mantener credenciales de larga duración en sus pipelines CI/CD. El riesgo es alto, el costo de migración es bajo y la mejora de seguridad es inmediata. Comience hoy.
