Many teams still run CI/CD pipelines with long-lived cloud access keys in repository secrets. It works, but it is fragile: keys are over-scoped, reused, and hard to rotate safely. A better model is GitHub Actions OIDC with short-lived AWS credentials. No static keys in GitHub, less credential sprawl, and better auditability.
This guide gives a practical hardening checklist for production teams.
Why OIDC is worth it
- Short-lived credentials per run
- Trust can be restricted to repo and branch
- Easy emergency revocation by disabling role trust
- No secret rotation tickets for AWS access keys
1) Create dedicated IAM roles per boundary
Use separate roles for prod, staging, and read-only jobs. Avoid one global deployment role.
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Federated":"arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"},"Action":"sts:AssumeRoleWithWebIdentity","Condition":{"StringEquals":{"token.actions.githubusercontent.com:aud":"sts.amazonaws.com"},"StringLike":{"token.actions.githubusercontent.com:sub":"repo:ORG/REPO:ref:refs/heads/main"}}}]}
Start strict with exact repo and branch. Expand only with justification.
2) Enforce least privilege permissions
Do not attach broad administrator policies. Map required deployment APIs and ARNs only.
- Separate build, deploy, and infra roles
- Scope iam:PassRole and kms:Decrypt tightly
- Add explicit denies for forbidden accounts/regions
3) Minimal workflow permissions
permissions:
id-token: write
contents: read
steps:
- uses: actions/checkout@v4
- uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789012:role/app-prod-deploy
aws-region: us-east-1
- run: aws sts get-caller-identity
Do not grant write scopes unless needed by the job.
4) Protect production with GitHub Environments
Pair OIDC with environment approvals and branch protection. A safe chain is: reviewed PR, protected branch, environment approval, then role assumption.
5) Isolate pull request contexts
Untrusted fork code should never assume production deployment roles. Use low-privilege validation roles for PR workflows and disable deployment steps outside protected branches.
6) Audit continuously
Track AssumeRoleWithWebIdentity in CloudTrail and baseline normal usage by repo, branch, and deployment window.
aws sts get-caller-identity
aws iam simulate-principal-policy --policy-source-arn arn:aws:iam::123456789012:role/app-prod-deploy --action-names ecs:UpdateService
Operational checklist
- [ ] One role per app/environment boundary
- [ ] Trust locked to repo + branch/environment
- [ ] Least privilege with resource scoping
- [ ] Production gated by environment protections
- [ ] PR workflows separated from privileged roles
- [ ] Detection for anomalous OIDC assumptions
Final takeaway: moving from static keys to OIDC is one of the highest-value CI/CD hardening upgrades because it reduces credential exposure while improving control and visibility.
References
- AWS Security Blog: Use IAM roles to connect GitHub Actions to AWS
- GitHub Docs: Configuring OpenID Connect in cloud providers
- AWS IAM OIDC condition keys
Operational Checklist (Production-Safe)
- Confirm prerequisites and permissions before changes.
- Apply the change in staging or a low-risk window first.
- Collect authentication/process/network logs and compare against baseline behavior.
- Document rollback steps and owner responsibility.
- Confirm detections/alerts are tuned for the new control set.
Validation and Success Criteria
- The target workflow completes without errors and without introducing service interruption.
- Expected security/availability behavior is confirmed through logs and direct functional tests.
- No unintended access, policy drift, or performance regression is observed after deployment.
Common Pitfalls to Avoid
- Applying changes without confirming exact environment prerequisites.
- Skipping post-change verification and relying only on command success output.
- Not defining rollback steps before touching production assets.