Skip to main content
Version: 2.10.0

Step 4 - Enable your AKS cluster to access Key Vault

There are two methods for authentication; select the one which applies to you:

4A - Managed Identity​

  • If your AKS cluster was not created with Managed Identities, this can be added via:
az aks update -g ${rgp} -n ${aksname} --enable-managed-identity

To sync Key Vault secrets to Kubernetes secrets, the AKS kubelet identity needs get and list access to Key Vault.

  • First, retrieve the Object ID of kubelet's managed identity passing in your resource group and AKS cluster name:
az aks show -g "${rgp}" -n "${aksname}"

  • This will return a large JSON response. Scroll through this response and find the element "identityProfile/kubeletidentity" - you need the objectID value.

  • Now set the policy to allow the managed identity access (get, list) to the Key Vault - replacing ${kvname} with the Key Vault name and ${objectid} with the Object ID retrieved:

az keyvault set-policy --name "${kvname}" --object-id "${objectid}" --secret-permissions get list

OR

4B - Service Principal​

If you are using a Service Principal to manage access between your AKS cluster and external resources, you will need the objectId,appId, and associated clientSecret as the service principal needs to be given access to the Key Vault. These values can be found in Azure Active Directory.

Note: if using a Service Principal associated with an App Registration, you should use the objectid associated with the corresponding Enterprise Application. See this article for more information.

az keyvault set-policy --name ${kvname} --object-id "${objectid}" --secret-permissions Get List

With the service principal now authorized, a secret ('keyvault-service-principal') is created within the cdrplatform namespace which is then used by the components connecting to key vault:

kubectl create secret generic keyvault-service-principal --from-literal=ClientID=${appid} --from-literal=ClientSecret=${clientsecret}