How do I set up secretless AWS access in CI/CD with OIDC and IAM roles?

Short answer: the long-lived AWS keys in GitHub Secrets are exactly what you should eliminate — they leak, they’re hard to rotate, and they’re standing credentials sitting open all the time. OIDC removes them.

Short answer

The core idea: instead of storing a permanent key somewhere, use a temporary identity minted fresh on every run. I covered setting up the workflow itself in the GitHub Actions post; the only change here is that no key is baked into that pipeline any more.

Why

1. A long-lived key is a standing identity sitting open all the time. It leaks, it’s hard to rotate, and central tracking is hard; GitHub Secrets helps to a point, but the key itself still sits somewhere.

2. OIDC makes AWS answer “is this workflow really coming from your repo?” cryptographically. AWS trusts tokens GitHub signs; unless the trust policy conditions match, a fork or a random PR can’t assume the role.

3. The workflow gets temporary STS credentials at runtime. At run time, it exchanges the short-lived GitHub OIDC token via AWS STS for temporary credentials that expire in an hour by default. No permanent secret is stored anywhere — even if leaked, it’s very short-lived.

What to do

1. Configure GitHub Actions as an OIDC identity provider in AWS IAM. This is the one-time setup that makes AWS trust tokens GitHub signs.

2. Create an IAM role with a tightly-scoped trust policy. In the role’s trust policy, pin the sub condition to a specific repo + branch + environment. That way only the source you defined can assume the role.

3. Apply least privilege + environment protection for prod. Scope the role to minimum permissions. For prod access, use GitHub Environments + required reviewers. The same approach exists on every cloud: GCP and Azure do the same job with Workload Identity Federation.

Bottom line: I’d set up OIDC + a tightly-scoped IAM role for AWS — zero stored keys, strict trust conditions, environment protection in prod. For non-cloud secrets (like a DB password), pull them from a secrets manager at runtime instead of putting them in GitHub Secrets. The rule is clear: make standing credentials impossible by minting identity fresh and short-lived.