Understanding Kubernetes ClusterRoles and ClusterRoleBindings

Yesterday I learned about Roles and RoleBindings. Today I explored ClusterRoles and ClusterRoleBindings for cluster-scoped resources like Nodes.

Why a Role Wasn't Enough

kubectl auth can-i get nodes

Output:

Warning: resource 'nodes' is not namespace scoped
no

Nodes are cluster-scoped resources, so a namespace Role cannot grant access.

Creating a ClusterRole

kubectl create clusterrole node-reader --verb=get,list,watch --resource=nodes

Verify:

kubectl get clusterrole | grep node-reader

Creating a ClusterRoleBinding

I first made a mistake:

kubectl create clusterrolebinding reader-binding --clusterrole=cluster-reader --user=adeoye

Checking permissions:

kubectl auth can-i get nodes --as adeoye

returned:

no - RBAC: clusterrole.rbac.authorization.k8s.io "cluster-reader" not found

The binding referenced a ClusterRole that didn't exist.

I fixed it by deleting and recreating the binding:

kubectl delete clusterrolebinding reader-binding
kubectl create clusterrolebinding reader-binding --clusterrole=node-reader --user=adeoye

Now:

kubectl auth can-i get nodes --as adeoye

returned:

yes

Testing as adeoye

kubectl config use-context adeoye
kubectl get nodes

Listing nodes worked.

Describing a node:

kubectl describe node cka-cluster3-worker

showed most information, but RBAC blocked access to leases and pods because the ClusterRole only granted access to nodes.

Trying to delete a node:

kubectl delete node cka-cluster3-worker

returned Forbidden because the ClusterRole only included get, list, and watch.

Key Takeaways

• Roles are namespace-scoped.
• ClusterRoles are cluster-scoped.
• ClusterRoleBindings grant cluster-wide permissions.
• RBAC permissions are resource-specific.
• Kubernetes follows the principle of least privilege.