Workload Identity Federation vs Static Cloud Keys: Risk, Migration Effort and Fit

A static cloud key copied into a CI secret store or a config file is valid until someone remembers to revoke it, and every process that can read it can become that workload. Workload identity federation replaces that stored key with a short-lived token the workload's own platform issues for each run, which the cloud exchanges for temporary credentials after checking issuer, audience and subject. This guide compares the two models on risk, operations and migration effort, explains where static keys still fit, and gives a phased plan to move CI/CD pipelines and external workloads off them. It is for cloud platform engineers, DevOps leads and identity architects. Setup detail per platform lives in the Workload Identity Federation Guide; this page is about the choice and the move. Cloud platforms are listed alphabetically throughout.

Key takeaways

• Federation removes the secret, not the trust. No key is stored, but the cloud now trusts an external issuer, so the trust policy conditions (audience, subject, repository, branch, environment) become the security boundary.
• Lifetime is the biggest difference. A static key lives until revoked; a federated credential lives minutes to hours. AWS AssumeRoleWithWebIdentity sessions default to one hour, and GitHub describes its OIDC token as valid for a single job.
• Each cloud provider's own guidance prefers federation. AWS IAM best practices say to require workloads to use temporary credentials, Google Cloud advises avoiding user-managed service account keys, and Microsoft Entra describes federation as removing the need to manage secrets.
• Static keys still fit a small, shrinking set of cases. Third-party tools that only accept keys, and clients that cannot obtain any token from a trusted issuer, are the main ones. Contain them with scope, network conditions, expiry and monitoring.
• Migration is mostly trust-policy work. The code change is usually one action or SDK setting; the effort is writing precise subject conditions, testing them, then deleting keys.

The short answer

Use workload identity federation for any workload whose platform can issue a signed identity token: CI/CD systems with OIDC (GitHub Actions, GitLab CI, Azure Pipelines and others), Kubernetes clusters with a service account issuer, workloads in another cloud, and on-premises hosts with a PKI certificate or SPIFFE identity. Keep static keys only where no trusted issuer exists or a third party will accept nothing else, and treat each one as a documented exception with an owner, minimum permissions, a network or condition restriction and a review date.

How each model works

Static cloud keys

An AWS IAM user access key pair, a Google Cloud service account key file or a Microsoft Entra application client secret or certificate is created once, copied to the workload and presented on every call. Google Cloud's key guidance lists the risks: credential leakage, privilege escalation through the service account, information disclosure, weakened non-repudiation where several people share a key, and malicious credential configuration files that point workloads at attacker endpoints. Microsoft's federation documentation notes that application secrets and certificates must be stored securely and rotated, and that expired credentials cause downtime.

Workload identity federation

1. The workload gets a token from its own platform: for example, a GitHub Actions job requests an OIDC JWT from https://token.actions.githubusercontent.com with claims such as sub, repository, environment and job_workflow_ref.
2. It presents the token to the cloud's token service: AWS STS AssumeRoleWithWebIdentity, the Google Cloud Security Token Service (an RFC 8693 token exchange) or the Microsoft identity platform, which accepts the external JWT as a client assertion.
3. The cloud validates it against a configured trust: the issuer's signing keys, the audience, and conditions on the subject and other claims.
4. The cloud returns short-lived credentials scoped to one role, service account or application, which expire without any revocation step.

Side-by-side comparison

Where static keys still fit

AWS documentation lists use cases that still need long-term credentials, including workloads that cannot use IAM roles (its example is WordPress plugins) and third-party clients or vendors not hosted on AWS. In practice the remaining cases are:

• Third-party SaaS that accepts only a key: ask the vendor for federation or role assumption support; until then, issue a dedicated key with read-only or narrowly scoped permissions.
• Legacy or embedded systems with no token issuer: consider a PKI-based route (AWS IAM Roles Anywhere, X.509 federation in Google Cloud, certificate credentials in Microsoft Entra) before falling back to a secret.
• Break-glass automation: a sealed, monitored credential kept for when the federation path itself is down, used and rotated under a documented procedure.
• Short-lived development access: Google Cloud recommends key expiry for temporary, non-production cases such as these, not for production workloads.

