A Role lives in a namespace, so it cannot talk about things that have none: nodes, namespaces, PersistentVolumes, StorageClasses. And a Role has to be recreated in every namespace that needs it. A ClusterRole solves both.
Cluster-scoped rules
kubectl create clusterrole node-reader --verb=get,list --resource=nodes
kubectl create clusterrolebinding ops-read-nodes --clusterrole=node-reader --group=opsA ClusterRoleBinding grants the role everywhere at once. That is the right shape for nodes, and for people who should see every namespace.
The built-in ones
kubectl get clusterroles| ClusterRole | Grants |
|---|---|
view | read most namespaced objects; not Secrets |
edit | view plus create, update, delete on them, and Secrets |
admin | edit plus Roles and RoleBindings in the namespace |
cluster-admin | everything, everywhere |
They exist on every cluster and are kept current with each release, so you rarely need to write "read everything" yourself.
Two ways to bind one
kubectl create rolebinding ana-view --clusterrole=view --user=ana -n shopA RoleBinding may reference a ClusterRole. The rules come from the ClusterRole; the scope comes from the binding's namespace. One definition, granted per namespace, is how most teams hand out edit to developers.
Reading it
kubectl get clusterrolebinding cluster-admin -o yaml
kubectl describe clusterrole view | head -20
kubectl auth can-i get nodes --as anacluster-admin is bound to the group system:masters, which is why the learner may do anything. Nobody else should be in that group.