The Kubernetes dashboard is quite useful to drill through existing Kubernetes clusters and inspect things without using kubectl. However, starting with version 2.0.40 of Azure CLI, Azure Kubernetes clusters are deployed with Role-Based-Access-Control (RBAC) enabled by default. Since that point in time, you will be presented with a bunch of errors when trying to access the traditional Kubernetes dashboard using az aks browse.

Broken Kubernetes Dashboard in RBAC enabled AKS
Insufficient permissions for Kubernetes dashboard in RBAC enabled AKS

This error occurs because the underlying ServiceAccount used to run the Kubernetes dashboard has insufficient permissions and cannot read all required information using Kubernetes API.

Inspect The Kubernetes Dashboard Deployment

You can quickly verify which ServiceAccount is used to run the Kubernetes dashboard by looking into the deployment manifest of kubernetes-dashboard in the kube-system namespace.

# Get ServiceAccountName that runs the Kubernetes dashboard
kubectl get deploy -n kube-system kubernetes-dashboard -o yaml | grep serviceAccountName:

serviceAccountName: kubernetes-dashboard

# Verify the ServiceAcccount
kubectl get serviceaccount -n kube-system
NAME                                 SECRETS   AGE
...                                  ...       ...
kubernetes-dashboard                 1         19h
...                                  ...       ...

Now, we know that we have to grant required permissions to the kubernetes-dashboard ServiceAccount in kube-system namespace.

For demonstration purposes, we will now create a ClusterRoleBinding and assign the ClusterRole cluster-admin to the ServiceAccount. Assigning this role to the kubernetes-dashboard ServiceAccount works but is a huge risk. Especially when omitting further authentication configuration for the Kubernetes dashboard.

You should read and consider using different authentication mechanisms, as described in the Access-Control section of the Kubernetes dashboard repository.

Create The ClusterRoleBinding

To create a new ClusterRoleBinding, you use the kubectl create clusterrolebinding command. Every ClusterRoleBinding consists of three main parts. In addition to a name, you must specify the desired ClusterRole and the full-qualified name of the ServiceAccount, whom the ClusterRole will be bound to.

# Create a ClusterRoleBinding
kubectl create clusterrolebinding kubernetes-dashboard \
  --clusterrole=cluster-admin \
  --serviceaccount=kube-system:kubernetes-dashboard

Access The Kubernetes Dashboard

Now having the ClusterRoleBinding deployed, we can again use Azure CLI and browse the Kubernetes dashboard.

# connect to AKS and configure port forwarding to Kubernetes dashboard
az aks browse -n demo-aks -g my-resource-group

The Azure CLI will automatically open the Kubernetes dashboard in your default web-browser. At this point, you can browse through all of your Kubernetes resources.

Kubernetes Dashboard in RBAC enabled AKS
Kubernetes Dashboard in RBAC enabled AKS

Remove The ClusterRoleBinding

Once you have finished inspecting the Azure Kubernetes cluster, remember to remove the ClusterRoleBinding to eliminate the security-vector. You can use kubectl delete to remove it as shown in the following snippet:

# Remove the custom ClusterRoleBinding
kubectl delete clusterrolebinding kubernetes-dashboard

Conclusion

Inspecting an existing Azure Kubernetes cluster using the Kubernetes dashboard is super useful while explaining artifacts or architectures to others. The intuitive visualization in Kubernetes dashboards is an excellent resource that you can use for discussions about things like cluster utilization, application architectures with people who are not so deep in Kubernetes. Personally, I don’t need the Kubernetes dashboard that regularly, so adding and removing the ClusterRoleBinding works for my usage. If you have a different usage pattern, you must take care of the Kubernetes dashboard Access-Control.