If you are still mounting a Kubernetes Secret containing an AZURE_CLIENT_SECRET into your pods, you are one kubectl get secret -o yaml away from an incident report. And if you are using AAD Pod Identity, you are running a component that reached end of support in September 2023.

Azure Workload Identity replaces both. It uses the OIDC issuer built into your AKS cluster to let a Kubernetes ServiceAccount exchange its projected token for an Azure AD (Microsoft Entra ID) access token. No secret, no rotation job, no NodeManagedIdentity DaemonSet intercepting IMDS traffic.

This walkthrough takes about 45 minutes end to end, assuming you already have an AKS cluster and the Azure CLI installed.

The problem: static credentials are a liability

A typical "pre-Workload-Identity" deployment looks like this:

apiVersion : v1 kind : Secret metadata : name : app-azure-credentials namespace : payments type : Opaque stringData : AZURE_TENANT_ID : 00000000-0000-0000-0000-000000000000 AZURE_CLIENT_ID :…