6.1.3. OIDC Federation with Cloud Providers

💡 First Principle: OpenID Connect replaces stored cloud credentials with proof of identity issued at run time — the workflow asks GitHub for a signed token describing exactly which repository, ref, and environment is running, and the cloud provider exchanges that for short-lived credentials — so there is no long-lived secret to steal.

The workflow side is two lines and an action:

permissions:
  id-token: write        # required — without it, no token is issued
  contents: read
steps:
  - uses: aws-actions/configure-aws-credentials@<sha>
    with:
      role-to-assume: arn:aws:iam::123456789012:role/gh-deploy
      aws-region: us-east-1

The cloud side registers GitHub as an identity provider and writes a trust policy that constrains which claims may assume the role. That constraint is the security boundary, and the exam cares about it: a policy matching only repo:my-org/my-repo:* lets any branch or PR in that repository assume the role, while repo:my-org/my-repo:ref:refs/heads/main or repo:my-org/my-repo:environment:production narrows it properly. Pairing the environment claim with an environment's required reviewers (6.1.5) is the strongest common pattern: cloud access becomes impossible without human approval.

Benefits to state plainly: no secrets stored in GitHub, no rotation burden, credentials that expire in minutes rather than months, and per-workflow granularity enforced on the cloud side where you can audit it.

⚠️ Exam Trap: Forgetting permissions: id-token: write is the single most common OIDC failure — the token request fails and the credential step errors, even though the cloud trust policy is perfect. Note also that a permissions: block granting id-token: write and nothing else revokes contents: read, breaking checkout (2.1.4).

Reflection Question: A trust policy uses sub: repo:my-org/my-repo:*. Name two ways an attacker with only the ability to open a pull request could try to obtain those cloud credentials, and the claim that closes both.