Solution Cluster Roles

In this lab article, we explore Kubernetes cluster roles and cluster role bindings. You will learn how to inspect existing roles and bindings, then create custom roles and bindings for a team member named Michelle. Follow along for step-by-step commands and detailed explanations.

Inspecting Cluster Roles and Cluster Role Bindings

Begin by counting the defined cluster roles. Since these objects are cluster-wide (not namespaced), run the command:

k get clusterroles --no-headers | wc -l

For example, you might see an output of 69 cluster roles.

Next, determine the number of cluster role bindings with a similar command:

k get clusterrolebindings --no-headers | wc -l

This command returns 54. Note that although the cluster-admin role will appear in the list, both cluster roles and their bindings apply across the entire cluster.

Examining the Cluster Admin Role Binding

To view the user groups associated with the cluster-admin role, filter the cluster role bindings with:

k get clusterrolebindings | grep cluster-admin

The output may look like this:

cluster-admin                       12m   ClusterRole/cluster-admin
helm-kube-system-traefik           12m   ClusterRole/cluster-admin
helm-kube-system-traefik-crd       12m   ClusterRole/cluster-admin

Now, inspect the cluster-admin binding in detail:

k describe clusterrolebindings cluster-admin

You should see a section similar to this:

Name:         cluster-admin
Labels:       kubernetes.io/bootstrapping=rbac-defaults
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
Role:
  Kind:    ClusterRole
  Name:    cluster-admin
Subjects:
  Kind    Name              Namespace
  ----    ----              ---------
  Group   system:masters

This output confirms that the cluster-admin role is bound to the system:masters group.

To understand the full range of permissions granted, describe the cluster role itself:

k describe clusterrole cluster-admin

The result includes a policy rule with wildcards:

Name:         cluster-admin
Labels:       kubernetes.io/bootstrapping=rbac-defaults
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
PolicyRule:
  Resources        Non-Resource URLs  Resource Names  Verbs
  ___________      _________________  ______________  _____
  **               []                 []              [*]

This rule signifies that the cluster-admin role can perform any action on any resource within the cluster.

Granting Node Access to Michelle

Suppose Michelle, a new team member, requires access to view nodes. Even though the cluster-admin role grants full privileges, creating a custom role for node-specific operations can enforce a principle of least privilege.

Create a cluster role named michelle-role with the permissions get, list, and watch on nodes:

kubectl create clusterrole michelle-role --verb=get,list,watch --resource=nodes

Bind this role to Michelle by creating a cluster role binding:

kubectl create clusterrolebinding michelle-role-binding --clusterrole=michelle-role --user=michelle

Confirm the binding details with:

k describe clusterrolebinding michelle-role-binding

Finally, test Michelle’s node access:

k get nodes --as michelle

This should display the list of nodes accessible to her.

Extending Michelle’s Permissions to Storage

As Michelle’s responsibilities expand, she now requires access to storage resources, such as persistent volumes and storage classes.

First, review available API resources to verify the exact resource names and versions:

kubectl api-resources

This command lists all available resources along with their short names, API groups, and versions.

Create a new cluster role called storage-admin with permissions to list, create, get, and watch on persistent volumes and storage classes:

k create clusterrole storage-admin --resource=persistentvolumes,storageclasses --verb=list,create,get,watch

Verify the role with:

k describe clusterrole storage-admin

You should see output similar to:

Name: storage-admin
PolicyRule:
  Resources                             Non-Resource URLs  Resource Names  Verbs
  persistentvolumes                     []                 []              [list create get watch]
  storageclasses.storage.k8s.io         []                 []              [list create get watch]

Finally, bind the new role to Michelle:

k create clusterrolebinding michelle-storage-admin --user=michelle --clusterrole=storage-admin

Check the binding details using:

k describe clusterrolebinding michelle-storage-admin

This confirms that Michelle now has the necessary permissions to manage storage resources.

Kubernetes API Resources Overview

For a complete overview of Kubernetes resources, including their short names and API versions, use the following command:

kubectl api-resources

This command outputs a detailed list, including items such as:

• nodes (no) with API version v1
• persistentvolumeclaims (pvc) with API version v1
• pods (po) with API version v1
• … and many more resources

This overview is invaluable when you create resource definitions and need to know whether a resource is namespaced or available cluster-wide.

Conclusion

In summary, this article guided you through inspecting cluster roles and cluster role bindings in Kubernetes. You examined the cluster-admin role and its binding to the system:masters group, then created a tailored role and binding for Michelle to access nodes. Finally, you extended her permissions to cover storage resources by setting up a storage-admin role and the corresponding binding. These steps illustrate how Kubernetes RBAC can be efficiently adapted to meet evolving team responsibilities.