Azure Kubernetes Service (AKS) with Azure AD
Main article is over here, and do check them out from time to time because things change very freuqently.
After reading the article above, I thought I could (maybe) everyone a favor by explaining a little bit more in details (and in layman terms ala Explain like I'm Five eli5) on what is going on. Here's my attempt:
In Azure, you get to add users and groups to resources and resource groups, delegating permission and grant them access as needed. Wouldn't it be great if you can just add your colleague within your Azure AD tenant to AKS so you get to control what access they have and they get to sign-in with their usual corporate credentials? This is exactly what AKS allows you to do today.
Here's what you need:
- An Azure Subscription (you can get it for free for a year thorugh my.visualstudio.com)
- Azure Kubernetes Services (AKS) - You will find a lot of references on how to create this but I suggest you to follow this guide
- Azure CLI, with AZ AKS installed (I like to do everything locally, but you can work with cloud shell as well)
Once you have you AKS ready run the following command:
az loginand follow on screen instruction
az aks get-credentials --resource-group k8s --name k8s --admin
Basically, what the above does is to get credential from your Kubernetes cluster and store them in C:\Users\[username]\.kube\config so kubectl can use them later.
az aks browse --resource-group k8s --name k8s
You can then open up the Kubernetes Dashboard by running above command. This will create a tunnel, and open up your browser to Kubernetes cluster's dashboard. (not very imporatant, but good to know)
you are now seeing the dashboard using the credential stored in .kube\config (for me it it was clusterAdmin_k8s_k8s) Depends on what version of Kubernetes you are running, if you see the following error, that's because AKS (the latest one as of the time of this blog's entry) has RBAC enabled by default and there is an extra step you need to do.
[caption id="attachment_555" align="alignnone" width="1024"] basically the first error is telling you the service account (kubernetes-dashboard) you are using to view the k8s dashboard at namespace (kube-system) has no permission to do what is needed (to view configmaps) - configmaps is forbidden: User "system:serviceaccount:kube-system:kubernetes-dashboard" cannot list configmaps in the namespace "default"[/caption]
kubectl create clusterrolebinding kubernetes-dashboard --clusterrole=cluster-admin --serviceaccount=kube-system:kubernetes-dashboard We are creating a "clusterrolebinding" name it as "kubernetes-dashboard" with "cluster-admin" as the permission level and grant this to the service account "kubernetes-dashboard" at "kube-system" namespace. Now refresh.
To add a Azure AD user, create a .yaml file with following contents
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: contoso-cluster-admins roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: "[username]@contoso.onmicrosoft.com"
kubectl apply -f "[path to .yaml]"
We were doing all the above through "local user account --admin", if you may. What we are going to do next is to login and run kubectl using Azure AD user.
Remove all the context in .kube\config by running
kubectl config unset contexts.k8skubectl config unset clusters.k8skubectl config unset users.clusterUser_k8s_k8s or you can delete .kube\config just to be safe
az aks get-credentials --resource-group k8s--name k8skubectl get nodes
You will be asked to sign-in again, and you can use the azure ad account you just added to sign-in.
I haven't test the following scenario yet, but if I am correct you now can add any developers as reader to the Azure Resource Group as reader (so they can run az aks get-credentials) and then grant them permission separately within Kubernetes cluster using RBAC-Binding
I hope my attempt in eli5 was good enough.