Short-lived credentials with OIDC

The traditional way to let a CI pipeline deploy to the cloud is to create an access key and paste it into a secret. That key works from anywhere, for anyone who has it, until someone remembers to rotate it. Leaked long-lived keys are one of the most common causes of cloud breaches.

Workload identity federation removes the stored key. The platform running your job vouches for it with a short-lived, signed OIDC token, and the cloud exchanges that token for temporary credentials.

GitHub Actions job ──(1) request OIDC token──▶ GitHub's token service
                    ◀─ signed JWT: repo=acme/api, ref=refs/heads/main, workflow=deploy ─
                    ──(2) present JWT──▶ AWS STS / GCP / Azure
                    ◀─ temporary credentials (valid ~1 hour) ─

The cloud trusts the issuer (GitHub, GitLab, a Kubernetes cluster), checks the token's signature, and checks its claims against a trust policy you wrote.

# GitHub Actions
permissions:
  id-token: write      # allow this job to request an OIDC token
  contents: read
steps:
  - uses: aws-actions/configure-aws-credentials@e1253824e5c10ff9df46874f81ed3ec929e19cfd # v6.3.0
    with:
      role-to-assume: arn:aws:iam::123456789012:role/deploy-api
      aws-region: eu-west-1

#The trust policy is the security boundary

Scope it tightly, by repository and branch or environment, not just organisation:

"Condition": {
  "StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" },
  "StringLike":   { "token.actions.githubusercontent.com:sub": "repo:acme/api:environment:production" }
}

If you only check the organisation, any repository in it, or any pull request workflow, can assume your production role.

#Benefits

• Nothing to leak or rotate. Credentials expire on their own within minutes to hours.
• Fine-grained and auditable. Each repository, environment or service gets its own role with least privilege, and cloud audit logs show which workflow assumed it.
• The same pattern runs inside clusters. Kubernetes ServiceAccount tokens federate to cloud IAM (IRSA and EKS Pod Identity, GKE Workload Identity, Azure Workload Identity), so pods get cloud access without key files.

The same signed identity can be used to sign build artifacts, which ties them to the workflow that produced them. See SBOMs and provenance.