Access and identity options for Azure Kubernetes Service (AKS)

Applies to: ✔️ AKS Automatic ✔️ AKS Standard

AKS uses identity in five distinct scenarios. Each scenario answers a different question and has its own configuration model.

For most production AKS workloads, AKS Automatic is the recommended default because it starts with a production-ready platform baseline, including identity-related defaults, while preserving the same AKS identity model described in this article.

This article gives a brief introduction to each scenario, explains how the guidance maps to AKS Automatic and AKS Standard, and points to the deep-dive documentation.

The five identity scenarios in AKS

Identity posture in AKS Automatic and AKS Standard

The five identity scenarios in this article apply to both AKS Automatic and AKS Standard. The main difference is operational posture:

• AKS Automatic provides more preconfigured identity and security defaults.
• AKS Standard provides more manual control and requires more setup choices.

Use AKS Automatic as the default starting point for most production workloads, and use AKS Standard when you need deeper custom platform configuration.

For an overview of AKS Automatic, see Introduction to Azure Kubernetes Service (AKS) Automatic.

AKS Automatic and AKS Standard identity posture comparison

The rest of this article gives a brief orientation to each scenario.

A. Kubernetes control-plane authentication

Kubernetes control-plane authentication establishes the identity of a user or service principal calling the Kubernetes API server. AKS supports:

• Microsoft Entra ID (recommended): Use Entra ID identities and groups to sign in to the cluster. Microsoft Entra integration provisions and rotates the integration on your behalf. To enable, see Use Microsoft Entra integration.
• Local accounts: A built-in cluster admin certificate that bypasses Entra ID. We recommend disabling local accounts in production. See Manage local accounts.
• External identity providers: Use an OIDC-compliant identity provider other than Microsoft Entra ID. See External identity provider authentication.

For most production workloads, start with AKS Automatic and Microsoft Entra integration.

For an in-depth look at how AKS authenticates Kubernetes API requests, see Cluster authentication concepts.

B. Kubernetes control-plane authorization

After a caller is authenticated to the Kubernetes API, AKS authorizes the request using one (or both) of two models:

• Kubernetes RBAC: The native Kubernetes Role, ClusterRole, and RoleBinding model evaluated by the API server. Permissions live in the cluster as Kubernetes objects.
• Microsoft Entra ID authorization: An AKS authorization webhook delegates authorization decisions to Microsoft Entra ID using Azure role assignments. Azure RBAC role assignments with dataActions are supported for all standard Kubernetes API resources, and role assignments with Azure ABAC conditions are supported for custom resources. Manage permissions centrally in Microsoft Entra ID to govern many clusters from a single role assignment at subscription, management group, or resource group scope.

In AKS Automatic, Azure RBAC for Kubernetes authorization is preconfigured as part of the production-ready default posture.

For a comparison and guidance on when to use each model, see Cluster authorization concepts.

C. AKS resource authorization (Azure Resource Manager)

In addition to authorizing calls to the Kubernetes API, you also need to authorize Azure-level operations on the AKS resource itself. The most common example is controlling who can pull a cluster's kubeconfig, which is a standalone Azure Resource Manager operation that you can govern granularly with Azure RBAC. This operation uses standard Azure RBAC against the Microsoft.ContainerService resource provider, is separate from Kubernetes API authorization, and applies the same way to AKS Automatic and AKS Standard. For more information, see Limit access to the cluster configuration file and the built-in roles in Azure built-in roles.

D. Cluster identity (cluster → Azure)

AKS clusters use Azure managed identities to act on Azure resources on your behalf — for example, to create load balancers, attach disks, or pull images from Azure Container Registry. The main identities are:

• Control-plane identity: Used by the cluster control plane to manage Azure resources for the cluster.
• Kubelet identity: Used by the kubelet on each node to authenticate to services such as Azure Container Registry.
• Add-ons/extensions identity: Some AKS add-ons and extensions use their own managed identities.

AKS Automatic keeps this same identity model while reducing setup friction through preconfigured production defaults.

For details on each identity type and how to use system-assigned vs user-assigned identities, see Managed identities in AKS.

E. Workload identity (pod → Azure)

Workload identity lets pods running in your AKS cluster authenticate to Microsoft Entra–protected Azure services (such as Key Vault, Storage, or Cosmos DB) without storing secrets in the cluster. AKS uses Microsoft Entra Workload ID, which projects a Kubernetes service account token federated to a Microsoft Entra application or user-assigned managed identity.

AKS Automatic includes workload identity and OIDC issuer as preconfigured defaults. In AKS Standard, these capabilities are optional and configured by the operator.

Don't use the deprecated Microsoft Entra pod-managed identity for new workloads.

Decision guide

AKS service permissions reference

For the Azure permissions that AKS uses (the identity that creates the cluster, the cluster identity at runtime, additional cluster identity permissions, and AKS node access), see AKS service permissions reference.

Related content

• Introduction to Azure Kubernetes Service (AKS) Automatic
• Create an Azure Kubernetes Service (AKS) Automatic cluster
• Cluster authentication concepts
• Cluster authorization concepts
• Use Microsoft Entra ID authorization for the Kubernetes API
• Managed identities in AKS
• Microsoft Entra Workload ID overview

For more information on core Kubernetes and AKS concepts, see the following articles:

• Kubernetes / AKS clusters and workloads
• Kubernetes / AKS security
• Kubernetes / AKS virtual networks
• Kubernetes / AKS storage
• Kubernetes / AKS scale