Authentication & Authorisation

Authentication

AKS offers two options for authenticating users to the Kubernetes API server, to run tools like kubectl or k9s.

1. Kubernetes Local Authentication

Local authentication allows for users to authenticate against user accounts that have been created in Kubernetes. Users are created in Kubernetes using a certificate for authentication. A default admin user is created when the cluster is deployed.

Warning

While AKS supports local accounts for cluster authentication, using them is not recommended for production environments. Instead, you should integrate your AKS cluster with Microsoft Entra ID. This enables centralized identity management, enforces role-based access control (RBAC), and ensures that access is automatically revoked when users leave the organization or change roles — significantly improving security and compliance.

2. Entra ID Authentication

The recommended approach for authentication is to use Entra ID. This can be configured at the time you deploy the cluster, or later, and allows users to authenticate to the Kubernetes API using their Entra ID credentials. By using Entra ID you ensure that your users are centrally managed, using the same security and compliance as the rest of your organisation. You benefit from all the security controls that apply to Entra ID users such as Multi-Factor Authentication, Conditional Access and security monitoring.

To authenticate Entra ID users using tools like kubectl you will need to install the kubelogin tool on any workstations that access AKS. kubelogin is a client-go credential plugin that implements Microsoft Entra authentication. The kubelogin plugin offers features that aren’t available in the kubectl command-line tool.

Once Entra ID authentication is enabled, and kubelogin is installed, when a user attempts to connect to AKS, they will be prompted to login to Entra ID using the standard Entra ID device code login flow from the CLI. It is also possible to configure kubelogin to use the credentials from your existing Azure CLI login, if this is present. To do so, you will need to run the following command once per Kubernetes context:

kubelogin convert-kubeconfig -l azurecli

Authorization

Once users are authenticated to AKS, they need to be granted rights to undertake actions in the cluster. In this section will focus on granting these rights to Entra ID users, as this is the recommended approach. When using Entra ID authorization there are two different authorization settings that need to be considered.

Cluster Access

The first set of permissions that need to be assigned are the rights to actually connect to the cluster. These are purely Azure RBAC permissions. This is achieved by assigning the Azure Kubernetes Service Cluster User role to the users or groups who need access, scoped to the specific clusters they need access to.

az role assignment create                         \
  --assignee <User_ID>                            \
  --role "Azure Kubernetes Service Cluster User"  \
  --scope /subscriptions/<Subscription_ID>/resourceGroups/<Resource_Group>/providers/Microsoft.ContainerService/managedClusters/<AKS_Cluster>

Info

You may notice that there is also a Azure Kubernetes Service Cluster Admin role. This role was previously used to grant access to using the local admin user on the cluster. This has been replaced by Azure RBAC for Kubernetes and should not be used.

Once this role has been assigned, the user should be able to use the following command to get credentials for the cluster.

az aks get-credentials -n <cluster name> -g <cluster resource group>

This will allow the user to authenticate to the cluster, but they will not have rights to do anything in the cluster.

Cluster Permissions

To be able to interact with the resources in the cluster, the user will need to be granted permissions on the cluster. There are two ways that this can be achieved

Assign Azure RBAC roles that define Kubernetes permissions to Entra ID users
Create Kubernetes Roles and Role Bindings, and assign these to Entra ID users

Using Azure RBAC roles is the recommended, and simplest approach.

Azure RBAC for Kubernetes Authorisation

The first option, using Azure RBAC for Kubernetes Authorisation, is the simplest method as it allows you to assign and manage all permissions through Azure RBAC, rather than needing to create Kubernetes authorisation resources in each cluster. There are 4 built in roles that can be used without any further configuration:

Role	Description
Azure Kubernetes Service RBAC Reader	Allows read-only access to see most objects in a namespace. It doesn’t allow viewing roles or role bindings. This role doesn’t allow viewing Secrets, since reading the contents of Secrets enables access to ServiceAccount credentials in the namespace, which would allow API access as any ServiceAccount in the namespace (a form of privilege escalation).
Azure Kubernetes Service RBAC Writer	Allows read/write access to most objects in a namespace. This role doesn’t allow viewing or modifying roles or role bindings. However, this role allows accessing Secrets and running Pods as any ServiceAccount in the namespace, so it can be used to gain the API access levels of any ServiceAccount in the namespace.
Azure Kubernetes Service RBAC Admin	Allows admin access, intended to be granted within a namespace. Allows read/write access to most resources in a namespace (or cluster scope), including the ability to create roles and role bindings within the namespace. This role doesn’t allow write access to resource quota or to the namespace itself.
Azure Kubernetes Service RBAC Cluster Admin	Allows super-user access to perform any action on any resource. It gives full control over every resource in the cluster and in all namespaces.

Alternatively you can create custom roles using the Microsoft.ContainerService/managedClusters permissions.

Once you have determined which roles to assign, you can create the Azure role assignment. The default assignment will grant permissions at the cluster scope:

az role assignment create --role "Azure Kubernetes Service RBAC Admin" --assignee <AAD-ENTITY-ID> --scope $AKS_ID

If you do not want to create the assignment at the cluster level, you can create the assignment at a specific namespace.

az role assignment create --role "Azure Kubernetes Service RBAC Reader" --assignee <AAD-ENTITY-ID> --scope $AKS_ID/namespaces/<namespace-name>

Kubernetes RBAC with Entra ID users

Info

Azure RBAC for Kubernetes is the recommended approach for managing permissions in AKS.

Authorization in Kubernetes is controlled using Roles and Role Bindings:

Roles define a set of permissions that can be assigned to a user, or group, to be able to take on a specific role
Role Bindings associated a Role with a user or group, so that they are assigned the permissions in that Role, at a specific scope.

Roles and Role Bindings are applied at a specific namespace. If you wish to grant these cluster-wide then there are two additional resources to use - Cluster Roles and Cluster Role Bindings. These are the same as the Role and Role Bindings discussed above, but are applied at the cluster scope, rather than the namespace scope.

Roles

Role objects include several settings that determine what the role is applied to. Below is an example role:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

The metadata section defines a name for the role, and where it is created. The rules section then defines the content of the role:

apiGroups - specifies which API group the defined resources belong to, allowing the role to target core or extended Kubernetes APIs for access control.
resources - defines which resources, in the specified API Groups, this role applies to
verbs - defines which actions are allowed on the specific resources

A single Role can define multiple different rules.

Role Bindings

Role Bindings are used to assign Roles to users or groups. In our case, we want to assign these roles to Entra ID users and groups. Below is an example role binding that assigns an Entra ID group the “view” role. Note that the name of the group used is the Entra ID object ID for the group, not the name.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-view
  namespace: dev-namespace
subjects:
- kind: Group
  name: "<Entra_ID_Group_ID>"  # Replace with the actual Microsoft Entra ID Group Object ID
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: view
  apiGroup: rbac.authorization.k8s.io

Once this Role Binding has been created, users in the assigned group will have access to the “view” role.