> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Solution Cluster Roles > This article explores cluster roles and bindings, detailing how to inspect, create, and assign permissions for users in a Kubernetes environment. 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: ```plaintext theme={null} system:volume-scheduler system:certificates.k8s.io:legacy-unknown-approver system:certificates.k8s.io:kubelet-serving-approver system:certificates.k8s.io:kube-apiserver-client-approver system:certificates.k8s.io:kube-apiserver-client-kubelet-approver system:service-account-issuer-discovery system:node-proxier system:kube-scheduler system:controller:attacheddetach-controller system:controller:clusteroverlay-aggregation-controller system:controller:cronjob-controller system:controller:daemon-set-controller system:controller:deployment-controller system:controller:endpoint-controller system:controller:endpointslice-mirroring-controller system:controller:expand-controller system:controller:ephemeral-volume-controller system:controller:generic-garbage-collector system:controller:job-controller system:controller:namespace-controller system:controller:node-controller system:controller:persistent-volume-binder system:controller:garbage-collector system:controller:replicaset-controller system:controller:replication-controller system:controller:resourcequota-controller system:controller:service-account-controller system:controller:service-controller system:controller:statefulset-controller system:controller:ttl-controller system:controller:vertical-pod-autoscaler system:controller:volume-protection-controller system:controller:ttl-after-finished-controller system:controller:root-ca-cert-publisher k3s-cloud-controller-manager ``` You can count these roles manually by piping the output to `wc -l`. For example: ```bash theme={null} k get clusterroles --no-headers | wc -l ``` 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: ```bash theme={null} k get clusterrolebindings --no-headers | wc -l ``` 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: ```bash theme={null} k get clusterroles NAME CREATED AT cluster-admin 2022-04-18T00:01:23Z system:discovery 2022-04-18T00:01:23Z system:monitoring 2022-04-18T00:01:23Z system:basic-user 2022-04-18T00:01:23Z system:public-info-viewer 2022-04-18T00:01:23Z system:aggregate-to-admin 2022-04-18T00:01:23Z system:aggregate-to-edit 2022-04-18T00:01:23Z system:aggregate-to-view 2022-04-18T00:01:23Z system:heapster 2022-04-18T00:01:23Z system:node 2022-04-18T00:01:23Z ... ``` 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: ```bash theme={null} k get clusterrolebindings | grep cluster-admin ``` The output may appear as follows: ```bash theme={null} cluster-admin 12m ClusterRole/cluster-admin helm-kube-system-traefik 12m ClusterRole/cluster-admin helm-kube-system-traefik-crd 12m ClusterRole/cluster-admin ``` You can then inspect the details of the cluster-admin binding with: ```bash theme={null} k describe clusterrolebindings cluster-admin ``` This command produces output similar to: ```YAML theme={null} Name: cluster-admin Labels: kubernetes.io/bootstraping=rbac-defaults Annotations: rbac.authorization.kubernetes.io/autoupdate: true Role: Kind: ClusterRole Name: cluster-admin Subjects: Kind Name Namespace ----- ------------------- ----------- Group system:masters ``` 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: ```bash theme={null} k get nodes --as michelle ``` she encounters the following error: ```yaml theme={null} Error from server (Forbidden): nodes is forbidden: User "michelle" cannot list resource "nodes" in API group "" at the cluster scope ``` 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: ```bash theme={null} k create clusterrole michelle-role --verb=get,list,watch --resource=nodes ``` Verify the new role by describing it: ```bash theme={null} k describe clusterrole michelle-role ``` Expected output: ```yaml theme={null} Name: michelle-role Labels: Annotations: PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- --------------- --------- nodes [] [] [get list watch] ``` ### Bind the Cluster Role to Michelle Bind the role to Michelle’s user account with: ```bash theme={null} k create clusterrolebinding michelle-role-binding --clusterrole=michelle-role --user=michelle ``` Verify this binding with: ```bash theme={null} k describe clusterrolebinding michelle-role-binding ``` Expected output: ```text theme={null} Name: michelle-role-binding Labels: Annotations: Role: Kind: ClusterRole Name: michelle-role Subjects: Kind Name Namespace ---- ---- --------- User michelle ``` Finally, test Michelle’s access again: ```bash theme={null} k get nodes --as michelle ``` A successful command execution will display a list of nodes similar to: ```text theme={null} NAME STATUS ROLES AGE VERSION controlplane Ready control-plane,master 16m v1.23.3+k3s1 ``` *** ## 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: ```bash theme={null} kubectl api-resources ``` 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: ```bash theme={null} k create clusterrole storage-admin --resource=persistentvolumes,storageclasses --verb=list,create,get,watch ``` Verify the role in YAML format using: ```bash theme={null} k get clusterrole storage-admin -o yaml ``` An expected YAML output is as follows: ```yaml theme={null} apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: creationTimestamp: "2022-04-18T00:20:48Z" name: storage-admin resourceVersion: "921" uid: e0ee52a7-b32c-4a42-bb7a-a783b040cd4e rules: - apiGroups: - "" resources: - persistentvolumes verbs: - list - create - get - watch - apiGroups: - storage.k8s.io resources: - storageclasses verbs: - list - create - get - watch ``` ### Bind the Storage Admin Role to Michelle Bind the `storage-admin` role to Michelle with the following command: ```bash theme={null} k create clusterrolebinding michelle-storage-admin --user=michelle --clusterrole=storage-admin ``` Verify this binding: ```bash theme={null} k describe clusterrolebinding michelle-storage-admin ``` Expected output: ```text theme={null} Name: michelle-storage-admin Labels: Annotations: Role: Kind: ClusterRole Name: storage-admin Subjects: Kind Name Namespace ---- ---- --------- User michelle ``` 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.