This post shows step-by-step how to set up an RBAC-limited user (via a ServiceAccount resource) from within Lens on a Lens Desktop Kube (LDK) cluster, and how to connect to the cluster as the limited-access user. This should work similarly on any cluster that you have admin privileges for.
The cluster dashboard for LDK with built-in metrics enabled looks something like this:
The Cluster Overview shows various metrics for the nodes in the cluster, and in the sidebar the full list of workloads can be seen, as is expected when connected to a cluster as an admin user, or a user that does not have RBAC limits imposed.
To allow an RBAC-restricted user to access this LDK cluster you need to create some kubernetes resources. In this guide we will create a ClusterRole, ClusterRoleBinding, and a ServiceAccount using Lens.
A ClusterRole defines a set of rules governing access across all namespaces of the cluster. For example the following ClusterRole only allows get, list, and watch access to pods:
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: read-pods
rules:
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- list
- watch
You can add this ClusterRole resource directly in Lens (click the + to the right of the tabs in the dock, select ’Create resource’ and copy/paste the above ClusterRole definition, then click ‘Create’ or ‘Create & Close’):
This cluster role needs to be associated with a user and for that you can create a ClusterRoleBinding:
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: developer-read-only
subjects:
- kind: ServiceAccount
name: developer-reader
namespace: default
roleRef:
kind: ClusterRole
name: read-pods
apiGroup: rbac.authorization.k8s.io
This ClusterRoleBinding associates the read-pods ClusterRole we created above with a ServiceAccount that we’ll create after this. Use Lens again to create this ClusterRoleBinding resource:
Now we need to create a user that will be bound by this ClusterRoleBinding. We will use a ServiceAccount for this as we can use Lens to create it, as well as the necessary authentication token and the kubeconfig allowing Lens to connect to the LDK cluster with the new RBAC-limited user’s credentials.
Go to Access Control in the sidebar and select Service Accounts. Then click the blue-circled + icon at the bottom right of the Service Accounts list. This will bring up the Create Service Account dialog:
To match what was already specified in the ClusterRoleBinding we created above, enter developer-reader for the account name and make sure the namespace is set to default. Then press Create.
You should see the developer-reader service account in the list. Click on it to bring up the details page, then click the Kubeconfig File icon at the top of the details page:
This will bring up the service account kubeconfig dialog:
Download the file to your ~/.kube folder, name it config-sa. It’s a good idea to open it with a text editor and change the context name (find the contexts section, line “- name: Lens Desktop Kube”) from Lens Desktop Kube, since that name is already used for the admin access to the LDK cluster. Here, it is renamed LDK-RO. Go to the cluster list in the catalog and the new cluster (LDK-RO context) should be there, assuming Lens is sync’ing with the ~/.kube folder, which it does by default:
Connecting to the LDK-RO cluster opens the cluster dashboard:
Note that there is no Cluster Overview section, because the developer-reader user does not have access to nodes. The Workload Overview shows only pods, of which there are currently none in the default namespace. No other workloads are visible because the developer-reader user has read access for pods only.
If the LDK-RO cluster fails to connect you may be experiencing a bug with LDK. You will need to inspect the LDK kubeconfig to find the correct server port and edit the LDK-RO kubeconfig (config-sa) to have the matching port.
The following image shows the pods list (at a time when there are pods running in the default namespace). Note only pods are visible in the sidebar under Workloads.
You can edit the ClusterRole created above to change the permissions of the developer-reader user. Remember to first switch back to the Lens Desktop Kube cluster, where you have full permissions in the LDK cluster. In the sidebar open up Access Control and select Cluster Roles. Click on the read-pods cluster role in the list. Click the Edit icon at the top of the details page to open an editor in the dock. Scroll down in the editor to the rules section, and, for example, add - nodes to the resources section:
Click Save or Save & Close and switch back to the LDK-RO cluster. You should disconnect and then reconnect to the LDK-RO cluster to ensure the cluster role changes take effect. You should now see Cluster and Nodes appear in the sidebar as the user now has read permissions for nodes:
Assuming that the Lens built-in metrics were installed on the LDK cluster, observe that the metrics are not available on the Nodes details page (or anywhere). This is because the user needs more permissions. See the followup post to learn how to enable metrics for an RBAC-limited user.