When I first explored Kubernetes many many years ago, Kubernetes Dashboard was a thing. However, the Dashboard project page says it is now deprecated and unmaintained, recommending Headlamp instead. So let’s install it! But with care, in least-privileged fashion.
As you can see, it contains three resource types: a Service, a Deployment, and a Secret.
The Service definition contains no Type, which means it defaults to ClusterIP. Thus, the Service will only be reachable from within the cluster. That’s not quite what I’m looking for, since I want to access Headlamp from another machine while on my local network. For this use case, the NodePort type is what I want, since it exposes the service on each Node’s IP address, at a static port. So let’s specify a different Type, and 30000 for the NodePort:
At this point, I saved the current configuration in a file called headlamp.yaml.
Granting permissions
If you scroll down to the Accessing Headlamp section of the documentation, it mentions that you can enable access by creating a service account, or by setting up OIDC. I’m going to use a service account since I want to keep things simple.
The main Installation page has commands for creating a Service Account, Cluster Role Binding, and Service Account Token. It also has this enlightening bit of information:
Headlamp uses RBAC for checking users’ access to resources. This means that the recommended way to log in to Headlamp is to use a Service Account token.
Here are the commands, but don’t run them because we’re going to take a different approach. Remember, I want to create a least-privileged installation:
If you look at the second command, it creates a Cluster Role Binding between the headlamp-admin Service Account and the cluster-admin Cluster Role. This seems like a bad idea… I don’t want to give Headlamp “cluster admin” privileges!
If we save our updated headlamp.yaml file and apply it, we should end up with a nearly complete headlamp installation including a Service Account with some minimal permissions.
1
$ kubectl apply -f headlamp.yaml
The only remaining piece is to generate a Service Account Token. Run the command we reviewed previously:
Copy the token, then open http://CLUSTER_IP:30000 in your browser. Paste the token, press the Authenticate button, and you should see the Headlamp UI.
But we’re not done yet …
If you visit the Nodes page, you should see “You don’t have permissions to view this resource”. Expand the “Details” link and you should see:
nodes is forbidden: User “system:serviceaccount:kube-system:headlamp-view” cannot list resource “nodes” in API group "" at the cluster scope
Looks like we need to give our Cluster Role more permissions.
Granting more privileges
Follow the hint given by the error message and update your YAML with additional permissions for your headlamp-view Role:
1
2
3
4
5
6
7
8
- apiGroups:
- ""resources:
- nodesverbs:
- get - list - watch
Re-apply the updated YAML, and refresh the Nodes page. You should see the error message go away.
I continued this process of exploring the UI, and updating the Role with additional permissions as needed. I encountered many new resource types in the process, which helped expand my knowledge of what Kubernetes is capable of.
My final read-only Cluster Role permissions can be found below. Now I can use Headlamp without wondering whether it’s capable of doing something malicious due to having given it too many permissions.