azCloudOps

Subscribe

Workload identity federation: cloud access without stored keys

Abstract cover on a deep navy background: three glowing nodes in blue, amber and teal linked by thin lines, with a small amber point of light passing between them, suggesting a short-lived token handed from one system to another.

Workload identity federation lets a pipeline, pod or virtual machine reach a cloud without a stored key. Azure, AWS and Google Cloud all support it under different names, and one deadline makes it worth a look now: Azure DevOps service connections must move to a new token issuer before July 1, 2027.

Level: Foundation to Operations. Format: Cloud Decoded. Providers: Azure, AWS, Google Cloud. Reading time: about five minutes. This piece answers the four questions every azCloudOps article follows, explained in our welcome post.

What is it?

Software that calls a cloud API has to prove who it is. The old way is a long-lived secret: an access key, a client secret or a service account key file, copied into a pipeline variable or a config file. Secrets leak, expire at the worst moment, and need rotating by hand.

Federation replaces the secret with a short-lived token that the workload’s own platform signs. Think of a hotel key card instead of a house key: the front desk checks your booking, hands you a card that works for a few days, and nobody has to change the locks when you leave. The cloud trusts the platform that issued the token, checks a few claims inside it, and returns temporary credentials.

Every provider describes the same problem. Microsoft says stored secrets and certificates “pose a security risk and have to be stored securely and rotated regularly”. Google says service account keys “can present a security risk if they are not managed correctly”. AWS says it strongly recommends that you do not store AWS credentials long term in applications outside AWS.

The technical shape is the same everywhere. You register a trust once: which issuer, which subject (for example one GitHub repository and branch, or one Kubernetes service account) and which audience. At run time the workload presents its OpenID Connect token or SAML assertion, the cloud checks those three things, and issues credentials that expire on their own.

Diagram titled Federation swaps stored cloud keys for short-lived tokens. Four steps: a workload runs anywhere, its platform signs a short-lived OIDC token or SAML assertion, the target cloud checks issuer, subject and audience against a trust set up in advance, and the cloud returns temporary credentials. Below, what each cloud calls it: Azure, Microsoft Entra Workload ID with federated identity credentials, and Azure DevOps service connections moving to the Entra issuer before the old issuer ends July 1, 2027; AWS, an IAM OIDC provider and role for inbound access, and STS GetWebIdentityToken issuing JWTs of 60 to 3,600 seconds for outbound calls; Google Cloud, Workload Identity Federation with pools and providers trusting AWS, Azure, OIDC, SAML 2.0 and X.509, replacing service account keys.
One pattern, three names: how workload identity federation looks on Azure, AWS and Google Cloud.

What changed?

Three updates matter, all read on the official pages on November 9, 2026.

  • Azure DevOps. On June 22, 2026 the Azure DevOps team announced the retirement of the Azure DevOps issuer in workload identity federation service connections. The issuer was deprecated on July 1, 2026, new connections use the Microsoft Entra issuer by default, existing connections show a warning until June 2027, and the old issuer reaches end of life on July 1, 2027. The scope is Azure public cloud connections that use single-tenant apps or managed identities. Conversion is an Update button per connection, and pipelines need no task changes.
  • AWS, now in both directions. Inbound OIDC federation lets an outside workload exchange its token for temporary credentials mapped to an IAM role. Since November 19, 2025, IAM outbound identity federation also lets AWS workloads call other services with short-lived JWTs from the STS GetWebIdentityToken API. Tokens last from 60 to 3,600 seconds, five minutes by default, and the feature carries no additional cost. You enable it once per account, per the getting started guide.
  • Microsoft Entra and Google Cloud list each other. The Entra concepts page names GitHub Actions, Kubernetes on AKS, EKS and GKE, Google Cloud, and AWS through outbound identity federation as supported sources. Google’s Workload Identity Federation page, updated November 7, 2026, trusts AWS, Azure, GitHub, GitLab, Kubernetes, X.509 certificates and any OIDC or SAML 2.0 provider.

Where is it heading? (analysis)

This section is my analysis, not vendor guidance. With AWS issuing tokens outward, all three clouds can now be both the issuer and the trusting side. Over the next 6 to 18 months I expect key-free access between clouds to become the default in reference architectures, and stored cloud keys to show up as findings in posture tools rather than as accepted practice. The same pattern is the natural fit for AI agents that call tools across clouds: an agent that holds no permanent key is far easier to govern and to switch off.

What should I do?

  • Developers: if your GitHub Actions or GitLab pipeline stores a cloud key as a secret, switch that job to federation first. It is usually a trust entry and a few lines of workflow.
  • Operations: in Azure DevOps, open Service connections, look for the deprecation warning, and convert each flagged connection to the Entra issuer well before July 1, 2027.
  • Security and governance: inventory long-lived keys across all three clouds, and scope every trust tightly. A subject such as one repository and one branch is good; a whole organization is too broad.
  • Platform teams: offer federation as the paved road in your landing zone templates, so new workloads never receive a key. Kubernetes teams heading home from this month’s conferences can start with service account token federation.

A word of caution: federation moves the risk from a leaked key to a loose trust rule. Review trust conditions the same way you review firewall rules.

Discuss

How many long-lived cloud keys does your team still hold, and what is blocking the switch to federation? Share your answer in the comments.

Sources

Last verified: November 9, 2026

Leave a Reply