CI/CD Secrets Management: Best Practices
OIDC federation is the modern way CI/CD authenticates to clouds. Long-lived secrets are 2020s; OIDC is 2026.
Why OIDC over static
Static secrets are the 2020s pattern: long-lived keys shared via env vars, rotated rarely, leaked easily. OIDC is the 2026 pattern: short-lived tokens issued per CI run, cryptographically tied to the run, no static keys to leak in the first place.
- Static failure mode. Long-lived keys leak in logs, screenshots, fork PRs; the blast radius is everything the key permits.
- OIDC short-lived tokens. Issued per CI run; valid for minutes; expire automatically; the leak window is tiny.
- Cryptographic tie. Token is bound to repo, branch, workflow; a leaked token cannot be replayed from elsewhere.
- The migration. Phase the change; one pipeline at a time; remove static keys after the OIDC path is proven.
Four patterns
Four OIDC patterns cover most CI/CD-to-cloud authentication needs. Each maps to a specific cloud or secret store; together they replace the static-key model entirely.
- AWS IAM Roles for GitHub Actions. OIDC trust between GitHub and AWS IAM; the canonical pattern; well-documented.
- GCP Workload Identity. OIDC trust for cloud auth on GCP; matches Workload Identity Federation primitives.
- Azure Federated Credentials. OIDC trust for AD auth on Azure; the equivalent pattern in the Microsoft stack.
- Vault JWT auth. OIDC-style JWT trust for non-cloud secrets; HashiCorp Vault accepts CI-issued JWTs.
Migration from static
Phase 1: enable OIDC for one critical pipeline. Phase 2: migrate cloud-auth pipelines. Phase 3: remove static cloud keys.
Phase 4: extend to non-cloud secrets via Vault.
Audit trail
OIDC tokens are tied to specific repo/branch/workflow. Audit log shows which CI run authenticated when.
SOC 2 evidence: cryptographic chain from auth event to action.
Antipatterns
- Long-lived AWS access keys in GitHub. Compromise risk; replace with OIDC.
- Same secrets across all repos. Shared blast radius.
- OIDC without scope limits. Token can do too much.
What to do this week
Three moves. (1) Apply this to one pipeline first. (2) Measure deploy frequency / MTTR before/after. (3) Document the outcome so the next team starts from data.