Managed Identities in Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) heavily relies on Microsoft Entra (Azure AD) and Managed Identities to securely access and manage Azure resources on behalf of the cluster and its workloads — without managing secrets or credentials manually.

In this article, we’ll explore the two types of managed identities used in AKS, understand their roles and scopes, and learn how to configure and leverage them effectively following best practices.

There are two core types of Managed Identities associated with AKS :

1. 1. 1. Cluster Managed ID (Control Plane ID)
      2. Kubelet Managed ID (Node Pool ID)

---

1️⃣ Cluster Managed Identity (aka Control Plane Identity)

🔹 What It Is:

The Cluster Managed Identity is used by the AKS control plane to provision and manage Azure infrastructure on your behalf. It interacts with Azure services such as load balancers, managed disks, public IPs, and route tables — especially for operations initiated through Kubernetes APIs (e.g., creating a PersistentVolume using AzureDisk).

🔹 How It’s Created:

• • • • If you don’t specify anything, Azure automatically creates a System Assigned Managed Identity for your cluster.

      • You can optionally assign a User Assigned Managed Identity using --assign-identity when creating the cluster. The User Assigned Managed Identity that you are referring, should be created beforehand.

🔹 Common Use Cases:

• • • • Provisioning PersistentVolumes (PVs) with managed disks.

      • Managing Load Balancers, Public IPs, and Route Tables.

      • Handling node scale-up/down and VMSS-related operations.

Required RBAC Roles for Cluster Managed Identity

Use Case	Required Role	Target Scope
Provision PersistentVolumes with Azure Disks	Storage Account Contributor	Disk Resource or Subscription
Manage Load Balancers, NSGs, NICs	Network Contributor	AKS Node Subnet and ILB Subnet (if separate)
Control VMSS, Public IPs, NSGs, Disks	Contributor	AKS Managed Resource Group (MC_*)
Assign Kubelet Managed Identity	Managed Identity Operator	Kubelet Managed Identity (User Assigned)
Private DNS zone management (for Private Clusters)	Private DNS Zone Contributor	Private DNS Zone Resource

🔧 Important:

If your AKS cluster uses separate subnets for different components, you must ensure that the Kubelet Identity (or Cluster Managed Identity, depending on who manages the resource) has the Network Contributor role assigned to:

• • • The AKS Node Pool subnet (where VMs are provisioned)
    • The Pod subnet (if using Azure CNI with delegated subnet for pods)
    • The LB subnet, if Load Balancers are configured to use a separate dedicated subnet

Without proper permissions, network interface attachments or internal IP assignments may fail silently or result in cluster deployment/runtime issues.

---

2️⃣ Kubelet Managed Identity (aka Node Pool Identity)

🔹 What It Is:

This identity is used by the kubelet running on each node to interact directly with Azure resources. It enables workload-level operations like pulling container images from Azure Container Registry (ACR), mounting Azure Disks or Files, and accessing Key Vault secrets via CSI drivers.

🔹 How It’s Created:

• • • By default, AKS creates a system-assigned identity for each node pool.

    • You can override this with a User Assigned Identity using --assign-kubelet-identity.

Required RBAC Roles for Kubelet Managed Identity

Use Case	Required Role	Target Scope
Pull images from Azure Container Registry (ACR)	AcrPull	ACR Resource
Mount Azure Disks (via CSI Driver)	Reader or Contributor	Disk Resource or Subscription
Mount Azure Files	Storage File Data SMB Share Reader	Storage Account
Access Key Vault Secrets (via CSI Secret Store Driver)	Key Vault Secrets User	Key Vault

🔁 These roles must be manually assigned to the Kubelet identity. Make sure to follow the principle of least privilege.

---

🔧 Best Practice: Use Pre-Created User Assigned Managed Identities

As a recommended approach for production environments, you should:

• • Create two User Assigned Managed Identities in advance: one for the control plane and one for the kubelet (node pool).

  • Assign the required RBAC roles to these identities before cluster creation.

  • Use these identities explicitly in your AKS creation command or Terraform/Bicep/Pulumi scripts.

Example with Azure CLI:

az aks create \
  --name myAKS \
  --resource-group myRG \
  --enable-managed-identity \
  --assign-identity /subscriptions/xxx/resourcegroups/xxx/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myClusterIdentity \
  --assign-kubelet-identity /subscriptions/xxx/resourcegroups/xxx/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myKubeletIdentity

---

🎯 Advantages of This Approach

