Workload ID, Part 1: How To Authenticate to Azure Without Secrets

Secrets in your Kubernetes setup can often feel like a necessary evil. Client secrets and certificates that you constantly need to rotate and keep secure, credentials that might leak or end up in your Git history… It’s not only cumbersome and high-risk, but also a serious security vulnerability.  

Fortunately, there’s an alternative for AKS: Microsoft Entra Workload ID. This approach lets your AKS applications securely authenticate to Azure without long-lived secrets. The federated workload functionality also exists for other providers, but in this blog, we will focus on the Azure solution. 

Since there’s quite a bit to cover, we’ve split this blog post into two parts. In this first part, we’ll explain the basics: why traditional secrets are problematic and how the mechanism behind Workload ID fundamentally works. In part 2, we’ll dive deeper into the practical configuration, best practices, and concrete benefits. 

Why are secrets not a good idea (anymore)? 

Previously, there were two ways to secure communication between Azure components: client secrets or certificates, both linked to an Entra ID App Registration. However, both options also create headaches: 

• Both secrets and certificates have a limited lifespan and need to be replaced (rotated) regularly. This is a manual or complex automated process and is therefore easily forgotten. 
• If a secret or certificate leaks, an attacker could gain access to your Azure resources. Who has the key and when was it last replaced? It’s easy to lose track in a complicated setup. 
• In a modern GitOps setup, you want to manage your entire cluster configuration in Git. But checking secrets or certificates into Git is an absolute no-go. Once in the version history, they are potentially compromised forever. 

For a while, there was a third option: AAD Pod Managed Identity. However, that solution is now deprecated and Microsoft discourages its use for new deployments. So, the old methods are cumbersome, insecure, and don’t fit well with modern development workflows. What’s the alternative? 

The solution: Workload ID explained 

Microsoft Entra Workload ID (formerly known as Azure AD Workload ID) offers a handy solution to all those problems. It lets you authenticate AKS workloads to Azure resources without having to manage secrets or certificates yourself. 

How? By establishing a trust relationship between your AKS cluster and Microsoft Entra ID (formerly Azure AD). This is achieved using a standard protocol called OpenID Connect (OIDC).  

You can think of it as a kind of digital introduction: your AKS cluster has a built-in “identity card” issuer (the OIDC Issuer). You configure Entra ID to trust this issuer for specific workloads. Then, when your workload attempts to authenticate to Entra ID using an “identity card” (a token) from this AKS OIDC Issuer, Entra ID does the following: 

1. It verifies that the token genuinely originates from the claimed issuer. 
2. It compares its configuration with the information contained in the token. 
3. It issues an access token to the workload. 

The result: your application gains access to Azure resources for which the linked identity is authorised, without any secrets needing to be stored or managed anywhere. 

The “token dance”: how does it work under the bonnet? 

The concept of a trust relationship sounds good, but how exactly does it work technically? It is a clever interplay between different components, constantly exchanging information. 

Azure	AKS
User Assigned Managed Identity (or App Registration)	OIDC issuer
Federated Credentials	Service Account
Entra ID	Kubelet & Workload ID Webhook

1. AKS OIDC Issuer 
   Once activated, your AKS cluster has a built-in OpenID Connect (OIDC) issuer. This can issue special, short-lived tokens for service accounts within the cluster.
2. Kubernetes Service Account 
   Your pod runs under a specific Kubernetes Service Account. This acts as your pod’s “identity” within the cluster.
3. User-Assigned Managed Identity or App Registration 
   In Azure, you create a User-Assigned Managed Identity (or an App Registration, as these also support federated credentials). This becomes the “identity” of your workload in Azure. You can also opt for App Registration here, as this also supports federated credentials.
4. Federated Credential 
   This is the crucial link between AKS and Entra ID, where you define:
   1. The URL of your specific AKS cluster’s OIDC Issuer.
   2. The namespace where the Kubernetes Service Account resides.
   3. The name of the Kubernetes Service Account. 
   4. A subject identifier (usually automatically generated) that is unique to this combination.
5. Kubelet & Service Account Token Volume Projection
   When your pod starts (and has the correct label), the following occurs:
   1. The Kubelet (the agent on each AKS node), assisted by the Workload ID mutating webhook, requests a Service Account (SA) token from the AKS OIDC Issuer, specific to the pod’s Service Account. 
   2. The Kubelet then injects the token received from the OIDC issuer into the pod at a predefined, configured location.
6. Entra ID verification 
   Entra ID receives the SA Token and verifies the following: 
   1. Who: For which namespace and Service Account was the token issued? 
   2. What: Is the token valid? Does it genuinely originate from the claimed issuer? 
   3. When: When was the token created, and is it still valid?
   4. Where: Where does the token originate? In other words, who is the issuer?
7. Azure AD token issuance
   If everything checks out, Entra ID returns a standard Azure AD access token to the workload, just as if the User-Assigned Managed Identity had authenticated itself. Once returned by Azure, this token is cached by the application
8. Automatic refresh
   The Kubelet monitors the Service Account token’s expiry date and automatically requests a new one from the OIDC issuer. This happens well before the current token expires – by default, after 80% of its validity period has elapsed. 

The beauty of this is that your application code usually doesn’t need to be aware of any of it. If you use modern Azure SDKs, they automatically detect the presence of the projected token and use it for authentication. Image source

What’s next? 

So, Workload ID offers an elegant solution to a complex problem. By establishing a trust relationship between your AKS cluster and Entra ID, you can authenticate securely without the hassle and risks of long-lived secrets. The OIDC federation and token exchange mechanism ensures secure and largely automatic handling behind the scenes. 

Now that you understand what Workload ID is and how it works conceptually, you’re ready for the next step. In part 2 of this blog post, we’ll we’ll walk you through the concrete configuration steps in Azure and Kubernetes and discuss the key considerations and best practices.