Workload identity federation: removing secrets from pipelines without opening a gap
Secrets stored in deployment pipelines are a prime target: they often carry broad Azure rights and leak easily. Workload identity federation replaces them with a trust relationship. That trust still has to be tightly bounded.
How it works
An external platform that can issue OIDC tokens (GitHub, Azure DevOps, a Kubernetes cluster, another cloud provider) hands each run a signed token describing the workload. The application exchanges it for an Entra ID access token. On the Entra ID side, you declare a federated identity credential on the app registration, or on a user-assigned managed identity, made up of three elements:
- Issuer: the OIDC provider's URL;
- Subject: the exact value expected in the external token's
subclaim; - Audience: usually
api://AzureADTokenExchange.
No secret is stored and the external tokens are short-lived. Everything therefore rests on how precisely the issuer and subject are matched.
GitHub Actions: the subject is everything
For GitHub, the subject describes the context in which the workflow runs. Depending on configuration, it can point to a branch, a tag, an environment or a pull request event. The most common pitfalls:
- Trusting pull requests: a pull request subject can be obtained by a workflow triggered from a contribution whose code has not been reviewed;
- Trusting an unprotected environment: an environment subject is only worth something if the environment enforces protection rules such as required reviewers or allowed branches;
- Trusting a branch anyone can push to: without a protection rule, any contributor can create or change the expected branch;
- Customising the subject template at organisation level without weighing the effect: a subject reduced to the repository name extends trust to every workflow in it.
Flexible matching. Microsoft offers flexible federated identity credentials based on matching expressions. They make it easier to manage many repositories or branches, but an overly broad wildcard amounts to trusting a whole slice of the organisation. Check the current Microsoft documentation for their status and syntax.
Azure DevOps
Azure Resource Manager service connections can use workload identity federation. The subject identifies the organisation, project and service connection. The secret disappears, but control moves into Azure DevOps: which pipelines may use the connection, who can edit them, and which checks and approvals apply. A connection open to every pipeline in the project remains a weak point.
Kubernetes
With workload identity on AKS, or any cluster exposing an OIDC issuer, the subject designates a service account in a namespace. Anyone who can create a pod using that service account in that namespace obtains the identity. Kubernetes RBAC then becomes the real security boundary.
Who can change the trust
Adding a federated identity credential to an application is equivalent to adding a secret: an application owner or application administrator can declare an issuer they control. Changes to federated identity credentials must therefore be monitored in the audit logs, just like new secrets.
What an audit checks
- An inventory of federated identity credentials, with issuer and subject.
- Overly broad subjects: pull requests, unprotected environments, wildcard matches.
- The Azure and Graph rights of federated applications.
- Platform-side controls: branch and environment protection, service connection authorisations, Kubernetes RBAC.
- Leftover secrets on applications that are already federated.