Resumen

  • id-token: write permite que un job o workflow de GitHub Actions solicite un JWT OIDC; GitHub aclara que ese ajuste no otorga permiso de escritura sobre recursos externos.
  • El proveedor cloud evalúa por separado sus condiciones de confianza y puede intercambiar el JWT por un token de acceso temporal. La decisión de un recurso es otra superficie de control.
  • Una afirmación de autorización cloud necesita unir revisión y claims acotados del workflow, política de confianza, intercambio y sesión, permiso efectivo, decisión del recurso y observación fechada del destino.

La frase «el pipeline tiene acceso cloud mediante OIDC» puede resumir una implementación útil. Se vuelve imprecisa si convierte varias decisiones separadas en un veredicto único. GitHub puede emitir un token de identidad a un job habilitado para pedirlo. Un proveedor puede haber configurado confianza en el emisor de GitHub y comprobar determinados claims. Un intercambio exitoso puede dar un acceso de corta duración a ese job. Después, el recurso puede evaluar dicho acceso contra un rol, una política de recurso, límites de sesión, contexto de petición, controles de organización o una denegación explícita.

No hay un solo responsable ni un solo registro que pruebe toda la cadena.

GitHub delimita el primer paso. id-token: write permite pedir y usar un JWT OIDC; no permite modificar otros recursos. Ver ese permiso en YAML prueba únicamente que el job podía solicitar un token. No prueba que lo solicitara, qué audiencia pidió, qué claims devolvió GitHub, que una nube los aceptara ni que una acción llegara a ejecutarse. Un token emitido es evidencia de identidad acotada, no una decisión de autorización cloud.

La relación de confianza del proveedor es un control distinto. GitHub explica que el proveedor valida los claims y, si tiene éxito, proporciona un token de acceso disponible para el job. Allí una condición puede examinar sujeto, audiencia, identidad de repositorio o referencia de workflow reutilizable. Un JWT válido puede no coincidir con la condición. Una política puede aceptar más o menos de lo que un responsable de release supone. Incluso una sesión emitida puede tener permisos distintos de los necesarios para una operación, y el recurso puede denegarla después mediante su propia política.

La guía para AWS muestra el cambio de autoridad: hay que configurar una relación de confianza y GitHub recomienda evaluar el claim sub en la política de confianza del rol. El sub no es una sesión de rol. La sesión no es una lista completa de permisos efectivos en un contexto concreto. Los workflows reutilizables añaden otra unión: GitHub puede incluir job_workflow_ref, pero la posibilidad de usar claims personalizados depende del proveedor. El nombre de un workflow no prueba qué condición evaluó una nube.

Daniel Kade propone un recibo de siete partes: la revisión, disparador, job y permiso OIDC; petición y claims limitados sin exponer un token vivo; revisión de proveedor de identidad y política de confianza; intercambio y sesión o rol; contexto de permiso efectivo; decisión y registro del recurso; y observación independiente y fechada del destino. Los identificadores sensibles pueden protegerse. Lo que no debe hacerse es rellenar las uniones ausentes con la palabra «federado».

Fuentes

  1. GitHub Docs — Configuring OpenID Connect in cloud providers
  2. GitHub Docs — OpenID Connect reference
  3. GitHub Docs — Configuring OpenID Connect in Amazon Web Services
  4. GitHub Docs — Using OpenID Connect with reusable workflows