Azure Kubernetes Service Workload Identity
- Nathan
- Jul 13
- 4 min read
AKS Workload Identity enables applications running in Azure Kubernetes Service (AKS) to securely access other Azure resources (KeyVault, Storage Account, .etc) by using EntraID, all without needing to manage service principal secrets.
Note: the previous version of this solution was called Pod-Managed Identities. Please do not use Pod-Managed Identities as it was deprecated in 2022.
There are a lot of parts involved in getting AKS Workload Identity up and running. I will do my best to outline everything below.
Installation & Configuration
Step 1 is to configure your AKS cluster. You must do 2 things: enable the OIDC Issuer, and enable Workload Identity. You can do this by running some Az CLI commands. If you prefer infrastructure as code, then I highlight the necessary ARM Template parameters that are required in the diagram above. After this is configured, your cluster will act as an OIDC Issuer, and it will get a special URL that will be used just for this purpose. It is important to capture this URL, as we will need it later.
Step 2 is to create a User-Assigned Managed Identity. Once created, capture the Client ID of the identity, as we will need this later. Also, assign the necessary RBAC roles to the identity. For example, if your app needs to access KeyVault, then you might want to assign the 'Key Vault Secrets User' role to the identity.
Step 3 is to create a Service Account in AKS. You must give the Service Account a special Annotation that points to the Client ID of the Identity that we created in Step 2.
Step 4 is to create a new Federated Credential on the Identity that we created in Step 2. The Credential must reference the Service Account we created in Step 3. The Credential must also reference the OIDC Issuer URL that we captured in Step 1.
Step 5 is the last step and involves updating your Application running in AKS. You must update the Kubernetes manifest for your app in 2 ways: you must add a special label that enables Workload ID, and you must add a special value to the 'spec' section that points at the Service Account that we created in Step 3. Last, but certainly not least, you must make sure your App is using one of the supported Azure Identity client libraries that support OIDC authentication.
Azure Service Connector
Service Connector is tool you can use to help you streamline connecting an Azure compute service (source) to a backing Azure service (destination), such as a database. Many compute services are supported, such as App Services, Container Apps, Functions, and AKS. Likewise, many backing services are supported, such as Azure Key Vault, Azure SQL Database, Azure Storage, and many more. See the docs for the full list of supported services.
Depending on the services you select, Service Connector will help you out in multiple different ways. For example, it may enable a Managed Identity for your compute service, and then grant an RBAC role for that identity on the selected backing service. It can also configure network settings so that each service can communicate. Lastly, if certain settings need to be configured on your compute service, then it will guide you on how to do that. For example, it may provide you environment variables that you must then configure on your source service, or it may give you links to sample code that you can use to update your source app, or it can even give you a yaml snippet to show you the changes that are needed for your app's Kubernetes manifest.
Connect an AKS Cluster to a KeyVault
Let's go over an example where we use Service Connector to connect an AKS Cluster with an Azure KeyVault. The AKS Cluster, the KeyVault, and the User-Assigned Managed Identity must already be created. In this example, we will be using Managed Identity for this connection, and not the Azure Key Vault provider for Secrets Store CSI Driver, which uses its own special identity.
With regards to this specific example and the 5 steps mentioned at the beginning of the article, Service Connector helps us in the following way:
Service Connector will automatically enable OIDC Issuer and Workload Identity on your AKS Cluster, if it is not already configured.
Service Connector will NOT create the managed identity for you. You must do this yourself before running Service Connector. However, Service Connector will automatically create a new RBAC role assignment on the KeyVault for the chosen managed identity and the chosen roles.
Service Connector will automatically create the Kubernetes Service Account in the given Namespace. Service Connector will make sure it has the necessary annotation which points it at the Client ID of the managed identity.
Service Connector will automatically create a new Federated Credential on the given managed identity. Service Connector will make sure it has the correct values for the OIDC Issuer URL as well as the Service Account.
Service Connector will not automatically update your app's source code. But, it will give you links to open the docs directly to some example code that you can reference. Also, Service Connector will NOT automatically update your app's Kubernetes manifest with the necessary values. However, it will give you a YAML snippet showing the changes that will need to be made (see screenshot below). Lastly, Service Connector will create a new Kubernetes Secret that contains the necessary values to connect your app with the KeyVault. If you use the YAML snippet, then the secrets will be mounted as environment variables inside your Kubernetes container.
A Warning About Automation
You can create connections in Service Connector by way of automation. The Azure Resource Manager reference can be found here: Microsoft.ServiceLinkers/linkers
But, a word of warning before you automate this. Service Connector is doing a lot of things to multiple different resources. In our example, it's enabling features on our AKS cluster as well as adding RBAC roles and network settings to our KeyVault. What happens if you manage that AKS cluster and KeyVault through separate automation code? Well, then you might run into a very confusing situation where 2 different automations are conflicting with each other. Microsoft even warns of this scenario in their documentation. So, please take caution in planning your deployments.