R
rmmartins
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).
Before diving into the specifics of AKS, let’s clarify the two main types of managed identities in Azure:
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 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):
Explanation:
2. Grant ACR Access to the User Managed Identity (UMI):
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:
Replace
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:
This command updates the node pool of your AKS cluster to assign a UMI to it.
Best Practices for Identity Management in AKS
Troubleshooting Tips
Verify Role Assignments: Use the following command to ensure that the UMI has the appropriate permissions to access ACR:
Debugging Pod Identity: To check if a Pod Identity is correctly assigned, you can use:
This will show if the correct Entra AD Pod Identity Binding is applied to the pods.
Checklist for Configuring ACR Access:
If you’re asking yourself, “Where are the Service Principals in all of this?”, it’s a valid question! While this article focuses on Managed Identities (System Managed Identity, User Managed Identity, and Pod Identity) as the recommended approach for AKS, Service Principals are still commonly used in many Azure scenarios.
Service Principals are manual Entra ID identities typically used for backward compatibility or for applications that run outside of Azure. Here’s a quick overview of the key differences between Service Principals and Managed Identities:
Service Principals vs. Managed Identities
When to Use Service Principals?
While Managed Identities are recommended for most AKS scenarios due to their automation and security benefits, you might still want to use Service Principals when:
In most cases, it’s advisable to migrate to Managed Identities if your current setup still uses Service Principals. For more information on migrating to Managed Identities, check the official documentation.
Next Steps
Now that you've set up User Managed Identity and Pod Identity in AKS, here are a few recommendations for further exploration:
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.
Continue reading...
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):
Code:
# 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-keysExplanation:
- We create a User Managed Identity (UMI).
- The
--assign-identityflag assigns the UMI to both the control plane and the VMSS (node pool).
2. Grant ACR Access to the User Managed Identity (UMI):
Code:
# 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_IDIn 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:
Code:
# 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:v1Replace
<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:
Code:
# 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_IDThis 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 --allDebugging 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-identityflag. - 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.
Where Do Service Principals Fit In?
If you’re asking yourself, “Where are the Service Principals in all of this?”, it’s a valid question! While this article focuses on Managed Identities (System Managed Identity, User Managed Identity, and Pod Identity) as the recommended approach for AKS, Service Principals are still commonly used in many Azure scenarios.
Service Principals are manual Entra ID identities typically used for backward compatibility or for applications that run outside of Azure. Here’s a quick overview of the key differences between Service Principals and Managed Identities:
Service Principals vs. Managed Identities
| Feature/Scenario | Service Principal | System Managed Identity (SMI) | User Managed Identity (UMI) |
|---|---|---|---|
| Creation | Manually created using Azure CLI, Portal, or ARM | Automatically created and tied to the resource’s lifecycle | Manually created and managed independently of resources |
| Lifecycle | Independent of any specific resource | Tied to the resource (e.g., AKS cluster) | Independent, can be used across multiple resources |
| Management | Requires manual credential management (e.g., client secret) | Managed automatically by Azure | Managed automatically by Azure |
| Use Case | Legacy apps, multi-cloud, backward compatibility | Single resource, like an AKS cluster | Reusable identity for multiple resources or node pools |
| Security | Credentials (passwords/secrets) need secure storage | No credentials to manage | No credentials to manage |
| Example Scenario | Older AKS clusters or hybrid cloud setups | Authenticating AKS cluster to ACR | Sharing a single identity across VMSS or AKS node pools |
When to Use Service Principals?
While Managed Identities are recommended for most AKS scenarios due to their automation and security benefits, you might still want to use Service Principals when:
- Backward compatibility is needed for legacy AKS clusters.
- You are working in a multi-cloud or hybrid environment.
- Manual control over identity management is required (e.g., specific client IDs and secrets for programmatic use).
In most cases, it’s advisable to migrate to Managed Identities if your current setup still uses Service Principals. For more information on migrating to Managed Identities, check the official documentation.
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.
Continue reading...