Azure Kubernetes Service (AKS) offers flexibility and scalability for containerized workloads, but identity management can be complex. Choosing the right identity type—System Managed Identity (SMI), User Managed Identity (UMI), Entra ID Workload Identity, or Service Principals—is critical for secure operations. Misconfigurations can lead to security issues or connectivity failures, making it essential to understand the differences and use cases for each type. This article aims to clarify these identity concepts and guide you through configuring them correctly.
What are Managed Identities and Service Principals in Entra ID?
Before diving into the specifics of AKS, let’s clarify the primary identity options:
1. Managed Identities: Created and managed by Azure, managed identities authenticate resources to access other Azure services without requiring explicit credentials. There are two types:
- 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.
2. Service Principals: Entra ID objects manually created to support legacy applications and external workloads. Service Principals rely on credentials like client IDs and secrets, making them more complex to manage and prone to security risks.
Summary:
| Feature | Managed Identities (SMI & UMI) | Service Principals |
|---|---|---|
| Creation & Management | Automatically managed by Azure | Manually created and managed |
| Authentication Method | Azure-managed tokens (no secrets) | Client ID & Secret |
| Security Risk | Low (no secrets) | High (secrets must be handled) |
| Best For | Azure-native workloads | Legacy apps or external access |
References:
Note on Why Managed Identities are Preferred
Managed Identities eliminate the need for manual secret management, reducing the risk of credential leaks. They are Azure-managed, simplifying the lifecycle and permission management, making them the recommended choice for most AKS scenarios. For more detailed guidance, see Migrate from Service Principals to Managed Identities.
Identity Options 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, Microsoft Entra ID automatically generates an identity tied to the cluster’s lifecycle. However, it’s important to note that VMSS nodes do not inherit this identity automatically, causing issues when trying to access services like ACR.
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 should be assigned to the identity tied to the VMSS, which is where User Managed Identity (UMI) comes into play.
2. User Managed Identity (UMI) in AKS
A manually created identity that persists independently of any resource lifecycle. In AKS, the UMI can be associated with the VMSS nodes, providing secure access to ACR and other Azure resources.
Why UMI is Important:
If you’re configuring your AKS cluster to pull container images from ACR, you must ensure the UMI has the correct permissions, specifically the AcrPull role.
3. Entra ID Workload Identity
Important: Pod Identity is being deprecated in favor of Entra ID Workload Identity. Microsoft recommends using Workload Identity for new deployments and migrating existing Pod Identity implementations.
Entra ID Workload Identity provides an integrated and simplified approach for managing pod-level identities. It uses Kubernetes Service Accounts natively, and eliminates the need for a separate identity controller, allowing seamless and secure communication between pods and Entra ID resources.
Use Case:
Ideal when specific pods need granular access to Azure resources (e.g., Key Vault, ACR).
Why Choose Workload Identity?
- Native Integration: Uses standard Kubernetes service accounts.
- Simplified Management: No custom identity controllers or bindings.
- Improved Security: Kubernetes service account tokens are used directly for authentication.
For details on migrating from Pod Identity to Workload Identity, refer to the Entra ID Workload Identity Migration Guide.
4. Service Principals in AKS
Service Principals are another identity option used in AKS, especially for legacy clusters or for specific scenarios requiring manual management of credentials. They are manually created and managed, often used for programmatic access by external applications and services.
When to Use Service Principals:
- If you need backward compatibility for legacy AKS clusters.
- When applications running outside of Azure need direct access to Entra ID resources.
- For multi-cloud or hybrid scenarios requiring manually managed client IDs and secrets.
Visual Diagram: Understanding Identity Flow in AKS
Below is a visual diagram to illustrate how System Managed Identity (SMI), User Managed Identity (UMI), and Entra ID Workload Identity work in AKS, and how they are used to access Azure resources like ACR and Key Vault.
This diagram shows how managed identities are tied to the AKS cluster, VMSS, and pods, providing secure access to key resources.
Configuring ACR Access Using User Managed Identity (UMI)
This section guides you through the steps needed to set up Azure Container Registry (ACR) access using a User Managed Identity (UMI). It covers creating a UMI, linking it to an AKS cluster, and granting it the AcrPull role. By using a UMI, you ensure secure, node-level authentication for pulling container images without handling credentials, reducing security risks. This approach is ideal for persistent identity scenarios across multiple services and resources.
1. Define the Resource Group and Identity Parameters:
# Define variables for Resource Group, Identity, and Location
RESOURCE_GROUP="myResourceGroup"
IDENTITY_NAME="myUserManagedIdentity"
LOCATION="eastus"
2. Create the User Managed Identity (UMI):
# Create a UMI in the specified Resource Group
az identity create --name $IDENTITY_NAME --resource-group $RESOURCE_GROUP --location $LOCATION
3. Assign the UMI to the AKS Cluster:
# Fetch the UMI's Resource ID
IDENTITY_RESOURCE_ID=$(az identity show --name $IDENTITY_NAME --resource-group $RESOURCE_GROUP --query 'id' -o tsv)
# Create the AKS cluster with the UMI linked to the VMSS (node pool)
AKS_CLUSTER_NAME="myAKSCluster"
az aks create --resource-group $RESOURCE_GROUP --name $AKS_CLUSTER_NAME --enable-managed-identity --assign-identity $IDENTITY_RESOURCE_ID --node-count 3 --generate-ssh-keys
4. Grant the AcrPull Role to the UMI:
# Get the ACR resource ID and assign the `AcrPull` role to the UMI
ACR_NAME="myACR"
ACR_ID=$(az acr show --name $ACR_NAME --resource-group $RESOURCE_GROUP --query "id" -o tsv)
az role assignment create --assignee $IDENTITY_RESOURCE_ID --role AcrPull --scope $ACR_ID
Configuring ACR Access with Entra ID Workload Identity
This section explains how to securely configure ACR access for AKS pods using Entra ID Workload Identity. By leveraging Kubernetes service accounts, you can map Entra ID identities to individual pods without needing manual credentials. This approach simplifies identity management while providing granular access control at the pod level, ensuring that each workload can access ACR independently. Ideal for teams looking to implement Kubernetes-native identity management with improved security and integration.
1. Create a Service Account for Workload Identity:
# Step 1: Create a namespace and a service account for workload identity
kubectl create namespace my-namespace
kubectl create serviceaccount workload-identity-sa --namespace my-namespace
2. Annotate the Service Account:
# Step 2: Annotate the service account with the managed identity client ID
kubectl annotate serviceaccount workload-identity-sa \
--namespace my-namespace \
azure.workload.identity/client-id=<your-managed-identity-client-id>
3. Assign the AcrPull Role to the Workload Identity:
# Step 3: Grant the AcrPull role to the workload identity for ACR access
az role assignment create --assignee <your-managed-identity-client-id> \
--role AcrPull --scope <your-acr-resource-id>
4. Deploy a Pod Using the Service Account:
# Step 4: Update the deployment to use the annotated service account
apiVersion: v1
kind: Pod
metadata:
name: acr-access-pod
namespace: my-namespace
spec:
serviceAccountName: workload-identity-sa
containers:
- name: my-container
image: <your-acr-name>.azurecr.io/my-app:v1
Choosing the Right Identity Approach for AKS
When configuring ACR access in AKS, selecting the appropriate identity method depends on your access needs:
-
User Managed Identity (UMI): Ideal for scenarios requiring node-level permissions, where every node in the cluster can access the ACR.
-
Entra ID Workload Identity: Provides more granular, pod-level permissions, enabling different applications within the cluster to access ACR with unique identities.
Use UMI if node-wide permissions are sufficient and Entra ID Workload Identity for more secure, isolated access at the pod level.
Decision Criteria: Choosing Between UMI and Entra ID Workload Identity
To help select the right identity configuration for your AKS cluster, consider the following criteria:
| Criteria | User Managed Identity (UMI) | Entra ID Workload Identity |
|---|---|---|
| Permission Scope | Node-level (all pods on the node share the same permissions) | Pod-level (each pod can have a unique identity) |
| Security Isolation | Suitable for simpler use cases with broad access needs | Recommended for multi-tenant or multi-app scenarios needing isolation |
| Complexity | Easier to implement and manage | More complex but offers higher security and flexibility |
| Use Case | Homogeneous workloads, testing environments | Production environments, different apps with varying permissions |
| Integration | Supports existing workloads without additional changes | Ideal for applications using Kubernetes-native authentication |
Key Takeaways for ACR Configuration
- Use User Managed Identity (UMI) for node-level access to ACR.
- Use Entra ID Workload Identity for granular, pod-level authentication.
- Always validate that the
AcrPullrole is correctly assigned.
Best Practices for Identity Management in AKS
- Use User Managed Identity (UMI) for node-level authentication instead of System Managed Identity (SMI) to enhance flexibility and security.
- Adopt Workload Identity for Kubernetes-native pod-level authentication, offering granular access control to individual Azure services.
- Review Permissions Regularly: Periodically audit identities to avoid over-permissioning.
- Migrate to Managed Identities: Replace Service Principals with Managed Identities whenever possible for better security.
- Minimize Identity Scope: Grant the least privilege needed for both node and pod identities.
- Use Azure Policies: Apply policies to enforce consistent identity configurations across the cluster.
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.
Comparison Table: Service Principals vs. SMI, UMI, and Entra ID Workload Identity
|
Feature |
Service Principals |
System Managed Identity (SMI) |
User Managed Identity (UMI) |
Entra ID Workload Identity |
|
Definition |
Entra ID object manually created to access resources. |
Automatically generated identity tied to resource. |
Manually created and reusable across multiple resources. |
Kubernetes-native identity tied to service accounts. |
|
Creation & Management |
Manual creation and lifecycle management. |
Created automatically when resource is provisioned. |
Manually created and managed; independent of resources. |
Uses service account annotations in Kubernetes. |
|
Authentication Method |
Client ID and Secret or Certificate. |
Uses Azure-managed tokens, no secret management. |
Uses Azure-managed tokens, no secret management. |
Uses Kubernetes service account tokens. |
|
Lifecycle |
Manually managed; requires secret rotation. |
Tied to the lifecycle of a specific resource. |
Independent of resource lifecycle; persists until deleted. |
Independent of resource lifecycle, integrated at the pod level. |
|
Permissions Scope |
Scoped to any Azure service, manual management. |
Limited to the lifecycle of a single resource (e.g., AKS). |
Can be shared across multiple Azure services and VMs. |
Scoped to individual pods or Kubernetes service accounts. |
|
Granularity |
High (supports complex role assignments). |
Low (applies to a single resource). |
High (shared identity across multiple resources). |
Very High (pod-level access with unique identities). |
|
Integration |
Requires manual integration with Azure resources. |
Automatically integrated with resource lifecycles. |
Can be manually linked to multiple resources. |
Native integration with Kubernetes service accounts. |
|
Security Risk |
High (requires secret management). |
Low (no secret exposure; automatic lifecycle management). |
Low (no secret exposure; automatic lifecycle management). |
Low (leverages Kubernetes-native authentication). |
|
Configuration Complexity |
High (manual setup and secret management). |
Low (automatic; no secret exposure). |
Moderate (manual creation but automatic management). |
Low (Kubernetes-native configuration). |
|
Recommended Usage |
Legacy apps, external services, or multi-cloud setups. |
Short-lived resources needing resource-specific access. |
Shared resources, VMSS, AKS clusters needing persistent identities. |
Per-pod secure access to Entra ID resources in AKS clusters. |
Key Takeaways
- Use SMI for scenarios where the identity needs to match the lifecycle of a single resource, such as a short-lived AKS cluster or VM.
- Use UMI for shared resources or long-lived applications that need consistent access to multiple Azure services.
- Choose Entra ID Workload Identity for pod-level access in Kubernetes clusters, offering the most granular control.
- Avoid Service Principals unless you require backward compatibility or are working in a multi-cloud/hybrid scenario where Managed Identities are not supported.
Next Steps
- Review your existing identity configuration in AKS.
- Migrate from Service Principals to Managed Identities wherever possible.
- Adopt Entra ID Workload Identity for granular, pod-level access.
By choosing the right identity approach for your AKS clusters, you can ensure seamless access, enhanced security, and simplified management for your Kubernetes workloads.
Final Thoughts
By understanding the differences between System Managed Identity, User Managed Identity, Entra ID Workload Identity, and Service Principals in AKS, you can effectively configure secure access to Azure resources like ACR and Key Vault. Correctly setting up the UMI and Workload Identity is key to avoiding common pitfalls that could lead to deployment issues.
Microsoft
