SolvedAKS Cluster-user can't access to AKS cluster with RBAC enabled

We followed this procedure to enable RBAC in our 1.10.3 AKS : https://docs.microsoft.com/en-us/azure/aks/aad-integration#access-cluster-with-azure-ad

We did the procedure with a global admin account, as with a "normal" admin it was not working.

We can access the cluster as a cluster-admin :

• az aks get-credentials --resource-group myAKSCluster --name myAKSCluster --admin
• kubectl get nodes
• set the provided code in the Azure device login page
• get the nodes details : OK

But for a normal user :

• az aks get-credentials --resource-group myAKSCluster --name myAKSCluster
• kubectl get nodes
• set the provided code in the Azure device login page
• Error : we don't recognize your code

We tried with kubectl get nodes --v=9 but it displays no log after the "we don't recognize your code" error.

The user trying to login is "member" in the AAD, we even gave him the "Contributor" role on the resource group of the AKS. Still not working.

We tried tips of MicrosoftDocs/azure-docs#10326 and #478 :

• Global admin : checked
• Click Grant permissions button : checked
• Client app is native : checked
• Member account : checked
• private AD account 'me@myprivatetenant.onmicrosoft.com' : checked

Reading this comment (#439 (comment)) I tried adding a RoleBinding before his login. But same issue.

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: yre-role
  namespace: yre
rules:
  - apiGroups: ["", "extensions", "apps"]
    resources: ["deployments", "replicasets", "pods", "pods/status", "pods/logs", "services", "ingresses", "configmaps", "daemonsets", "secrets"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["", "extensions", "apps"]
    resources: ["services", "ingresses", "configmaps", "secrets"]
    verbs: ["create", "update", "delete", "patch"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: yre-role-binding
  namespace: yre
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: "yre@mycompany.onmicrosoft.com"
    namespace: yre
roleRef:
  kind: Role
  name: yre-role
  apiGroup: rbac.authorization.k8s.io
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: yre-dashboard-role-binding
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: "yre@mycompany.onmicrosoft.com"
roleRef:
  kind: Role
  name: user-dashboard-role
  apiGroup: rbac.authorization.k8s.io
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: user-dashboard-role
  namespace: kube-system
rules:
  - apiGroups: [""]
    resources: ["services/proxy"]
    verbs: ["get"]

The only difference seems that working admin users have the "client application" with the role "Default access" in their "Applications" (in their AAD user's profile). But I think it has been automatically added when we logged in and gave our consent.

Do we have to manually edit the manifest ? The oauth2Permissions part ?

Any help will be appreciated :)

@mleneveut can you share your cluster resource name and resource group name to help with debugging on our side? Also is the AAD user in a different tenant than the AAD application? Can you also share an approx. time window when the AAD user tried to interact with AKS cluster using clusterUser kubeconfig?

@jonaspetersorensen regarding:

What does "--admin" actually do?

A successful AKS cluster create configures two kubconfigs with different roles:

1. Cluster Admin kubeconfig
2. Cluster User kubeconfig

Customers can get these kubeconfigs via POST action:
https://management.azure.com/subscriptions/${SUB_ID}/resourcegroups/${RG_NAME}/provid
ers/Microsoft.ContainerService/managedClusters/${AKS_NAME}/accessProfiles/${ROLE_NAME
}/listcredential?api-version=2018-03-31

Substitute ${ROLE_NAME} with: clusterAdmin or clusterUser role names.

The POST action enables subscription admin to control access to sensitive information like kubeconfigs.
Users in ARM may be associated with a set of roles which control access to resources or paths within a
resource. For example, the Owner role has access to * and the Reader role has access to */read.
This allows quick and easy access management for customers.

Reference Material:
 https://docs.microsoft.com/en-us/azure/active-directory/role-based-access-built-in-roles
 https://docs.microsoft.com/en-us/azure/active-directory/role-based-access-control-customroles

clusterAdmin kubconfig
This is the kubeconfig that has full access to the cluster (can be RBACed as mentioned
above). Using this kubeconfig cluster admin can create roles and rolebindings to associate AAD groups
for Kubernetes RBACing.

clusterUser kubconfig
Cluster user kubeconfig is setup to authenticate and authorize via AAD. By default, an AAD user has no
access to the cluster and authorization to an AKS cluster will only succeed if AKS cluster admin has setup
the right role bindings for the user.