1. No Post-Deployment RBAC Confusion:

   • Roles like Network Contributor, Contributor, AcrPull, Key Vault Secrets User, etc. can be assigned in advance.

   • You avoid last-minute access issues or manual patch-ups after cluster creation.

2. Improved Visibility and Auditing:

   • Since these identities are user-assigned, you can see all assigned roles clearly in the Azure portal under the identity’s Permissions (IAM) blade.

3. Reusability Across Cluster Rebuilds:

   • If you ever need to delete and re-create the cluster (e.g., during a blue-green upgrade, AKS migration, or DR failover), you can reuse the same identities.

   • This preserves the permission model and avoids re-assigning roles from scratch.

⚠️ Known Limitation / Exception

There are a few roles that cannot be pre-assigned before cluster creation because the resource scope doesn’t exist yet. Examples include:

• • Access to the managed resource group created by AKS (usually named like MC_rg_clustername_location).

  • Any RBAC permission specific to dynamically created resources within the cluster’s lifecycle (e.g., specific disks, ILB IPs, node pools).

🛠️ These roles may need to be assigned just after cluster creation via automation or script hooks.

---

Viewing Managed Identities After AKS Deployment

Once the AKS cluster is created, the easiest way to view the associated identities is by running the following command:

az aks show --name <cluster-name> --resource-group <resource-group-name> --output json

This will return a detailed JSON output that includes:

• • identityProfile.kubeletidentity → Shows the Kubelet (node pool) identity

  • identityProfile.<default> → Shows the Cluster (control plane) identity

  • Whether the identity is system-assigned or user-assigned

  • Full resource IDs, client IDs, and object IDs of both identities

You can also confirm if the identities are shared or separate, and validate that the correct RBAC roles have been assigned by navigating to the Azure portal > Identity blade of each managed identity.

For System Assigned Identity

You’ll see a top-level field like:

"identity": {
  "type": "SystemAssigned"
}

This means Azure created a system-assigned managed identity tied to the cluster lifecycle.

For User Assigned Identity

You’ll see something like:

"identity": {
  "type": "UserAssigned",
  "userAssignedIdentities": {
    "/subscriptions/.../userAssignedIdentities/myClusterIdentity": {
      "clientId": "...",
      "principalId": "..."
    }
  }
}

And under identityProfile.kubeletidentity, you’ll see similar details for the Kubelet Identity (whether system or user-assigned).

For Both Cluster & Kubelet Identity Together

Look under the identityProfile section:

If resourceId is present → User Assigned
If it’s missing (or absent altogether) → likely System Assigned

---

🧵 How It All Ties Together (Example Flow)

Let’s say a pod running in AKS wants to pull a container image from Azure Container Registry (ACR):

1. 1. The kubelet identity is used to authenticate with Azure AD.

   2. Azure AD issues a token to the kubelet for ACR.

   3. The token is used to pull the image securely — no username/password needed.

   4. Role AcrPull must be assigned to the identity on the ACR scope.

Similarly, when using CSI to mount an Azure Disk:

• • The cluster identity may provision the disk.

  • The kubelet identity mounts the disk on the node.

---

🌐 A Brief Note on Workload Identity

Azure Workload Identity is a newer, more granular model that enables Kubernetes pods to access Azure resources using their own federated identity instead of relying on node-level kubelet identities.

• • • Integrates with Azure AD Workload Federation.

    • Supports identity at pod level (vs node level in Managed Identity).

    • Ideal for multi-tenant clusters or fine-grained RBAC.

ℹ️ While Workload Identity is a powerful evolution and works in conjunction with Azure AD and Managed Identity, it deserves a dedicated article of its own.

---

✅ Roles Summary

• Cluster Managed Identity (Control Plane)

• • Contributor – AKS Managed Resource Group (MC_*)
  • Network Contributor – Node, ILB, and Pod subnets
  • Storage Account Contributor – For disk provisioning
  • Private DNS Zone Contributor – For private clusters
  • Managed Identity Operator – On kubelet identity

 

• Kubelet Managed Identity (Node Pool)

• • AcrPull – On Azure Container Registry
  • Reader/Contributor – On managed disks (CSI)
  • Storage File Data SMB Share Reader – On storage account
  • Key Vault Secrets User – On Key Vault
  • Key Vault Secrets Officer – On specific secrets (CSI Rotation)

See Also

• • Use a managed identity in Azure Kubernetes Service (AKS)