OIDC eliminates static CI/CD secrets via short-lived tokens. Master ephemeral identity for GitHub Actions and GitLab with our 2026 cheat sheet. Read now.
Why Static CI/CD Secrets Are the Weak Link
Most pipelines authenticate to cloud providers, registries, and package repositories using long-lived credentials stored as CI variables. These secrets sit in your pipeline configuration indefinitely, get copied into logs and forks, and often carry far more permission than any single job needs. If one leaks, an attacker has a durable key that keeps working until someone notices and rotates it.
Rotation is the usual answer, but manual rotation is slow and easy to forget, and automated rotation still leaves a valid secret in place between cycles. The core problem is that the credential outlives the work it was created for.
How OIDC Removes the Static Secret
OIDC (OpenID Connect) lets your CI/CD system prove its identity directly to a cloud provider without a stored password. Instead of holding a secret, the pipeline requests a short-lived token that describes the job — who triggered it, which repository and branch it belongs to, and what it is allowed to do. The provider verifies that token against a trust relationship you configure once, then hands back temporary credentials scoped to that single run.
Because the token is minted per job and expires within minutes, there is nothing durable to steal. The credential exists only for the lifetime of the work, and its claims are cryptographically tied to the exact pipeline context that requested it.
Setting It Up in GitHub Actions and GitLab
The pattern is the same on both platforms: register the CI provider as a trusted identity issuer on the cloud side, then define which token claims are allowed to assume which role or permission set. The pipeline requests the token at runtime and exchanges it for scoped access.
- GitHub Actions: grant the workflow the
id-token: writepermission, configure the cloud provider to trust GitHub's issuer, and restrict the trust policy to specific repositories, branches, or environments. - GitLab: use the built-in ID token that GitLab injects into the job, and bind the cloud-side trust to project, ref, or protected-branch claims.
- Both: scope each role to the minimum actions a job needs, and use separate trust conditions for production versus preview or feature branches.
Getting Ephemeral Identity Right
OIDC only helps if the trust policy is tight. A permissive condition — trusting an entire organization, or any branch — recreates the blast radius you were trying to shrink, since any fork or feature branch could then mint production credentials. Pin trust to the specific repository, ref, and environment, and give each pipeline stage its own narrowly scoped role rather than one shared identity.
Treat the short-lived credentials as disposable: never write them to a persistent store, cache, or log, and let them expire naturally instead of trying to extend them. Done well, zero-trust CI/CD means every deployment authenticates as itself, for that run only, with no standing secret left behind to manage or leak.