How to Secure CI/CD Pipelines With OIDC Federation Instead of Stored Secrets

Retrospective: this article looks back at events from April 2022, written in 2026 with the benefit of hindsight.

Stored cloud credentials in CI/CD systems are a prime target. OIDC federation lets pipelines get short-lived credentials from AWS or Azure on demand — with no stored secrets to steal. Here is how.

How it works

Your CI/CD platform (GitHub Actions, GitLab, Azure DevOps and others) issues a signed OIDC token describing the job — repository, branch, environment. The cloud provider trusts that issuer and exchanges the token for temporary credentials, with conditions limiting which repositories and branches can do so.

AWS with GitHub Actions

1. In IAM, create an OIDC identity provider for token.actions.githubusercontent.com.
2. Create an IAM role with a trust policy allowing sts:AssumeRoleWithWebIdentity from that provider, with conditions on token.actions.githubusercontent.com:sub — for example, repo:your-org/your-repo:ref:refs/heads/main or a specific environment.
3. Grant the role only the permissions the pipeline needs.
4. In the workflow, use the aws-actions/configure-aws-credentials action with role-to-assume and permissions: id-token: write.
5. Delete the old access keys stored as repository secrets.

Azure with GitHub Actions

1. Create an app registration or user-assigned managed identity.
2. Add a federated identity credential for GitHub, specifying organization, repository and entity (branch, environment or pull request).
3. Assign Azure RBAC roles scoped to the resources the pipeline deploys.
4. Use the azure/login action with client ID, tenant ID and subscription ID — no secret.
5. Remove client secrets.

Hardening tips

• Restrict trust to protected branches or deployment environments with required reviewers.
• Use separate roles for plan/test and deploy.
• Avoid wildcard subject conditions.

Verify

No long-lived cloud credentials in CI/CD secrets; all deployments authenticate through federation.