Skip to main content
In this lesson, we will explore the concepts of cluster roles and cluster role bindings. We will inspect the existing cluster roles and their bindings, count them, and review their permissions before creating new roles and bindings for a new team member named Michelle.

​
Inspecting Existing Cluster Roles

Begin by examining the currently defined cluster roles in your cluster. These roles include cluster-admin, system-specific roles, and others. Run the following command to list them:
You can count these roles manually by piping the output to wc -l. For example:
On one system, this command produced an output of 6, but keep in mind that this example shows a truncated list. In another instance, a total of 69 roles might be expected using a different counting method.
Cluster roles are cluster-scoped and are not limited to any namespace.

​
Inspecting Cluster Role Bindings

Next, verify the cluster role bindings by counting them with the following command:
This command returned 54 on the system in question, indicating that there are 54 cluster role bindings. To illustrate further, here is an excerpt displaying some cluster roles and their creation times:
Both cluster roles and cluster role bindings are applied across the entire cluster and are not namespace-specific.

​
Reviewing Cluster Admin Role Bindings

The cluster-admin role represents the highest permission level and is bound to specific user groups via a ClusterRoleBinding. To identify the binding for the cluster-admin role, run:
The output may appear as follows:
You can then inspect the details of the cluster-admin binding with:
This command produces output similar to:
This confirms that the cluster-admin role is bound by default to the system:masters group, thereby granting all possible operations (denoted by [*] for all actions on all resources).
Exercise caution when modifying cluster roles as they affect permissions across the entire cluster.

​
Granting Node Access to a New User (Michelle)

Michelle, a new team member, requires access to manage nodes. Initially, when Michelle runs:
she encounters the following error:
To resolve this issue, follow these steps:

​
Create the Cluster Role for Node Access

Create a cluster role named michelle-role that allows Michelle to get, list, and watch nodes:
Verify the new role by describing it:
Expected output:

​
Bind the Cluster Role to Michelle

Bind the role to Michelle’s user account with:
Verify this binding with:
Expected output:
Finally, test Michelle’s access again:
A successful command execution will display a list of nodes similar to:

​
Expanding Michelle’s Responsibilities to Storage

Michelle’s roles are expanding to include storage management. To grant her access to storage-related resources, first verify the available API resources by running:
This command lists resources along with their short names, API versions, and scope. For storage management, the key resources are persistent volumes and storage classes.

​
Create a Cluster Role for Storage Administration

Create a cluster role named storage-admin that allows listing, creating, getting, and watching persistent volumes and storage classes:
Verify the role in YAML format using:
An expected YAML output is as follows:

​
Bind the Storage Admin Role to Michelle

Bind the storage-admin role to Michelle with the following command:
Verify this binding:
Expected output:
Michelle should now have the necessary permissions to manage storage resources such as persistent volumes and storage classes.
This concludes the lesson on inspecting, creating, and binding cluster roles and cluster role bindings. By following these steps, you learned how to review existing roles, grant specific permissions to a user, and expand those permissions as job responsibilities change.

Watch Video