When deploying workloads in Kubernetes that use Azure resources, you will often need to authenticate against Azure Active Directory (AAD) to access these resources.
It is considered a best practice to use a Managed Identity and grant that identity access to the Azure resources your workload needs. Managed identities eliminate the need for developers to manage secrets, credentials, certificates and keys that would be required to access these Azure resources.
Both AAD Pod Identity and AAD Workload Identity are AKS features that allow your workloads to get AAD access tokens as a user-assigned managed identity. This means the workload can use the token to access the Azure resources to which the managed identity has been granted access.
So now that you know why you should be using one of these two mechanisms, the question remains: why would you use AAD Workload Identity specifically? And why bother migrating towards it, if you are already using AAD Pod Identity? Find out in the next section! 👉
Why migrate from AAD Pod Identity to AAD Workload identity?
Azure Active Directory (AAD) Pod Identity is a preview feature that has been officially deprecated (since 24/10/2022). AAD Workload Identity is the newer, preferred way of working (and was marked as generally available on 17/04/2023), and this has several advantages over AAD Pod Identity:
- Integrates with native Kubernetes capabilities instead of relying on Custom Resource Definitions
- Improved scaling and performance compared to AAD Pod Identity
- More straightforward installation process
- Supports both Linux and Windows workloads (AAD Pod Identity only supported Linux workloads)
In short, if you are writing applications that use Azure resources that you are deploying on an AKS cluster, and you want to leverage the benefits of managed identity, you should use AAD workload identity.
How to migrate to AAD Workload Identity
The following steps make a couple of assumptions:
- You have an AKS server running, with AAD pod identity enabled (this means you have the
aks-previewextension enabled, and are using theEnablePodIdentityPreviewfeature). - You are already using a user-assigned managed identity, which is linked to a pod identity.
We start off by updating our AKS cluster to publish the OIDC documents, and enable workload identity. We save the OIDC issuer url for later use.
Now we can create a federated credential, which is at the heart of workload identity. It’s these credentials that form the link between the service account used by our workload, and the user-assigned managed identity.
If you are already using service account resources, you’ll have to add the azure.workload.identity/client-id and azure.workload.identity/use annotations. If you aren’t using service accounts yet, add them for each workload that is linked to a user-assigned managed identity.
See the example below:
Your current workload should also be adapted: you’ll have to add the azure.workload.identity/use label, as well as the serviceAccountName property to the pod template.
You can remove the aadpodidbinding label: this is AAD pod identity specific and will no longer be used.
💡 If you have a container on a workload that does not have access to the latest Azure Identity SDKs, but still relies on IMDS to get an access token, you can add a azure.workload.identity/inject-proxy-sidecar and azure.workload.identity/proxy-sidecar-port label. These labels will add a proxy sidecar to your pods that will convert the IMDS transactions that your applications make to OIDC.
Verify that your pods can still access AAD-protected resources linked to the user-assigned managed identity. As an additional step, you could start a bash session on the container, and verify if the federated token file was projected to your pod:
If everything seems in order, and you have completed the above steps for all workloads using AAD pod identity, you can delete the pod identity from your AKS cluster:
Conclusion
In this post, we explained why you would use AAD Workload Identity in the first place, and what advantages it offers when compared to AAD Pod Identity.
We went over the steps required to migrate from AAD Pod Identity to AAD Workload Identity, and we had a look at some practical examples of what needs to be adapted. We also reflected on some limitations and attention points.
We hope you enjoyed this article, and that it has helped you to understand what AAD Workload Identity is, and how you can migrate to it. If you still have any questions, feel free to get in touch with us, and consider subscribing to our RSS feed so you don’t miss out on future articles.
Click on the link below to subscribe 👇
Subscribe to our RSS feed
Talk to the author
Contact Dries
Consultant