Azure Kubernetes Service (AKS) is designed to offer flexibility and scalability while maintaining a secure environment. One of its key features is managed identities, which allow resources to authenticate and interact with other Azure services. However, understanding the different types of identities—System Managed Identity (SMI), User Managed Identity (UMI), and Pod Identity—can be challenging.

In this post, we’ll break down these identity concepts, explore how each works, and provide a visual guide to help you configure them correctly for tasks like granting access to Azure Container Registry (ACR).

What is a Managed Identity in Azure?

Before diving into the specifics of AKS, let’s clarify the two main types of managed identities in Azure:

System Managed Identity (SMI): Automatically created and tied to the lifecycle of a resource (such as an AKS cluster). The SMI is deleted when the resource is deleted.
User Managed Identity (UMI): Manually created and independent of any resource lifecycle. UMIs persist until manually deleted and can be reused across multiple resources.

Identity Types in AKS

In AKS, managed identities allow the cluster and its components to securely authenticate with Azure services such as ACR. Understanding how these identities interact with various resources is crucial for seamless cluster operations.

1. System Managed Identity (SMI) in AKS

When you create an AKS cluster with a System Managed Identity (SMI), Azure generates an identity tied to the cluster’s lifecycle. However, the key limitation is that the SMI is restricted to the cluster itself, meaning that the nodes in the Virtual Machine Scale Sets (VMSS) that power the cluster do not inherit this identity automatically.

Common Pitfall: Many users mistakenly assign ACR permissions to the cluster’s SMI, assuming it will extend to the nodes. This causes access issues because the nodes (responsible for pulling images) cannot authenticate with ACR using the cluster’s SMI.

Solution: Permissions need to be assigned to the identity tied to the VMSS. This is where User Managed Identity (UMI) comes into play.

2. User Managed Identity (UMI) in AKS

A User Managed Identity is created and managed manually. When applied to an AKS cluster, the UMI is associated with the VMSS that manages the nodes, allowing those nodes to use the identity to authenticate with Azure services, such as ACR.

Why UMI is Important: If you’re setting up your AKS cluster to pull container images from ACR, ensure that you assign the correct permissions to the UMI associated with the node pool’s VMSS. This guarantees that the nodes can authenticate and pull images without any issues.

3. Pod Identity in AKS

Pod Identity offers an even more granular level of access control. With Pod Identity, you can assign unique identities to individual pods, allowing each pod to authenticate with different Azure resources, such as Key Vault or ACR.

Use Case: Imagine you have one pod that needs access to ACR and another that needs access to Key Vault. With Pod Identity, you can assign different identities to each pod, ensuring they only access the resources they need.

Visual Diagram: Understanding Identity Flow in AKS

Here’s a simple visual diagram to illustrate how System Managed Identity (SMI), User Managed Identity (UMI), and Pod Identity work in AKS:

This diagram shows how managed identities are tied to the AKS cluster, VMSS, and pods, providing secure access to Azure resources like ACR and Key Vault.

Configuring ACR Access for AKS

Configuring Azure Container Registry (ACR) access for AKS clusters is a common task, but users often mistakenly assign permissions to the wrong identity, usually the System Managed Identity (SMI). The correct approach is to use a User Managed Identity (UMI), which should be assigned to the Virtual Machine Scale Set (VMSS) that backs the AKS node pool.

Steps to Configure ACR Access for AKS:

1. Create an AKS Cluster with a User Managed Identity (UMI):

# Variables
RESOURCE_GROUP=”myResourceGroup”
AKS_CLUSTER_NAME=”myAKSCluster”
LOCATION=”eastus”
IDENTITY_NAME=”myUserManagedIdentity”
ACR_NAME=”myACR”

# Create a User Managed Identity (UMI)
az identity create –name $IDENTITY_NAME –resource-group $RESOURCE_GROUP –location $LOCATION

