Identidades federadas para cargas de trabajo cloud

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#

1. Inventaría secretos y certificados usados por automatizaciones; registra dónde se consumen y cuándo caducan.
2. Escoge un pipeline de bajo riesgo y reproduce el acceso con identidad federada en un entorno no productivo.
3. Valida emisor, sujeto, audiencia, permisos y registros de acceso. Prueba deliberadamente un sujeto no autorizado.
4. Promueve el patrón a producción con revisión de cambios, propietario y alertas de autenticaciones inesperadas.
5. Revoca la credencial anterior solo cuando la nueva ruta está verificada y existe un plan de reversión.
6. 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.

Referencias#

• Microsoft Entra: federación de identidades para cargas de trabajo
• Microsoft: consideraciones para credenciales federadas