Understanding Identity Concepts in AKS

Azure Kubernetes Service (AKS) is designed to provide 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. But understanding the different types of identitySystem Managed Identity (SMI), User Managed Identity (UMI), and Pod ID—It can be difficult.

In this post, we’ll break down these identity concepts, walk you through 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 are managed identities in Azure?

Before we look at the details of AKS, let’s clarify the two main types of managed identities in Azure.

1. System Managed Identity (SMI): Automatically created and attached to the lifecycle of a resource (e.g. an AKS cluster). When a resource is deleted, the SMI is also deleted.
2. User Managed Identity (UMI): Created manually and independent of the resource lifecycle. UMIs persist until they are manually deleted and can be reused across multiple resources.

Identity types in AKS

Managed identities in AKS allow your cluster and its components to securely authenticate with Azure services such as ACR. Understanding how these identities interact with various resources is important for smooth cluster operation.

1. AKS System Managed Identity (SMI)

When you create an AKS cluster using a system managed identity (SMI), Azure creates an identity that is associated with the cluster’s lifecycle. However, the main limitation is that SMI is limited to the cluster itself. This means that the nodes in the virtual machine scale set (VMSS) running the cluster do not automatically inherit this ID.

Common pitfall: Many users mistakenly assign ACR permissions to SMIs in their cluster, assuming they will extend to the nodes. This causes access issues because the node responsible for pulling images cannot authenticate to ACR using the cluster’s SMI.

Workaround: Permissions must be assigned to the identity associated with the VMSS. This is where User Managed Identity (UMI) comes into play.

2. User Managed Identity (UMI) in AKS

User managed identities are created and managed manually. When applied to an AKS cluster, UMI is associated with the VMSS that manages the node, allowing that node to use its identity to authenticate to Azure services such as ACR.

Why UMIs are important: When setting up an AKS cluster to pull container images from ACR, you must assign the correct permissions to the UMIs associated with the node pool’s VMSS. This will allow your nodes to authenticate and pull the image without issue.

3. AKS Pod ID

Pod ID provides a much more granular level of access control. Pod IDs allow you to assign unique IDs to individual pods, allowing each pod to authenticate with various Azure resources, such as Key Vault or ACR.

Use case: Imagine you have one pod that needs to access ACR and another pod that needs to access Key Vault. Pod IDs allow you to assign a different ID to each pod to ensure that it accesses only the resources it needs.

Visual diagram: Understanding the identity flow in AKS

Below is a simple visual diagram explaining how System Managed Identity (SMI), User Managed Identity (UMI), and Pod ID work in AKS.

This diagram shows how managed identities connect to AKS clusters, VMSS, and Pods to provide secure access to Azure resources such as ACR and Key Vault.

Configure ACR access to AKS

Configuring Azure Container Registry (ACR) access to an AKS cluster is a common task, but users often mistakenly assign permissions to the wrong identity, such as the System Managed Identity (SMI). The correct approach is to use a User Managed Identity (UMI), which must be assigned to the virtual machine scale set (VMSS) that powers the AKS node pool.

Steps to configure ACR access to AKS:

1. Create an AKS cluster using 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:

• Create a User Managed Identity (UMI).
• that --assign-identity The flag assigns a 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, you grant the UMI the AcrPull role to allow it to pull container images from ACR.

3. Check permissions and test settings.

# 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=.azurecr.io/my-app:v1

change and my-app:v1 Use the actual ACR registry name and image version.

Update an existing AKS cluster

If you have an existing AKS cluster and need to add a User Managed Identity (UMI) to your 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  \
    --assign-identity $IDENTITY_RESOURCE_ID

This command updates the AKS cluster’s node pool to assign a UMI.

Identity Management Best Practices in AKS

• Do not use System Managed Identity (SMI) for node-level authentication. Always use User Managed Identity (UMI) for operations that require node-level permissions, such as pulling an image from ACR.
• Use Pod IDs if your workloads require granular access control to Azure resources such as Key Vault or ACR.
• Make sure the permission (e.g. AcrPull) is applied to the correct scope for the identity you are using.

Troubleshooting Tips

Check role assignment: Verify that UMI has appropriate permissions to access ACR using the following command:

az role assignment list --assignee $IDENTITY_CLIENT_ID --all

Debugging Pod ID: To check if the pod ID is assigned correctly, you can use:

kubectl get pods -o yaml | grep -i 'aadpodidentitybinding'

This will indicate whether the correct Entra AD pod ID binding has been applied to the pod.

Checklist for configuring ACR access:

• Make sure you are using User Managed Identity (UMI) for your node pool’s VMSS.
• During the cluster creation process, ensure that the UMI is assigned using: --assign-identity flag.
• Assign the AcrPull role to the UMI for ACR access.
• Verify role assignments and test your settings to ensure that your nodes can pull images from ACR.

next steps

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

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

final thoughts

Understanding the differences between system managed identities, user managed identities, and pod identities in AKS can help you effectively configure secure access to Azure resources such as ACR and Key Vault. Setting up UMI and Pod ID correctly is important to avoid common pitfalls that can lead to deployment issues.