Each exception should carry an owner, a ticket, minimum permissions, an IP or VPC condition where the platform supports one, and a review date. See the OWASP NHI Top 10 NHI7 Long-Lived Secrets Guide.

Platform specifics

For each platform, NHI Mgmt Group has a dedicated guide: the AWS Access Keys Security Guide, the Google Cloud Service Account Keys Security Guide and the Azure Managed Identities Security Guide.

Security trade-offs of federation

• Trust condition breadth: a condition that matches any repository in an organisation, or any branch, lets a pull request or a forked workflow assume a production role. Google Cloud's documentation warns against granting access to all identities in a pool and recommends attribute conditions, partly to prevent confused deputy problems. Pin to repository plus protected branch or deployment environment.
• Issuer compromise: anyone who can mint tokens as the trusted issuer can become every workload that trusts it. Self-hosted issuers (Kubernetes clusters, internal CI) need their signing keys protected like a CA. See the Self-Hosted OIDC Issuer Security Guide.
• Token exfiltration within the run: a malicious step in the same job can request or read the federated token and use it until expiry. Request tokens only in the steps that need them and keep session durations short.
• Audience reuse: using the same audience value across clouds or environments lets a token minted for one target be replayed at another that trusts the same issuer. Use a distinct audience per target.
• Availability coupling: deployments now depend on the issuer's discovery and JWKS endpoints and the cloud token service. Keep a documented break-glass path.

Migration plan: static keys to federation

1. Inventory keys and their callers. List IAM user access keys, service account keys and app registration secrets, with last-used time and the source IPs or user agents that use them. Tag each with the pipeline or system that owns it. See How to find unused AWS IAM roles and access keys and How to inventory Google Cloud service account keys and replace them with federation.
2. Remove what is unused. Disable keys with no recent use, wait one full release cycle, then delete.
3. Prioritise by exposure. Start with keys stored in CI/CD variables, those with administrative permissions and those shared across pipelines.
4. Create the trust per workload with the narrowest conditions: one role or service account per pipeline and environment, subject pinned to repository and protected branch or environment, distinct audience.
5. Test in parallel. Add the federated login step alongside the existing key in a non-production pipeline; confirm the cloud audit log shows the federated session doing the work.
6. Cut over and disable the key, rather than delete it, so rollback is a single re-enable for one release.
7. Delete the key and its stored copies in CI variables, secrets managers and developer machines once the pipeline has run cleanly.
8. Prevent regression with organisation guardrails that block new key creation by default and an exception process for the cases above.

Platform walkthroughs: How to set up workload identity federation for GitHub Actions to AWS, How to set up workload identity federation for GitLab CI to Azure and How to move GKE workloads from keys to Workload Identity Federation.

Decision guidance

Small teams: start with the CI pipeline that deploys to production; one federated role removes the most valuable key in the estate. Large estates: treat federation trusts as governed identities with owners and reviews, use templates for trust conditions, and report remaining keys per business unit.

Where identity governance fits

Federation moves the identity record from a secret to a trust relationship, and that relationship needs the same governance as any non-human identity: an owner, a purpose, least-privilege permissions, periodic review and deprovisioning when the repository or cluster is retired. Review trust policies with the Workload Identity Federation Trust Review Checklist, and pipeline identity more broadly with the CI/CD Pipeline Identity Security Guide.

Threat model, failure modes and a worked scenario for each option

Static cloud keys

Threat model. A static key is a bearer credential that works from anywhere until someone deletes it. Google Cloud's own guidance lists the risks plainly: keys end up in places they should not be stored, an attacker who holds one can escalate privileges by acting as the service account, and activity performed with a stolen key hides behind the service account's identity, which weakens non-repudiation. Failure modes. Keys stay valid until deleted by default, so a key copied into a CI variable three years ago is still live. Expiry dates help, but the same guidance warns they can break production workloads when the key lapses. Controls. Use organisation policy constraints to stop new keys being created, allow exceptions only where no federated alternative exists, record an owner and a rotation date for every exception and alert on use from unexpected networks. Decision criteria. Keep a static key only when the caller cannot present any verifiable token, such as a legacy appliance.

