Skip to main content
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:
For example, you might see an output of 69 cluster roles. Next, determine the number of cluster role bindings with a similar command:
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:
The output may look like this:
Now, inspect the cluster-admin binding in detail:
You should see a section similar to this:
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:
The result includes a policy rule with wildcards:
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:
Bind this role to Michelle by creating a cluster role binding:
Confirm the binding details with:
Finally, test Michelle’s node access:
This should display the list of nodes accessible to her.
Creating targeted roles ensures that team members have only the permissions needed for their current responsibilities.

​
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:
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:
Verify the role with:
You should see output similar to:
Finally, bind the new role to Michelle:
Check the binding details using:
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:
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.
The image shows a terminal output listing Kubernetes resources, their API versions, availability status, and descriptions, likely from a kubectl api-resources command.

​
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.
Leveraging custom roles and bindings not only enhances security by enforcing the principle of least privilege but also simplifies management as responsibilities within the team evolve.

Watch Video