Even though I'm not Kubernetes Dashboard user, I understand why it is the easiest way for most people to interact with their apps running on top of Kubernetes. If you are interacting with it daily or managing the cluster itself, you are probably more fine with CLI, aka kubectl. Kubernetes Dashboard is easy to install, but you might want to have it per namespace and to limit what users can do. Let's see how to install and configure it for this scenario.
The latest version of Kubernetes dashboard v2.0 is running without a
cluster-admin role, which was too dangerous. On top of that, all secrets are explicitly created, and ServiceAccount doesn't have permission to create any secret. This is excellent news. But, you probably want to limit users for touching anything that is not part of their namespace. Or even more, make it read-only and disable access to some sensitive info, like secrets.
Installation and Configuration
Kubernetes Dashboard does have namespace support. Installing the dashboard is a pretty straightforward process. So, let's say you want to install it in the
default namespace. First, create a custom config for kubernetes-dashboard helm chart:
cat > values-dashboard.yaml<<EOF extraArgs: - --system-banner="Test Cluster" - --namespace=default metricsScraper: enabled: true EOF
NOTE: If you have a single sign-on solution with ingress, you can set
--enable-insecure-login extra args to disable dashboard authentication. With ingress terminating SSL, you need to set
protocolHttp: true as well.
In the above config, I enabled metrics scraper. It is required to have a metrics server running in the cluster for this to work. If you don't have it installed, you can enable it via config.
Let's make this dashboard read only by adding custom role:
cat > kubernetes-dashboard-role.yaml<<EOF apiVersion: rbac.authorization.k8s.io/v1beta1 kind: Role metadata: name: dash-kubernetes-dashboard-read-only rules: - apiGroups: - "*" resources: - configmaps - cronjobs - daemonsets - deployments - events - ingresses - jobs - persistentvolumeclaims - persistentvolumes - pods - pods/log - replicasets - replicationcontrollers - services - statefulsets verbs: - describe - get - list - watch EOF cat > kubernetes-dashboard-rolebinding.yaml<<EOF apiVersion: rbac.authorization.k8s.io/v1beta1 kind: RoleBinding metadata: name: dash-kubernetes-dashboard-read-only labels: app: kubernetes-dashboard roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: dash-kubernetes-dashboard-read-only subjects: - kind: ServiceAccount name: dash-kubernetes-dashboard namespace: default EOF
NOTE: Set a preferred namespace -
default in this case.
The last step it to apply all those resources and to install the dashboard:
kubectl apply -f kubernetes-dashboard-role.yaml -n default kubectl apply -f kubernetes-dashboard-rolebinding.yaml -n default helm repo add kubernetes-dashboard https://kubernetes.github.io/dashboard/ helm install --name dash \ --namespace default \ -f values-dashboard.yaml \ kubernetes-dashboard/kubernetes-dashboard
You can go ahead and check if the dashboard works as expected. If you try to list namespaces or check cluster-wide resources, you will get
the namespaces is forbidden error message, which is what you wanted to achieve by running it per namespace. You can further adjust `dash-kubernetes-dashboard-read-only` role to make it work for your use case.
Installing a Kubernetes Dashboard per namespace and with limited options is a simple way of adding more visibility to the Kubernetes cluster without violating security. Stay tuned for the next one.