Every Azure service principal secret you rotate is a secret that could have been eliminated instead. Most teams treat credential rotation as hygiene — a calendar reminder every 90 days, a script that pushes a new client secret into a pipeline variable, a Slack message when it fails at 2 a.m. But rotation only manages the risk of a long-lived credential; it doesn't remove it. A stolen service principal secret is still valid until someone notices, and CI/CD systems, Kubernetes clusters, and automation scripts are exactly where secrets tend to leak — in logs, in environment dumps, in forked repos.
Azure Workload Identity Federation solves this differently: instead of storing a secret at all, it lets a workload exchange a short-lived, cryptographically signed token for an Azure AD access token, at request time, with nothing sitting on disk. Below is how it works, where it fits in AKS, and what changes operationally when you adopt it.
What Is Azure Workload Identity Federation?
Azure Workload Identity Federation is a mechanism that lets an external identity provider issue a token that Azure AD (Microsoft Entra ID) trusts enough to exchange for a real access token — without a client secret or certificate ever being generated. Microsoft introduced federated credentials for Azure AD applications in October 2021, and by 2022 extended first-class support to Azure Kubernetes Service through the AKS workload identity feature, which reached general availability in AKS 1.22+ clusters. The trust relationship is configured once: you register the issuer URL and subject claim of the external token issuer (say, a Kubernetes cluster's OIDC issuer, or GitHub Actions) against an app registration, and Azure AD will accept any token matching that issuer/subject pair for up to one hour, using the OAuth 2.0 token exchange flow defined in RFC 8693. No secret is stored by the workload at any point — not in a Kubernetes Secret, not in a pipeline variable, not in Key Vault.
How Does It Eliminate Service Principal Secrets Instead of Just Hiding Them?
It eliminates them because the workload never possesses a long-lived credential to hide in the first place. In the traditional model, a pod or pipeline holds a client ID and client secret (or certificate), both of which are valid for months and can be exfiltrated, logged, or committed by accident — this is precisely the pattern behind incidents like the 2021 Codecov breach, where a static credential embedded in a build script was extracted and used to pull secrets from thousands of downstream CI environments. With federated credentials, the workload instead presents a token it already has by virtue of its identity — a Kubernetes service account token, a GitHub Actions OIDC token, a SPIFFE SVID — and Azure AD does the exchange server-side. Microsoft's own guidance now pushes customers toward this model directly: as of 2024, Entra ID enforces a maximum secret lifetime and nudges new app registrations toward federated credentials by default in the portal UI. The practical effect is that "eliminate service principal secrets" stops being an aspirational security goal and becomes the default configuration for any workload running in AKS, GitHub Actions, or another OIDC-capable platform.
How Do You Actually Set Up AKS Workload Identity?
You set it up by enabling the OIDC issuer and workload identity add-ons on the cluster, then mapping a Kubernetes service account to an Azure AD application via a federated credential. Concretely: az aks update --enable-oidc-issuer --enable-workload-identity turns on both prerequisites on an existing cluster (no full redeploy needed since AKS 1.24). You then annotate a Kubernetes ServiceAccount with the Azure AD application's client ID and label the pod spec with azure.workload.identity/use: "true". Azure AD's federated credential configuration on the app registration references the cluster's OIDC issuer URL and the specific system:serviceaccount:<namespace>:<name> subject — meaning the trust is scoped to one namespace and one service account, not the whole cluster. A single AKS node pool can run dozens of workloads, each with its own scoped federated credential, and none of them ever touch a client secret. This is a meaningfully tighter blast radius than the older pod-identity or secret-mounted approach, where a compromised node could often reach credentials belonging to unrelated workloads.
What Exactly Is Happening Under the Hood with Azure AD Federated Credentials?
Under the hood, Azure AD federated credentials are a trust configuration that maps an external token's issuer and subject claims to permission to request a real Azure AD token, validated entirely through public-key signature checks — no shared secret is exchanged at configuration time either. When a pod starts, the Azure Identity SDK (or the workload identity webhook, which mutates the pod spec automatically) projects a Kubernetes service account token into the container, valid for a configurable window (the default is 1 hour, with a 24-hour maximum). The application code calls Azure AD's token endpoint, presents that projected token, and Azure AD verifies it against the federated credential's registered issuer and subject before minting an Azure access token — typically valid for 60–90 minutes. If an attacker exfiltrates that access token, it expires quickly and cannot be reused to mint new tokens, unlike a stolen client secret, which remains valid until someone manually revokes it — often the gap that turns a minor compromise into a prolonged incident, as seen in the 2023 Storm-0558 case where a stolen Microsoft signing key was used to forge authentication tokens across customer tenants for weeks before detection.
What Breaks or Changes When You Migrate Off Static Secrets?
The main things that change are observability and dependency mapping, not application logic — most SDKs (Azure Identity libraries for .NET, Python, Java, Node, Go) already support DefaultAzureCredential or WorkloadIdentityCredential, so code changes are often limited to a constructor call. What genuinely changes is that security teams lose the one artifact they used to inventory service-to-service access: the client secret itself. Without a secret to find in Key Vault or a vault scan, teams need a live map of which federated credentials trust which issuers and subjects, and which of those are still actually in use. In practice, organizations running this migration across even a few hundred AKS workloads find drift quickly — stale federated credentials pointing at decommissioned namespaces, overly broad subject claims (a wildcard-like system:serviceaccount:<namespace>:* pattern some teams mistakenly configure), and app registrations that still have a lingering client secret alongside the new federated credential "just in case," which quietly reintroduces the exact risk the migration was meant to remove.
How Safeguard Helps
Safeguard treats the migration to Azure Workload Identity Federation as something to verify continuously, not deploy once and forget. Our platform inventories every Azure AD app registration and federated credential across your tenant, flags app registrations that still carry an active client secret or certificate alongside a federated credential (the "just in case" leftover that undoes the security benefit), and maps each federated credential's issuer/subject scope back to the specific AKS namespace, service account, or CI workflow that's authorized to use it — so overly broad subject claims get caught before they're exploited. Safeguard also correlates this identity graph with your software supply chain findings, so a compromised build pipeline or dependency is immediately checked against what Azure AD trust relationships it could reach. For teams that already eliminated service principal secrets in some workloads but not others, Safeguard's dashboards show exactly where legacy credentials remain, giving security and platform teams a prioritized, evidence-backed path to finishing the migration rather than a one-time audit that goes stale the next time someone spins up a new AKS namespace.