# 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://muhammetsafak.com/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.

## 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](/blog/did-someone-say-github-actions/); 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.

## Related Reading

- [Why is keeping the key in .env risky when encrypting sensitive financial data — what do KMS/Vault give you?](https://muhammetsafak.com/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://muhammetsafak.com/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://muhammetsafak.com/just-ask/shrinking-docker-images-with-multi-stage-builds-and-distroless/) — Just Ask