Azure AD and AKS RBAC integrate by Azure AD acting as the identity provider for AKS cluster access, translating user/group permissions into Kubernetes RBAC roles.
Let’s see it in action. Imagine you have a Kubernetes cluster running on Azure Kubernetes Service (AKS) and you want to manage who can do what within that cluster using your existing Azure Active Directory (Azure AD) identities. Instead of creating separate Kubernetes users or service accounts for everyone, you can leverage Azure AD.
Here’s a typical scenario. You have a team of developers who need to deploy applications to a specific namespace, say dev-app-ns. You also have an operations team that needs broader access, perhaps to manage deployments across multiple namespaces.
First, on your AKS cluster, you’d enable Azure AD integration. This is usually done during cluster creation or by updating an existing cluster. The command might look something like this (simplified):
az aks create \
--resource-group myResourceGroup \
--name myAKSCluster \
--enable-aad \
--aad-admin-group-object-ids <your-admin-group-object-id>
The --enable-aad flag tells AKS to integrate with Azure AD. The --aad-admin-group-object-ids is crucial: it specifies an Azure AD group whose members will have cluster-admin privileges. This is your first layer of control.
Once Azure AD integration is enabled, you can start mapping Azure AD identities (users or groups) to Kubernetes RBAC roles. Kubernetes RBAC uses Roles and ClusterRoles to define permissions, and RoleBindings and ClusterRoleBindings to grant those permissions to subjects (users, groups, or service accounts).
For our dev-app-ns example, you’d create a Role in that namespace:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: app-deployer
namespace: dev-app-ns
rules:
- apiGroups: ["apps", ""] # "" indicates the core API group
resources: ["deployments", "pods", "services"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
Then, you’d create a RoleBinding to grant this Role to a specific Azure AD group. Let’s say your developers are in an Azure AD group with Object ID abcdef12-3456-7890-abcd-ef1234567890.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: dev-app-deployers-binding
namespace: dev-app-ns
subjects:
- kind: Group
name: "abcdef12-3456-7890-abcd-ef1234567890" # This is the Azure AD Group Object ID
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: app-deployer
apiGroup: rbac.authorization.k8s.io
Now, any user who is a member of that Azure AD group can log into the AKS cluster using kubectl and their Azure AD credentials. When they try to perform an action (like kubectl create deployment ... in dev-app-ns), AKS checks their Azure AD identity against the RoleBinding, sees they are part of the abcdef12-... group, and grants them the permissions defined in the app-deployer Role for that namespace.
For the operations team, you might grant them a ClusterRole (which applies cluster-wide) and bind it using a ClusterRoleBinding. For instance, to give them read-only access to all pods in all namespaces:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
And the binding:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: ops-cluster-reader-binding
subjects:
- kind: Group
name: "fedcba98-7654-3210-fedc-ba9876543210" # Another Azure AD Group Object ID
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: cluster-reader
apiGroup: rbac.authorization.k8s.io
This setup centralizes identity management in Azure AD and leverages Kubernetes RBAC for fine-grained authorization within the cluster. The surprising part is how seamlessly Azure AD group memberships are translated into Kubernetes subjects, making it feel like you’re directly managing Kubernetes permissions with your cloud identities. You don’t need to provision separate Kubernetes users; membership in an Azure AD group is sufficient.
The system works by AKS acting as an API server authenticator. When a user tries to authenticate to the Kubernetes API server using kubectl, they’re often prompted to log in via Azure AD. Upon successful authentication, Azure AD issues a token. AKS then validates this token and, crucially, queries Azure AD to determine the groups that the authenticated user belongs to. Kubernetes RBAC authorization is then performed based on these group memberships.
The exact levers you control are the Azure AD groups you select and the Kubernetes RBAC roles and bindings you create. You define what permissions any member of a given Azure AD group will have within the cluster. This allows for dynamic role assignment: add a user to an Azure AD group, and they instantly gain those permissions in AKS; remove them, and they lose them.
What most people don’t realize is that the name field in the subjects section of a RoleBinding or ClusterRoleBinding must be the Azure AD Object ID of the group (or user, though group binding is far more common for RBAC). It’s not a display name or a friendly alias; it’s the GUID that uniquely identifies the Azure AD object. If this doesn’t match, the binding will simply not apply to that Azure AD identity.
The next concept you’ll encounter is managing access for individual users or service principals, and how to handle more complex, attribute-based access control scenarios.