Access dashboard on AKS with RBAC enabled

AKS supports RBAC since its General Available.

After visiting the Dashboard of Kubernetes in AKS you will get warnings because the user visiting the dashboard does not have enough rights. This post tells you how to solve this. But let’s create a RBAC enabled cluster first.

Creating an AKS cluster with RBAC

RBAC is not switched on by default. Since Azure CLI version 2.0.40 RBAC is enabled by default. RBAC is enabled during the creation of the cluster.

Create an AKS cluster with RBAC and HTTP application routing with the CLI:

az aks create --resource-group clouddemo --name democluster --kubernetes-version 1.11.3 --max-pods 100 --enable-addons http_application_routing --ssh-key-value "C:\repos\pascal\subscription\ssh\public.pub" --service-principal abcdef-1234-4bf5-b140-8a37729da10e --client-secret yRXSaXMZqV46nawU

I prefer to create a service principal myself on forhand. Use this PowerShell script to create one https://github.com/pascalnaber/vsts-azure-principal

I pass a ssh key which is being created on forhand also. Read here how to create one with Puttygen:
https://pascalnaber.wordpress.com/2017/09/06/ssh-keys-on-windows-for-kubernetes-with-azure-container-service-acs/

Besides the CLI, it’s also possible to create an AKS cluster with an ARM template:

https://github.com/pascalnaber/EnterpriseARMTemplates/tree/master/templates/resources/Microsoft.Container-ServicemanagedClusters

Trying to access the dashboard

You have provisioned a RBAC enabled AKS cluster. When you create a proxy to the dashboard. You will see the following errors :

configmaps is forbidden: User "system:serviceaccount:kube-system:kubernetes-dashboard" cannot list configmaps in the namespace "default"
persistentvolumeclaims is forbidden: User "system:serviceaccount:kube-system:kubernetes-dashboard" cannot list persistentvolumeclaims in the namespace "default"
secrets is forbidden: User "system:serviceaccount:kube-system:kubernetes-dashboard" cannot list secrets in the namespace "default"
services is forbidden: User "system:serviceaccount:kube-system:kubernetes-dashboard" cannot list services in the namespace "default"
ingresses.extensions is forbidden: User "system:serviceaccount:kube-system:kubernetes-dashboard" cannot list ingresses.extensions in the namespace "default"
daemonsets.apps is forbidden: User "system:serviceaccount:kube-system:kubernetes-dashboard" cannot list daemonsets.apps in the namespace "default"
pods is forbidden: User "system:serviceaccount:kube-system:kubernetes-dashboard" cannot list pods in the namespace "default"
events is forbidden: User "system:serviceaccount:kube-system:kubernetes-dashboard" cannot list events in the namespace "default"
deployments.apps is forbidden: User "system:serviceaccount:kube-system:kubernetes-dashboard" cannot list deployments.apps in the namespace "default"
replicasets.apps is forbidden: User "system:serviceaccount:kube-system:kubernetes-dashboard" cannot list replicasets.apps in the namespace "default"
jobs.batch is forbidden: User "system:serviceaccount:kube-system:kubernetes-dashboard" cannot list jobs.batch in the namespace "default"
cronjobs.batch is forbidden: User "system:serviceaccount:kube-system:kubernetes-dashboard" cannot list cronjobs.batch in the namespace "default"
replicationcontrollers is forbidden: User "system:serviceaccount:kube-system:kubernetes-dashboard" cannot list replicationcontrollers in the namespace "default"
statefulsets.apps is forbidden: User "system:serviceaccount:kube-system:kubernetes-dashboard" cannot list statefulsets.apps in the namespace "default"

This looks like this:

The ServiceAccount used by the dashboard has not enough rights to access all resources.

Solving the problem

Microsoft has changed AKS multiple times. In short is this the only thing you have to do now:

Create a ClusterRoleBinding which gives the role dashboard-admin to the ServiceAccount created above.

kubectl create clusterrolebinding kubernetes-dashboard -n kube-system --clusterrole=cluster-admin --serviceaccount=kube-system:kubernetes-dashboard

 

 

 

Below you can read the old solution during the first versions of AKS.

The best solution is to create a specific user/serviceaccount which has the rights to access the dashboard. Here are the steps to configure this:

1. Create a ServiceAccount for the dashboard:
(in the mean time Microsoft has added a service account already for this. So service account kubernetes-dashboard exists already.)

kubectl create serviceaccount kubernetes-dashboard -n kube-system

2. Create a ClusterRoleBinding which gives the role dashboard-admin to the ServiceAccount created above.

kubectl create clusterrolebinding kubernetes-dashboard -n kube-system --clusterrole=cluster-admin --serviceaccount=kube-system:kubernetes-dashboard

3. Get the Token of the ServiceAccount.
To access the dashboard we need the token of the ServiceAccount.

This can be done with the following line, which doesn’t work on a Windows CLI:

kubectl get secret $(kubectl get serviceaccount kubernetes-dashboard -n kube-system -o jsonpath="{.secrets[0].name}") -n kube-system -o jsonpath="{.data.token}" | base64 --decode

Personally I’ve installed the Ubuntu Linux Subsystem and installed the Azure CLI and configured kubectl on it. An alternative is to execute it in Powershell:

$data = kubectl get secret $(kubectl get serviceaccount kubernetes-dashboard -n kube-system -o jsonpath="{.secrets[0].name}") -n kube-system -o jsonpath="{.data.token}"
[System.Text.Encoding]::ASCII.GetString([System.Convert]::FromBase64String($data)) | clip

(Thank you for the clip addition Amanda Debler)

There are 2 ways to authenticate to the Dashboard. Both ways use the token.
The first way shows how to authenticate with the login view.
The second way shows how to authenticate with an added Bearer token to the request header.

4. Login with the Token into the dashboard.
4a. Start a proxy to the dashboard:

kubectl proxy

4b. Access the dashboard in your browser on:
http://localhost:8001/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy/

You will see the warnings as can be seen in the screenshot above. You need to login using the login view, but the login view is not shown by default.

4c. Navigate to the login view:
http://localhost:8001/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy/#!/login

Choose for token and enter the token you gathered with step 3.
Now you have the functionality in the dashboard you expected.

5. Add an Bearer token to authenticate
It is possible to add the needed Bearer token to each request using an addin of Chrome.

5a. Start a tunnel to the Dashboard.
This is an alternative to the login-view approach.
You are used to start the dashboard with kubectl proxy. But this doesn’t work well with  adding headers to a request. Therefor you need to use port-forward:
You will need the name of the Pod of the Dashboard:

kubectl -n kube-system get pods

Find the name of the Pod of the Dashboard and use this name in the port-forward command:

kubectl port-forward kubernetes-dashboard-5ffc5c5558-t2ngc 9090:9090 -n kube-system

5b. Install and configure an extension in Chrome to add request headers for each request to the Dashboard.
For example ModHeader or Requestly are extension which offer this functionality.

Configure the extension with value:
Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImRhc2hib2FyZC10b2tlbi02d3RxYiIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2Vyd

When you access the portal you are authenticated right away.

The configuration of the extensions looks like the following:
ModHeader

Requestly: