Stop Storing Long-Lived Cloud Keys in CI/CD: The 2026 Guide to OIDC Workload Identity Federation

If an attacker found one of your cloud access keys today, how long would it stay valid? For most teams, the honest answer is “until someone notices” — which can be months. According to Datadog’s 2025 State of Cloud Security report, 59% of AWS IAM users have an access key older than one year, alongside 55% of Google Cloud service accounts and 40% of Microsoft Entra ID applications. A credential that never expires is a credential that only ever gets more dangerous.

This is the single most fixable identity risk in cloud CI/CD pipelines today, and the fix has a name: OIDC workload identity federation. This guide walks through what it is, why long-lived keys keep leaking, and exactly how to migrate your pipelines to short-lived, keyless authentication.

The Problem: Static Secrets Don’t Expire, But They Do Leak

The classic CI/CD pattern is to store AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY (or a GCP service account JSON, or an Azure client secret) as repository secrets, then hand them to every build. It works on day one and quietly becomes a liability forever after. Long-lived credentials share three properties that attackers love: they never expire on their own, any step in any workflow can read and exfiltrate them, and once stolen they grant persistent access with no built-in time limit.

The leak surface is enormous. A long-cited GitGuardian analysis found that, on average, every 10,000 Git commits leak roughly 84 AWS access keys, and over 30% of developers admit to accidentally committing credentials to public repositories. Industry breach data tells the rest of the story: 64% of cloud breaches involve identity misuse, privilege escalation, or credential theft, and compromised-credential incidents cost an average of $4.67M with a 246-day mean time to identify and contain. The 2025 “16 billion credential” compilation leak was a stark reminder that exposed secrets aggregate and circulate cheaply — stolen credentials sold for as little as $10 on some markets.

Technical Analysis: How OIDC Federation Replaces the Key

OpenID Connect (OIDC) federation removes the stored secret entirely. Instead of a key living in your CI system, your pipeline requests a short-lived, cryptographically signed identity token from its own platform’s identity provider (for example, GitHub Actions, GitLab, or your Kubernetes cluster). Your cloud provider is configured to trust that issuer, validates the token, and exchanges it for temporary credentials that expire in minutes.

The mechanics on AWS look like this:

1. Register the OIDC provider. Create an IAM OIDC identity provider that points at your CI platform’s issuer URL (e.g., https://token.actions.githubusercontent.com for GitHub Actions).
2. Create a scoped IAM role. Define a role whose trust policy matches the token’s sub (subject) claim. The subject encodes the repository, branch, and environment — so you can pin access to exactly repo:my-org/my-repo:ref:refs/heads/main and nothing else.
3. Assume the role at runtime. The workflow uses the standard aws-actions/configure-aws-credentials action with web identity. AWS STS returns session credentials valid for minutes, scoped to the role’s permissions.

The same pattern applies across clouds: GCP calls it Workload Identity Federation (mapping the OIDC subject to a service account), and Azure uses federated credentials on an app registration. In every case, there is no secret stored anywhere.

The trust policy is where the real security lives. Use StringEquals and StringLike conditions on the sub claim to enforce granular access, and give staging and production different roles with different trust policies and permission levels. A common mistake is a wildcard like repo:my-org/*:* — that effectively lets any branch in any repo in your org assume the role. Pin to specific repos, specific branches, and specific environments.

Impact Assessment

Risk rating: High (and high-leverage to fix). Long-lived keys are a top-two breach entry point, yet eliminating them in CI/CD is a contained, well-documented engineering task — often a day or two of work per pipeline.

Who is affected: Any organization running CI/CD against AWS, Azure, or Google Cloud with stored access keys — which is the large majority. Non-human-identity exposure (API keys, service-account credentials, AI-tool tokens) is the fastest-growing credential category heading into 2026, driven by teams wiring up automation and AI platforms faster than they rotate secrets.

Upside beyond security: Federation also kills the operational tax of key rotation schedules and the recurring compliance findings about stale credentials. And because every OIDC authentication logs the repository, branch, commit, actor, and workflow in CloudTrail, your audit trail becomes dramatically richer than “someone used static key AKIA… from an IP.”

CloudShieldSecure Perspective

Eliminating stored keys is the goal; knowing you’ve eliminated them — and catching the ones that creep back in — is the discipline. This is exactly the gap CloudShieldSecure is built to close. The platform continuously inventories non-human identities across your cloud accounts, flags access keys by age (so the 59% problem becomes a dashboard, not a surprise), and detects when a long-lived credential is reintroduced into a pipeline or committed to a repo. Just as important, CloudShieldSecure baselines normal federated-role usage and alerts on anomalies — a role assumed from an unexpected branch, region, or actor — so that even your short-lived credentials are watched for misuse. Keyless is a configuration; staying keyless is continuous monitoring.

Recommended Actions

Work through this checklist for each CI/CD pipeline:

• Inventory first. List every stored cloud credential in your CI system and rank by permission scope and age. Anything older than 90 days is a priority.
• Migrate one pipeline end-to-end. Stand up the OIDC provider, create a tightly scoped role, and convert a single non-critical workflow before rolling out broadly.
• Pin the trust policy. Use StringEquals/StringLike on the sub claim — lock to specific repo, branch, and environment. Never use a bare wildcard.
• Separate roles per environment. Distinct roles and permissions for staging vs. production.
• Set short session durations. Keep STS/temporary credential lifetimes to minutes, not hours.
• Delete the old keys. Federation only helps if you actually revoke the static secrets afterward. Confirm via CloudTrail/audit logs that nothing still uses them, then delete.
• Enforce in CI/CD with policy-as-code. Add a check (e.g., Open Policy Agent) that fails any pipeline reintroducing a long-lived key.
• Monitor continuously. Alert on new access keys, stale keys, and anomalous federated-role assumptions.

Sources & References

• Datadog — 2025 State of Cloud Security Report
• Datadog — Key learnings from the 2025 State of Cloud Security study
• ScaleSec — OIDC for GitHub Actions on AWS
• AWS Fundamentals — Connect GitHub Actions to AWS with OIDC (No Access Keys)
• Sysdig — Cloud security best practices for 2026

CloudShieldSecure is a cybersecurity platform by CloudKonsult Limited. Learn more at cloudshieldsecure.cloudkonsult.cloud.