Identidades de carga y federación OIDC

Una carga de trabajo (un job de CI, un contenedor, una función) prueba quién es ante la nube. La forma antigua es una clave de acceso guardada como secreto: dura meses, se copia, se filtra en un registro y hay que rotarla. La forma federada usa un token de identidad que el proveedor de CI emite para cada ejecución, firmado y de vida corta, y que la nube canjea por credenciales temporales.

El token trae reclamaciones: quién lo emitió (iss), para qué servicio (aud) y de quién se trata (sub, el sujeto, que suele codificar el proyecto y la rama o el entorno). Lo que la nube verifica de esas reclamaciones es lo que define el riesgo.

En AWS la condición de la confianza compara las reclamaciones del token. Si solo se comprueba aud, cualquier token emitido por ese proveedor para ese destinatario sirve, sea de la rama principal, de otro proyecto o de una ejecución de pruebas. La condición sobre sub es la que dice qué ejecución concreta puede asumir el rol.

Abre los tres roles de federacion/aws/ y compara las condiciones de cada uno.

En Azure, una credencial federada de una aplicación fija el emisor, el sujeto y la audiencia que acepta. El sujeto debe ser tan específico como el despliegue que se quiere permitir. Una solicitud de cambio la puede abrir cualquiera que tenga acceso de escritura al repositorio, a veces con código aún sin revisar; dar a ese sujeto acceso a producción es abrir la puerta antes de la revisión.

Revisa federacion/azure/credenciales-federadas.txt y fíjate en el sujeto de cada una frente a su nombre.

Una buena forma de auditar una confianza es probarla con un caso: tomas un token y compruebas, rol por rol, si cumpliría todas las condiciones. Una condición con comodín (StringLike con un asterisco) acepta lo que case con el patrón; una de igualdad exacta (StringEquals) solo acepta ese valor.

El archivo federacion/token-del-ejemplo.txt trae las reclamaciones de una ejecución de pruebas. No hace falta ejecutar nada: compara cada reclamación con las condiciones de los tres roles.

En Google Cloud, un pool de identidades de carga tiene proveedores que reciben tokens de un emisor externo. Cada proveedor puede llevar una condición de atributo que descarta los tokens que no cumplan. Sin ella, cualquier identidad que el emisor firme entra al pool, y de ahí a los permisos que se concedan sobre el pool.

En federacion/gcp/proveedores-del-pool.txt hay dos proveedores. Uno es de un contratista y no tiene condición.