Identidades federadas para cargas de trabajo cloud
Reduce secretos persistentes en CI/CD y servicios cloud con identidades federadas, confianza OIDC restringida, mínimo privilegio y pruebas de revocación.
2 min de lectura
En este artículo
Sustituye credenciales duraderas cuando el entorno lo permita
Pipelines, contenedores, scripts y servicios necesitan identidad para acceder a recursos. Un secreto de cliente guardado durante meses puede filtrarse, quedar olvidado o caducar y detener una tarea. La federación permite que una carga de trabajo presente un token de un proveedor de identidad de confianza y lo intercambie por un token de acceso del proveedor cloud, sin almacenar esa credencial de larga duración en el pipeline.
El mecanismo y sus límites dependen de cada plataforma. En Azure, por ejemplo, Microsoft Entra puede confiar en emisores externos para escenarios como GitHub Actions y Kubernetes. En otros entornos se usan mecanismos equivalentes, como identidades administradas o federación OIDC. La federación no elimina la necesidad de controlar permisos y relaciones de confianza.
Diseña una confianza estrecha
Para cada integración define:
- Emisor: el proveedor que firma el token, por ejemplo la plataforma de CI.
- Sujeto: el repositorio, rama, entorno o identidad exacta que puede autenticarse.
- Audiencia: el servicio destinatario previsto.
- Permisos: operaciones mínimas necesarias, limitadas a recursos concretos.
- Propietario: equipo responsable de mantener y revisar la confianza.
Evita comodines amplios que permitan a cualquier rama, repositorio o flujo obtener credenciales de producción. Separa desarrollo, pruebas y producción. Protege además la configuración que puede modificar el workflow: si un atacante puede cambiar el código autorizado, también podría aprovechar la confianza existente.
Migración por etapas
- Inventaría secretos y certificados usados por automatizaciones; registra dónde se consumen y cuándo caducan.
- Escoge un pipeline de bajo riesgo y reproduce el acceso con identidad federada en un entorno no productivo.
- Valida emisor, sujeto, audiencia, permisos y registros de acceso. Prueba deliberadamente un sujeto no autorizado.
- Promueve el patrón a producción con revisión de cambios, propietario y alertas de autenticaciones inesperadas.
- Revoca la credencial anterior solo cuando la nueva ruta está verificada y existe un plan de reversión.
- Mantén inventario de identidades, permisos, última actividad y proceso de baja de repositorios o cargas.
Si una integración no admite federación, usa una credencial administrada en una bóveda, con alcance limitado, rotación y fecha de retirada planificada. No copies el secreto a logs ni a artefactos del pipeline.
Evidencias que conviene conservar
Guarda la configuración aprobada de la relación de confianza, las políticas de permisos, el resultado de las pruebas positivas y negativas, los registros de emisión de tokens y la fecha de revisión. Comprueba también qué ocurre si se elimina la rama, el repositorio o el proveedor emisor.
La documentación de Microsoft sobre federación de identidades de cargas describe el intercambio de tokens y las coincidencias sensibles a mayúsculas de emisor, sujeto y audiencia. Adapta esos detalles al producto que uses y a sus cambios de versión.
Consulta los guardarraíles cloud con policy as code para encajar estas identidades en políticas de plataforma.