OIDC en GitHub Actions: id-token, no keys estáticas en secrets

Cloud keys en secrets.AWS_SECRET_ACCESS_KEY viven para siempre hasta que alguien las rote. OIDC: el job pide id-token: write, GitHub firma un JWT, el cloud verifica sub (repo + environment) y entrega un rol corto.

No sustituye GITHUB_TOKEN permissions: eso es el token de GitHub. OIDC es el token hacia AWS/GCP/Azure. Tampoco es secretos en .env. El curso instalar un agente no cubre OIDC.

Receta

permissions:
  contents: read
  id-token: write

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123:role/gha
          aws-region: us-east-1

Sin id-token: write el action de OIDC falla. Un agente que pone permissions: write-all “para que funcione” abre de más.

El trust policy del rol debe acotar sub al repo (y al Environment si hay). Un sub: repo:* es un bypass.

Qué no hacer

• Dejar las keys estáticas “por si OIDC falla”. Borra las estáticas cuando OIDC pasa.
• Reusar el mismo rol para PRs de fork. Forks no deben asumir el rol de prod.
• Pegar el JWT en logs o en el prompt.

Receta AGENTS.md

Prefer OIDC (id-token: write + cloud role) over long-lived cloud keys in Actions secrets.
Scope the role trust to this repo (and environment).
Never log the JWT. Never write-all permissions.

FAQ

¿aud? GitHub documenta aud (token.actions.githubusercontent.com). El cloud lo verifica.

¿Environment? Combina OIDC + Environment: el sub incluye el environment. Mejor que un rol global.

¿GCP/Azure? Mismo patrón: workload identity / federated credentials. No copies un JSON de service account al secret.

Verificado 2026-09-03 contra GitHub Docs OpenID Connect y workflow syntax permissions.