AKS is integrated with Azure active directory (https://azure.microsoft.com/en-ca/services/active-directory/) via OpenID connect tokens (https://kubernetes.io/docs/reference/access-authn-authz/authentication/#openid-connect-tokens). The Role-Based Access Control (RBAC) feature can only be enabled during cluster creation, so let's start over to create an RBAC-enabled cluster.

Before creating the cluster, we'll have to prepare two application registrations in the Azure active directory first. The first acts as a server for the users' group membership. The second is like a client that integrates with kubectl. Let's go to the Azure active registry service in the Azure portal first. Go to the Properties tab and record the Directory ID. We'll need this later when we create the cluster:

Let's go to the Application registrations of the Azure active registry service in the Azure portal first. The tab on the side shows two application registration options. One is the original design and the other is the preview version for the new console. Their functionalities are basically the same. We'll show the GA version first and the preview version after:

In the App registrations page, click New application registration. Add a name with any URL. 

Here, we use myAKSAD as the name. After creation, we record the APPLICATION ID first. Here, we get c7d828e7-bca0-4771-8f9d-50b9e1ea0afc. After that, click Manifest and change the groupMemebershipClaims to All, which will get the group claims in the JWT token for all users that belong:

After saving the settings, go to these Settings page then the Keys page to create a key. Here, we specified expires as one year. This value was generated by the portal directly. We'll need this password later when we create the cluster:

Next, we'll define a set of applications and delegated permissions for this registration. Hit the Required permissions tab and click Add, before selecting Microsoft Graph. Here, we'll select Read directory data under the Application permissions category and Sign in and read user profile and Read directory data under the delegated permissions so that the server can read the directory data and verify the users. After clicking the Save button, we'll see the following screen in the Required permissions page:

As the admin, we can grant permission for all users in this directory by clicking the Grant permission button. This will make a window pop up that will double-check this with you. Click Yes to continue.

It's now time to create a second application registration for the client. The name we used here is myAKSADClient. Record its Application ID after creation. Here, we get b4309673-464e-4c95-adf9-afeb27cc8d4c:

For the required permissions, the client just needs to access the application, search the delegated permissions, and find the Access permission with the display name that you created for the server. Don't forget to hit the Grant permission button after you are done:

Right now, it's time to create our AKS cluster with Azure AD integration. Make sure that you have recorded the following information from the previous operations:

It is now time to launch the cluster:

# az aks create --resource-group devops --name myADAKS --generate-ssh-keys --aad-server-app-id c7d828e7-bca0-4771-8f9d-50b9e1ea0afc --aad-server-app-secret 'A/IqLPieuCqJzL9vPEI5IqCn0IaEyn5Zq/lgfovNn9g=' --aad-client-app-id b4309673-464e-4c95-adf9-afeb27cc8d4c --aad-tenant-id d41d3fd1-f004-45cf-a77b-09a532556331 --node-count 1 --enable-addons monitoring,http_application_routing --generate-ssh-keys

In Kubernetes, a role binding or a cluster role binding binds the role to a group of users. A role or cluster role defines a set of permissions.

After the cluster is successfully launched, to integrate with OpenID, we'll have to create the role binding or cluster role binding first. Here, we'll use the existing cluster role in the cluster, which is cluster-admin. We'll bind the users to the cluster-admin cluster role so that the users can be authenticated and act as cluster admins:

// login as admin first to get the access to create the bindings
# az aks get-credentials --resource-group devops --name myADAKS --admin

// list cluster roles
# kubectl get clusterrole
NAME AGE
admin 2h
cluster-admin 2h
...

For a single user, we'll have to find the username. You can find the Object ID for the target user under the users page in the Azure AD portal:

Use user subjects and specify the Object ID as the name, as shown here:

# cat 12-3_user-clusterrolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 name: azure-user-cluster-admins
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: "8698dcf8-4d97-43be-aacd-eca1fc1495b6"

# kubectl create -f 12-3_user-clusterrolebinding.yaml
clusterrolebinding.rbac.authorization.k8s.io/azure-user-cluster-admins created

After that, we can start over to access the cluster resources, as shown here:

// (optional) clean up kubeconfig if needed.
# rm -f ~/.kube/config

// setup kubeconfig with non-admin
# az aks get-credentials --resource-group devops --name myADAKS 

// try get the nodes
# kubectl get nodes
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code A6798XUFB to authenticate.

It seems like we need to log in before listing any resources. Go to the https://microsoft.com/devicelogin page and input the code, as the prompt suggests:

Log in to your Microsoft account and return to the terminal. The integration looks great!

# kubectl get nodes
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code A6798XUFB to authenticate.
NAME STATUS ROLES AGE VERSION
aks-nodepool1-42766340-0 Ready agent 26m v1.9.11

Rather than specifying a set of users, you could choose to specify users as a group via the Azure AD group object ID. Replace the subject in the cluster role binding configuration so that all the users in that group will have cluster admin access:

- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: "$group_object_id"