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

> Delete the long-lived AWS keys from GitHub Secrets and assume a repo/branch-scoped IAM role over OIDC; pull non-cloud secrets from a manager at runtime.

- Asked: 2026-06-12
- Answered: 2026-06-12
- Asked by: Doruk
- Tags: ci-cd, guvenlik, altyapi
- Source: https://www.muhammetsafak.com.tr/en/just-ask/secretless-ci-cd-with-aws-iam-roles-and-oidc/
- Language: en-US
- Author: Muhammet Şafak

---
**Question:** Our GitHub Actions workflows need AWS access keys and production DB passwords. Putting them in the repo is a huge hole; GitHub Secrets helps to a point, but key rotation and central tracking are hard.

How do I make our pipeline access AWS resources secretlessly using AWS IAM roles and OIDC?


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.

The core idea: instead of storing a permanent key somewhere, use a temporary identity minted fresh on every run.

1. **Configure GitHub Actions as an OIDC identity provider in AWS IAM.** This makes AWS trust tokens GitHub signs. Now AWS can cryptographically verify "is this workflow really coming from your repo?"
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 a fork or a random PR can't assume the role; only the source you defined can.
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.
4. **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.

## Related Reading

- [Why is keeping the key in .env risky when encrypting sensitive financial data — what do KMS/Vault give you?](https://www.muhammetsafak.com.tr/en/just-ask/encrypting-sensitive-financial-data-at-rest-and-key-management/) — Just Ask
- [How do I isolate self-hosted CI/CD runners and build an ephemeral, clean-after-each-run environment?](https://www.muhammetsafak.com.tr/en/just-ask/isolating-and-securing-self-hosted-ci-cd-runners/) — Just Ask
- [How do I shrink Docker images with multi-stage builds and distroless?](https://www.muhammetsafak.com.tr/en/just-ask/shrinking-docker-images-with-multi-stage-builds-and-distroless/) — Just Ask