Configure granular GITHUB_TOKEN permissions and use OIDC token federation to remove long-lived cloud secrets

Free sampleSecure and optimize automationhard

A deployment job needs to authenticate to AWS and assume an IAM role using GitHub's OIDC provider so that no long-lived AWS access keys are stored as repository secrets. The job already calls aws-actions/configure-aws-credentials with role-to-assume. The run fails because the workflow cannot obtain an OIDC token. Which addition to the workflow is required for the job to request that token?

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@<sha>
        with:
          role-to-assume: arn:aws:iam::111122223333:role/deploy
          aws-region: ap-southeast-2

AStore the role ARN as an encrypted repository secret and reference it through secrets in the with block, because OIDC still needs the target role supplied as a protected secret rather than as plain text.
BAdd an actions/setup-node step before the credentials step, because the OIDC token is issued by the Node toolchain that setup-node installs onto the GitHub-hosted runner for the job.
CAdd permissions with id-token: write to the deploy job, because that scope authorises the job to request a signed OIDC token from GitHub which the credentials action then exchanges for temporary AWS credentials. Correct
DAdd permissions with contents: write to the deploy job, because the OIDC token is written into the workspace as a file and the job needs repository write access to persist it before the exchange.

Grant the id-token: write permission so a job can request a GitHub OIDC token and exchange it for short-lived cloud credentials. Federating into a cloud provider with OIDC requires the workflow to obtain a signed token from GitHub's OIDC endpoint, and that request is gated by the id-token: write permission. Without it the runner cannot mint the token, so the credentials action has nothing to exchange with AWS STS. The role ARN is not a secret, setup steps for language runtimes are unrelated, and contents: write governs repository contents rather than token issuance.

Why A is wrong: Tempting because secrets feel mandatory for cloud auth, but the role ARN is not sensitive and the failure is the missing token request, so storing the ARN as a secret does not let the runner mint an OIDC token.

Why B is wrong: Tempting because many jobs begin with a setup step, but setup-node provisions a language runtime and has nothing to do with OIDC token issuance, so adding it leaves the token request unauthorised.

Why C is correct: The id-token: write permission lets the job fetch a signed JSON Web Token from GitHub's OIDC provider, and the credentials action exchanges that token with AWS STS for short-lived credentials, removing the need for stored keys.

Why D is wrong: Tempting because contents: write sounds like it covers writing a token, but the OIDC token is requested from GitHub's endpoint rather than written to the repository, and contents scope does not authorise the id-token request.

Configure granular GITHUB_TOKEN permissions and use OIDC token federation to remove long-lived cloud secrets.

Practice question for this objective

More in this domain