AKS RBAC seems to have stopped working for AD Group bindings. (Forbidden error)

[MarkTopping]

Hi.

Summary:
Newly provisioned 1.10.3 clusters (which exactly replicate a existing 1.10.3 clusters) forbid user to interact with AKS resources when Cluster Role Bindings are setup using Azure AD Groups. Everything works fine when the same users are added to the bindings individually as Users. Authentication works correctly in both cases (via the AD Server/Client App Registrations), but authorisation seems to be an issue.

Error Message:
Error from server (Forbidden): pods is forbidden: User "removed@account.onmicrosoft.com" cannot list pods in the namespace "default"

To be clear the user is within a group configured as a cluster-admin. The issue here is not the namespace.

Working (subject type: User)

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: individual-users-admins
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: "usersemail@account.onmicrosoft.com"

No longer working (subject type: Group)

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: sorted_react_prod_admins
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: "Azure-AD-Group-Name"

More Detail:
Approximately 2 weeks ago I built two RBAC-enabled clusters using AKS Version: 1.10.3. Cluster Role Bindings where provisioned which linked up to several Azure Active Directory Groups and everything worked fine. Unfortunately I needed to alter the Service Principle these ran under so it become necessary to tear them down and re-build.

So, yesterday I re-provisioned my clusters and did so using the same scripts I'd generated for building them up first time round - this includes cluster creation and the cluster role bindings setup. The only thing I changed in my scripting was that I altered my parameters.json file to take account of the new Service Principle credentials (I create my clusters using the acs-engine and resource templates).

There were also a couple of steps in the whole process which I did not repeat. That is I did not re-create my Azure AD Groups, and I did not create new AD Server/Client App Registrations. I expect to leverage the fact these are already in place.

As such, my new cluster use the same AppServerId, ClientServerId, and ServerApplicationSecret as the initial clusters did, and to repeat/confirm, I can successfullly authenticate via https://login.microsoftonline.com/common/oauth2/deviceauth and the code provided when I run aks get-credentials.

To experiment I also created a new AD Group and gave that group cluster-admin. Members of the group where still forbidden to access resources.

Note that the users in my AD Groups are NOT guest accounts. Been there and tackled that one previously.

[colemickens]

Possibly relevant: #505 (comment) and kubeguard/guard#154

[bryanlikes]

They decided that AKS would no longer accept group names for the rolebindings and only accept group guids on new cluster deployments. Clusters deployed before the change should still work with display name.

[amanohar]

@MarkTopping, as @colemickens mentioned this might be due to AKS now using AAD group's unique id instead of group display name in the rolebinding. The documentation has been updated: https://docs.microsoft.com/en-us/azure/aks/aad-integration and all current AKS customers that have a running AAD cluster should have received a notification (cc: @sauryadas )

[MarkTopping]

@bryanlikes @amanohar This is useful information in deed. Something I might have expected to come with a version increment - I'm sure I won't be the only person/organisation with now defunct infrastructure deployment scripts.

Anyhow, I will try Guids as you suggest and report back soon.
Thank you both for the guidance

[MarkTopping]

Took me a while to get round this this since i'd applied a workaround which took the pressure off. Anyhow, just confirming...

Using the AD Group Object Id instead of Group Name worked.

Thanks.

[sauryadas]

Closing this since this is now working