Workload Identity: Killing the Last Long-Lived Secret in AKS

Open the secrets in almost any maturing AKS cluster and you'll find them: a storage account key here, a service principal client secret there, a connection string that three teams now depend on and nobody remembers rotating. Each one is a quiet wager that it will never end up in a log, a laptop, or a Git history. You will not win every one of those bets forever.

Workload Identity is how you stop placing them.

The shift: present who you are, not what you know

The old model is shared-secret: your pod holds a credential, presents it to Azure, and Azure checks it against a stored copy. The whole security of the system rests on that secret staying secret: across rotation, across every developer who's ever run kubectl get secret, forever.

Workload Identity replaces that with federated trust. The chain looks like this:

1. Your pod runs as a Kubernetes service account.
2. That service account is annotated to map to an Entra ID (Azure AD) workload identity.
3. Kubernetes issues the pod a short-lived, signed service-account token.
4. The Azure SDK exchanges that token for an Entra ID access token, because you've configured a federated credential that says "I trust tokens for this service account, in this cluster's OIDC issuer."
5. The pod calls Azure with a real, expiring access token. No stored secret anywhere.

The credential the pod holds is valid for minutes and useless outside the cluster that issued it. There's nothing worth stealing.

Why this is worth the migration

• There is no secret to rotate. Rotation incidents, expiry outages, and "who has a copy of this key" questions simply stop existing for these paths.
• Blast radius collapses. A leaked short-lived token expires before it's useful and is scoped to one workload's identity, not a shared principal that can do everything.
• Access becomes legible. Permissions hang off named identities with Azure RBAC, so "what can this workload touch in Azure" is a query, not an archaeology project.

Migrating without a big-bang weekend

You don't rip out every secret at once. You drain the swamp one workload at a time.

1. Inventory. List every place a pod authenticates to Azure today: storage, Key Vault, databases, service buses. This list is usually longer than anyone expects, and the inventory alone is worth the exercise.
2. Enable the foundation. Turn on the OIDC issuer and the Workload Identity add-on for the cluster. This is additive; it changes nothing about existing workloads.
3. Cut over the easy, high-value ones first. Pick a workload reaching Key Vault or Storage. Create its managed identity, grant Azure RBAC, wire the federated credential and the service-account annotation, deploy, verify, and then delete the old secret. Deletion is the step that actually removes risk.
4. Make it the default. New workloads use Workload Identity by default. Static secrets become the exception that needs a justification.

The takeaway

Most cluster security work is about adding controls. This is about removing the thing the controls were protecting. A secret you've deleted can't leak, can't expire at 2 a.m., and can't show up in a breach report. Workload Identity isn't just better auth for AKS. It's a smaller attack surface, earned one deleted secret at a time.