This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(83.2, 76%, 18%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EKB%3C/text%3E%3C/svg%3E)
Hello
On an RBAC & AzureRBAC enabled AKS cluster I have noticed that the cluster-admin ClusterRole is bound to two subjects through the aks-cluster-admin-binding ClusterRoleBinding:
This is unexpected. As far as I understand following Use Azure role-based access control to define access to the Kubernetes configuration file in Azure Kubernetes Service (AKS) - Available permissions for cluster roles, the Users clusterAdmin and clusterUser correspond to the Entra ID roles "Azure Kubernetes Service Cluster Admin" and "Azure Kubernetes Service Cluster User", respectively.
The cluster-admin ClusterRole grants full access onto all resources in all namespaces in the cluster. As such, an Entra ID user who is assigned the "Azure Kubernetes Service Cluster User" role in Entra ID should not be assigned the cluster-admin ClusterRole in Kubernetes.
Am I misunderstanding something?
Best
Konstantin
Hello Konstantin Bachem
Any update on the issue?
Just checking in to see if you got a chance to see previous response.
If the suggested response helped you resolve your issue, please 'Accept as answer', so that it can help others in the community looking for help on similar topics.
Hello Konstantin Bachem
Welcome to Microsoft Q&A Platform, thanks for posting your query here.
Based on the details you provided, looks like there is a discrepancy between the Entra ID roles and the Kubernetes RBAC roles assigned to the users.
The cluster-admin ClusterRole grants full access to all resources in all namespaces in the cluster, and it should only be assigned to users who require full administrative access to the cluster.
The Azure Kubernetes Service Cluster Admin role in Entra ID corresponds to the cluster-admin ClusterRole in Kubernetes, while the Azure Kubernetes Service Cluster User role in Entra ID corresponds to a more limited set of permissions in Kubernetes.
It is possible that the clusterUser user in Kubernetes was mistakenly assigned the cluster-admin ClusterRole, which would grant them full administrative access to the cluster. I would recommend reviewing the RBAC roles assigned to each user in Kubernetes and ensuring that they correspond to the appropriate Entra ID roles.
If you are still unsure about the RBAC roles assigned to users in your AKS cluster, you can use the kubectl describe clusterrolebinding command to view the details of the ClusterRoleBindings that have been created.
Hope this helps.
Hello
Thank you for confirming my suspicion that the aks-cluster-admin-binding ClusterRoleBinding has unexpected subject values.
I am surprised to hear that managing ClusterRoleBinding s such as these isn't handled entirely by AKS, and that I am required to review and edit it directly. I would also like to point out that no manual modification has been made to the aks-cluster-admin-binding ClusterRoleBinding. Do you have an idea what AKS configuration in Azure could have led to this result?
Is there documentation on which Entra ID roles such as Azure Kubernetes Service Cluster Admin correspond to which ClusterRoleBindings and what the default for those bindings is?
Best
Konstantin
It is possible that the unexpected subject values in the aks-cluster-admin-binding ClusterRoleBinding were caused by a misconfiguration during the setup of your AKS cluster. However, it is difficult to determine the exact cause here. I would recommend you to file a support case. That way support engineer can help with troubleshooting this.
Regarding your question about documentation on which Entra ID roles correspond to which ClusterRoleBindings and their default values, I would recommend reviewing the official Microsoft documentation on Azure Kubernetes Service (AKS) RBAC. This documentation provides detailed information on the default roles and permissions in AKS, as well as how to customize them to meet your specific needs.
https://learn.microsoft.com/en-us/azure/aks/manage-azure-rbac?tabs=azure-cli
https://learn.microsoft.com/en-us/azure/aks/azure-ad-rbac?tabs=portal
Additionally, you may want to review the RBAC configuration of your AKS cluster to ensure that it aligns with your intended permissions and access levels. This can help you identify any misconfigurations or unexpected behavior in your cluster's RBAC setup.
I have contacted Microsoft support, who have responded with the following:
These are the default local accounts that are configured on RBAC clusterrolebinding.
Yes, both users will have same permissions when using only RBAC, but this is by design.
So, if you have AAD enabled on your cluster, this clusterrolebinding will not be taken in consideration, since AAD overlap RBAC.
If you think that this might be some "unsecure" configuration on your cluster, you can always disable this local accounts: Manage local accounts with AKS-managed Microsoft Entra integration - Azure Kubernetes Service | Microsoft Learn
More information on this: Azure.AKS.LocalAccounts - PSRule for Azure
Hello Konstantin Bachem
Thanks for sharing this for the benefit of community.