Azure AKS 用户凭据登录到 K8 仪表板和 RBAC 内置角色

Question

According to the documentation , Azure Kubernetes Service Cluster User Role allows access to Microsoft.ContainerService/managedClusters/listClusterUserCredential/action API call only.

My user is part of an AD group that has Azure Kubernetes Service Cluster User Role permissions on the AKS cluster and all the cluster role and cluster role bindings have been applied via kubectl .

I can double check and verify that access to dashboard and permissions work with these steps:

 1. az login
 2. az aks get-credentials --resource-group rg --name aks
 3. kubectl proxy
 4. Open web connection
 5. Get prompt on terminal to login via device code flow
 6. Return to web connection on dashboard
 7. I can correctly verify that my permissions apply, 
 i.e. deleting a job does not work and this falls in line with my
    kubectl clusterrole bindings to the Azure AD group.

However when I try to use the az aks browse command to open the browser automatically like this, ie without kubectl proxy :

 1. az login
 2. az aks get-credentials --resource-group rg --name aks
 3. az aks browse --resource-grouprg --name aks

I keep getting the following error:

The client 'xxx' with object id 'yyyy' does not have authorization to perform action 
'Microsoft.ContainerService/managedClusters/read' over scope 
'/subscriptions/qqq/resourceGroups/rg/providers/Microsoft.ContainerService/managedClusters/aks' 
or the scope is invalid. If access was recently granted, please refresh your credentials.

A dirty solution was to apply Reader role on the AKS cluster for that AD group - then this issue goes away but why does az aks browse require Microsoft.ContainerService/managedClusters/read permission and why is that not included in Azure Kubernetes Service Cluster User Role ?

What is happening here?

Answer 1

Currently, the command

az aks browse --resource-grouprg --name aks isn't working with the more recent version of AKS, you can find the full details here.

https://github.com/MicrosoftDocs/azure-docs/issues/23789

Also, your current problem might also be that your user XXX doesn't have the right IAM access level at the Subscription/ResourceGroup level.