Information Security professionals, this is one of the powerful capability that you don’t want your organization to miss. Integration of AKS cluster with Azure AD is not new. Microsoft turned the classic experience into managed capability. You can control access to Kubernetes Cluster using Azure AD identities and Azure RBAC (role based access control). For most of the organizations, users and groups are synced with Azure and you can use your on-premise Identity and Access Governance (IAG) to control access to Azure Kubernetes Service cluster.
“AKS-managed Azure AD integration is designed to simplify the Azure AD integration experience, where users were previously required to create a client app, a server app, and required the Azure AD tenant to grant Directory Read permissions. In the new version, the AKS resource provider manages the client and server apps for you.“
In this post, we are going to demonstrate the AAD integration but let me touch on few perks Microsoft brought to you without much fan fare. It’s been six months since my last post on AKS, Kubernetes Sidecar Security Pattern with NGINX+ for Reverse Proxy + TLS + Jwt, and I am excited to see Microsoft has been proactively adding new features to AKS.
First thing first, I upgraded the Azure Cli (v2.13.0) and Kubectl (v.1.18.8). Why not refresh Docker for Desktop in Windows 10? Yep, upgraded the docker to v19.03.13. Upgrading docker was not needed but it’s done in preparation for next article- run docker container as non-root!
As an admin, you can find Kubernetes Resources in Azure Portal and you no longer have to run a proxy to see the same in dashboard or run countless kube commands to see the same. This feature is in preview but it is going in the right direction. You can’t see roles and rolebindings but, I guess, those are not available for security reason. Deployment center is in preview and it allows you to configure a DevOps pipeline to deploy your application updates to kubernetes cluster.
Back to AAD integration with AKS. I am working on an existing cluster and it was just a matter of clicks to enable AKS-managed Azure Active Directory. Well, that the first step! You can do the same with Azure cli, AKS-managed Azure Active Directory integration. You will be asked to assign an AD group to cluster admin and you should do so. I created a group aks-cluster-admin and assigned it to the cluster. Azure will create the necessary ClusterRole (using existing cluster-admin) and ClusterRoleBinding (aks-cluster-admin-binding-aad) for you with AD group assigned.
Next, we need to create AD groups (or use existing AD groups), assign members to them and assign the group(s) to Azure Kubernetes RBAC role(s).
If you are a DevOps person, you would be using Azure Cli or SDK in your CI/CD process to make the changes. You can user Azure Portal to make the same change or verify the changes in portal.
Azure Managed AAD integration is new and it’s not mature enough but it is heading in the right direction. Azure took care of Kubernetes ClusterRole and ClusterRoleBinding when we enabled AAD with AKS. However, it would not add/update kubernetes role/clusterrole and rolebinding/clusterrolebinding for other groups when you assign AD group to Kubernetes RBAC role! For now, you have to do that work yourself. I assigned aks-cluster-reader group to Azure Kubernetes Service RBAC Reader but user belong to aks-cluster-reader could not access anything.
No worry, you can create a clusterrole or use an existing role (view) and create a new clusterrolebinding with the reader group as subject. You can find more details here.
That’s all and we are ready to test! We need at least two users- one belong to aks-cluster-admin (prodip.kumar@aspnet4you.com) and another belong to aks-cluster-reader (Bob@aspnet4you.com). To access cluster as AD user/group, we will need to run az aks get-credentials command. This command will update the kube config file with placeholders and you will be prompted to login in browser. Successful login will update the config with access token which is used for subsequent kubectl commands. Having the access token does not mean you can access resources, it would depend if user’s group is assigned to clusterrolebinding.
#Access an Azure AD enabled cluster az aks get-credentials --resource-group $myResourceGroup --name $myAKSCluster --overwrite-existing
Bob is our least privileged user and we will try Bob’s identity to test first. Let’s try to run kubectl get nodes command under Bob’s login. You will be prompted to login at https://microsoft.com/devicelogin with a code given. See what happened for our test! Error from server (Forbidden): nodes is forbidden: User “bob@aspnet4you.com” cannot list resource “nodes” in API group “” at the cluster scope. This is expected since “view” clusterrole referenced in “aks-cluster-reader-binding-aad” clusterrolebinding does not have permission to apiGroup and nodes resource.
Let’s see if Bob can see pods and services. Yes, Bob can access (read) pods, service, etc. You can customize the clusterrole as per your need.
Now, let’s use Prodip.Kumar@aspnet4you.com who is a member of aks-cluster-admin privileged AD group. We will have to run “az aks get-credentials –resource-group $myResourceGroup –name $myAKSCluster –overwrite-existing” command to reset the security context. aks-cluster-admin has access to everything and user can see/edit everything as designed.
Let’s try to access Kubernetes Dashboard as prodip.kumar@aspnet4you.com. We will grab the access token, issued to the user at the time of login, from kube config file. Yep, user can access everything on dashboard as expected.
We will run az aks get-credentials command to reset the context and login as Bob. Sign out from k8 dashboard and login with Bob’s access token. Bob can see deployments, pods, services and some other resources. However, Bob can’t see nodes, clusterroles, secrets, etc.
