Quartz 5

workload-identity-federation

Properties2
tagsidentity, security, federation, service-connections
aliasesworkload identity, federated credential, OIDC federation, token federation

2 min read

Workload identity federation

What it is

Workload identity federation lets a workload (a CI pipeline, container, or app) authenticate to a cloud — here Microsoft Entra ID / Azure — by exchanging a token it already holds (an OIDC token from GitHub, another cloud, or an identity provider) for a cloud access token. It replaces storing a long-lived service-principal secret with a short-lived, scoped, per-run credential.

Why it exists

A service principal can authenticate with a client secret or certificate, both of which need lifecycle management. A federated identity lets a pipeline ask its issuer for a token and trade it for a short-lived Azure access token, avoiding a static credential in the pipeline configuration.

Key ideas

  • Federated credential — a rule on a service principal saying “accept this issuer’s tokens when these claims match” (e.g. sub = the GitHub repo, ref/aud = a target branch/job).
  • OIDC federation — the common CI case: the issuer (GitHub Actions, Azure Pipelines, etc.) mints an OpenID Connect token the workload presents to Microsoft Entra ID.
  • Exchange — issuer issues token → workload presents it to the identity as proof → Entra ID checks signature + claims → returns an Azure access token bound to the identity’s RBAC roles.
  • Short-lived & scoped — the cloud token is minimal-scope and expires quickly, so a leak has low blast radius.

How it fits

[CI run] → [issuer mints OIDC token] → [present to workload identity] → [Entra ID verifies claim → issues scoped token] → [deployment action]

It is the secure substrate for service connections and deployment-automation in Azure Pipelines / GitHub Actions.

Exam notes

  • Differentiator vs a secret/certificate-based service principal: no stored credential in the pipeline; the federated identity exchanges a short-lived issuer token.
  • vs managed identity (see service-principal): managed identities are for Azure-resident workloads; workload identity federation lets external issuers (GitHub, third-party IdPs) authenticate.
  • It powers OIDC federation for CI/CD without placing PATs/client-secrets in Actions secrets.

service-principal · entraid · azure-pipelines · github-actions · key-vault · deployment-automation

📘 Source: Microsoft Learn — Workload identities overview · GitHub Docs — OIDC hardening

Graph View

Backlinks