# Get the UMI’s client ID and resource ID
IDENTITY_CLIENT_ID=$(az identity show –name $IDENTITY_NAME –resource-group $RESOURCE_GROUP –query ‘clientId’ -o tsv)
IDENTITY_RESOURCE_ID=$(az identity show –name $IDENTITY_NAME –resource-group $RESOURCE_GROUP –query ‘id’ -o tsv)

# Create the AKS cluster and assign the UMI to the cluster and node pool (VMSS)
az aks create
–resource-group $RESOURCE_GROUP
–name $AKS_CLUSTER_NAME
–location $LOCATION
–enable-managed-identity
–assign-identity $IDENTITY_RESOURCE_ID
–node-count 3
–generate-ssh-keys

Explanation:

We create a User Managed Identity (UMI).
The –assign-identity flag assigns the UMI to both the control plane and the VMSS (node pool).

2. Grant ACR Access to the User Managed Identity (UMI):

# Get the ACR resource ID
ACR_ID=$(az acr show –name $ACR_NAME –resource-group $RESOURCE_GROUP –query “id” -o tsv)

# Assign the ‘AcrPull’ role to the UMI
az role assignment create
–assignee $IDENTITY_CLIENT_ID
–role AcrPull
–scope $ACR_ID

In this step, we grant the AcrPull role to the UMI, allowing it to pull container images from ACR.

3. Verify Permissions and Test the Setup:

# List role assignments to verify the UMI has the correct permissions
az role assignment list –assignee $IDENTITY_CLIENT_ID –all

# Deploy a sample workload to test ACR access
kubectl create deployment my-app –image=<your-acr-name>.azurecr.io/my-app:v1

Replace <your-acr-name> and my-app:v1 with your actual ACR registry name and image version.

Updating an Existing AKS Cluster

If you have an existing AKS cluster and need to add a User Managed Identity (UMI) to the node pool, you can update it using the following command:

# To update an existing AKS node pool to use a UMI:
az aks nodepool update
–resource-group $RESOURCE_GROUP
–cluster-name $AKS_CLUSTER_NAME
–name <nodepool-name>
–assign-identity $IDENTITY_RESOURCE_ID

This command updates the node pool of your AKS cluster to assign a UMI to it.

Best Practices for Identity Management in AKS

Avoid using System Managed Identity (SMI) for node-level authentication. Always use User Managed Identity (UMI) for tasks requiring node-level permissions, such as pulling images from ACR.
Use Pod Identity when your workloads need granular access control for Azure resources like Key Vault or ACR.
Ensure that permissions (such as AcrPull) are applied at the correct scope for the identity being used.

Troubleshooting Tips

Verify Role Assignments: Use the following command to ensure that the UMI has the appropriate permissions to access ACR:

az role assignment list –assignee $IDENTITY_CLIENT_ID –all

Debugging Pod Identity: To check if a Pod Identity is correctly assigned, you can use:

kubectl get pods -o yaml | grep -i ‘aadpodidentitybinding’

This will show if the correct Entra AD Pod Identity Binding is applied to the pods.

Checklist for Configuring ACR Access:

Ensure you are using a User Managed Identity (UMI) for the node pool’s VMSS.
During the cluster creation process, make sure the UMI is assigned using the –assign-identity flag.
Assign the AcrPull role to the UMI for ACR access.
Verify the role assignment and test the setup to confirm that the nodes can pull images from ACR.

Next Steps

Now that you’ve set up User Managed Identity and Pod Identity in AKS, here are a few recommendations for further exploration:

Explore more Pod Identity use cases with Azure Key Vault and other Azure services.
Implement Azure AD Pod Identity for workloads that need granular, pod-level access to Azure resources.
Scale this setup for multi-region AKS clusters and investigate how AKS networking can be integrated with identity management.

Final Thoughts

By understanding the differences between System Managed Identity, User Managed Identity, and Pod Identity in AKS, you can effectively configure secure access to Azure resources like ACR and Key Vault. Correctly setting up the UMI and Pod Identity is key to avoiding common pitfalls that could lead to deployment issues.

​Microsoft Tech Community – Latest Blogs –Read More