principlebashMajor
OIDC authentication in CI eliminates long-lived cloud credentials
Viewed 0 times
aws-actions/configure-aws-credentials@v4
OIDCshort-lived credentialsIAM roleworkload identityno long-lived secretsSTS
awsgcp
Error Messages
Problem
CI workflows store long-lived cloud credentials (AWS access keys, GCP service account keys) as GitHub secrets. These keys do not expire, are copied into secrets managers, and rotate infrequently. A leaked key grants persistent access.
Solution
Use OpenID Connect (OIDC) to get short-lived credentials directly from the cloud provider:
IAM role trust policy (allows only this repo's main branch):
# AWS example
jobs:
deploy:
runs-on: ubuntu-latest
permissions:
id-token: write
contents: read
steps:
- uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789:role/GitHubActionsRole
aws-region: us-east-1
- run: aws s3 ls # no credentials stored anywhereIAM role trust policy (allows only this repo's main branch):
{
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:sub": "repo:org/repo:ref:refs/heads/main",
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
}
}
}Why
OIDC tokens expire after the job ends (typically 1 hour). There is nothing to rotate, nothing to store, and no credential that outlives the job. The trust policy restricts which repos and branches can assume the role.
Gotchas
- permissions: id-token: write must be explicitly declared—it is not on by default
- The sub claim format varies by trigger type (branch vs PR vs tag)—test the exact claim value in IAM before going to production
- GCP uses Workload Identity Federation; AWS uses STS AssumeRoleWithWebIdentity—both require one-time setup of the trust relationship
Revisions (0)
No revisions yet.