Best practices for authentication and authorization in Azure Kubernetes Service (AKS)

As you deploy and maintain clusters in Azure Kubernetes Service (AKS), you implement ways to manage access to resources and services. Without these controls:

• Accounts could have access to unnecessary resources and services.
• Tracking credentials used to make changes can be difficult.

In this article, we discuss what recommended practices a cluster operator can follow to manage access and identity for AKS clusters. You'll learn how to:

Use Microsoft Entra ID

Best practice guidance

Deploy AKS clusters with Microsoft Entra integration. Using Microsoft Entra ID centralizes the identity management layer. Any change in user account or group status is automatically updated in access to the AKS cluster. Scope users or groups to the minimum permissions amount using Roles, ClusterRoles, or Bindings.

Your Kubernetes cluster developers and application owners need access to different resources. Kubernetes lacks an identity management solution for you to control the resources with which users can interact. Instead, you can integrate your cluster with an existing identity solution like Microsoft Entra ID, an enterprise-ready identity management solution.

With Microsoft Entra integrated clusters in AKS, you create Roles or ClusterRoles defining access permissions to resources. You then bind the roles to users or groups from Microsoft Entra ID. Learn more about these Kubernetes RBAC in the next section. Microsoft Entra integration and how you control access to resources can be seen in the following diagram:

1. Developer authenticates with Microsoft Entra ID.
2. The Microsoft Entra token issuance endpoint issues the access token.
3. The developer performs an action using the Microsoft Entra token, such as kubectl create pod.
4. Kubernetes validates the token with Microsoft Entra ID and fetches the developer's group memberships.
5. Kubernetes RBAC and cluster policies are applied.
6. The developer's request is successful based on previous validation of Microsoft Entra group membership and Kubernetes RBAC and policies.

To create an AKS cluster that uses Microsoft Entra ID, see Integrate Microsoft Entra ID with AKS.

Use Kubernetes role-based access control (Kubernetes RBAC)

Best practice guidance

Define user or group permissions to cluster resources with Kubernetes RBAC. Create roles and bindings that assign the least amount of permissions required. Integrate with Microsoft Entra ID to automatically update any user status or group membership change and keep access to cluster resources current.

In Kubernetes, you provide granular access control to cluster resources. You define permissions at the cluster level, or to specific namespaces. You determine what resources can be managed and with what permissions. You then apply these roles to users or groups with a binding. For more information about Roles, ClusterRoles, and Bindings, see Access and identity options for Azure Kubernetes Service (AKS).

For example, you create a role with full access to resources in the namespace named finance-app, as shown in the following example YAML manifest:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role
  namespace: finance-app
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["*"]

You then create a RoleBinding and bind the Microsoft Entra user developer1@contoso.com to it, as shown in the following YAML manifest:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role-binding
  namespace: finance-app
subjects:
- kind: User
  name: developer1@contoso.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: finance-app-full-access-role
  apiGroup: rbac.authorization.k8s.io

When developer1@contoso.com is authenticated against the AKS cluster, they have full permissions to resources in the finance-app namespace. In this way, you logically separate and control access to resources. Use Kubernetes RBAC with Microsoft Entra ID-integration.

To learn how to use Microsoft Entra groups to control access to Kubernetes resources using Kubernetes RBAC, see Control access to cluster resources using role-based access control and Microsoft Entra identities in AKS.

Use Azure RBAC

Best practice guidance

Use Azure RBAC to define the minimum required user and group permissions to AKS resources in one or more subscriptions.

There are two levels of access needed to fully operate an AKS cluster:

• Access the AKS resource on your Azure subscription.

  This access level allows you to:

  • Control scaling or upgrading your cluster using the AKS APIs
  • Pull your kubeconfig.

  To learn how to control access to the AKS resource and the kubeconfig, see Limit access to cluster configuration file.

• Access to the Kubernetes API.

  This access level is controlled either by:

  • Kubernetes RBAC (traditionally) or
  • By integrating Azure RBAC with AKS for kubernetes authorization.

  To learn how to granularly grant permissions to the Kubernetes API using Azure RBAC, see Use Azure RBAC for Kubernetes authorization.

Next steps

This best practices article focused on authentication and authorization for your cluster and resources. To implement some of these best practices, see the following articles:

• Integrate Microsoft Entra ID with AKS
• Use Microsoft Entra pod-managed identities in Azure Kubernetes Service (preview)

For more information about cluster operations in AKS, see the following best practices:

• Multi-tenancy and cluster isolation
• Basic Kubernetes scheduler features
• Advanced Kubernetes scheduler features