Workload identity federation

Threat model. The asset moves from a stored key to the trust relationship between the cloud and an external issuer. The attacker now wants to obtain a token from that issuer whose claims satisfy a loosely written trust policy. Failure modes. Trust conditions that match only the issuer, or a wildcard on the repository or branch, let any workflow in an organisation assume a production role. Controls. Scope trust conditions to the subject, repository and environment claims rather than broad matches, require a dedicated audience, and log every token exchange. GitHub's OIDC documentation notes that repositories created after 15 July 2026 use an immutable default subject format that includes owner and repository IDs, which closes the rename and recreate trick against name-based conditions. Decision criteria. Federate wherever the caller already holds a signed identity token from a platform you trust.

Worked scenario. A deployment pipeline holds a long-lived cloud key in a repository secret. The team replaces it with an OIDC trust that accepts only the production environment of one repository. The cloud access token issued is valid for that single job and then expires, so a leaked log line or compromised runner yields minutes of access instead of years, and the old key is deleted rather than disabled.

Detection and measurement

• Key creation: alert on new IAM user access keys (CloudTrail CreateAccessKey), new service account keys (Cloud Audit Logs google.iam.admin.v1.CreateServiceAccountKey) and new secrets or certificates on Entra app registrations, especially outside the exception process.
• Key use from unexpected places: static key calls from new networks or user agents. See How to Detect aws access key use from unusual locations.
• Federated sessions: log AssumeRoleWithWebIdentity, STS token exchanges and Entra sign-ins by federated credential, and alert on subjects not seen before for a role.
• Trust policy changes: alert on edits that widen subject conditions or add new identity providers.

Metrics that show the programme is working:

• Number of active static cloud keys, trended down, with each remaining one tied to an approved exception.
• Percentage of CI/CD deployments to production authenticated by federation.
• Median age of remaining static keys.
• Percentage of federation trusts with subject conditions pinned to a repository and branch or environment.
• Time from key exposure detection to revocation for the keys that remain.

Common failure patterns

• Static secrets in CI variables harvested at run time: in the Codecov Breach 2021, a tampered uploader script sent CI environment variables, including cloud keys, to an attacker server for about two months, and every affected customer had to find and rotate each long-lived secret.
• Wildcard subjects: trust conditions such as repo:org/* let any repository or pull request workflow assume a production role.
• Federation added, key never deleted: the pipeline uses the federated role, but the old key still sits in the CI variable store and in a developer's shell history.
• One role for every pipeline: a single broad role federated to many repositories recreates the blast radius of a shared key.
• Missing audience check: a trust that does not check the audience accepts tokens minted for other targets by the same issuer.
• No guardrail: without a policy blocking new keys, teams create fresh ones whenever federation set-up looks harder.

Framework mapping

Practitioner checklist

• Inventory every static cloud key with owner, last use and calling system.
• Delete unused keys after a disable period.
• Federate every CI/CD pipeline and Kubernetes workload whose platform issues identity tokens.
• Pin trust conditions to repository plus protected branch or environment, and use a distinct audience per target.
• Use one role, service account or application per workload and environment, with least privilege.
• Block new key creation by organisation policy and run an exception process with review dates.
• Remove old keys from CI variables, secrets stores and developer machines after cut-over.
• Alert on key creation, trust policy changes and new subjects assuming a role.
• Protect self-hosted issuers' signing keys and keep a documented break-glass path.

Standards and references

• AWS: Security best practices in IAM
• AWS: AssumeRoleWithWebIdentity API reference
• Google Cloud: Workload Identity Federation
• Google Cloud: Best practices for managing service account keys
• Microsoft Learn: Workload identity federation
• GitHub Docs: OpenID Connect
• IETF: RFC 8693 OAuth 2.0 Token Exchange

Related NHI Mgmt Group resources: Workload Identity Federation Guide · GitHub Actions OIDC Federation Hardening Guide · Cloud Access Key Leak Playbook · Top 10 Workload Identity Mistakes