ClusterRole and ClusterRoleBinding

Namespaced Roles can't grant access to cluster-scoped resources (nodes, PVs, namespaces, CSRs) or apply across all namespaces at once. Cluster-wide permissions need a cluster-scoped RBAC mechanism.

Solution: Use a ClusterRole + ClusterRoleBinding for cluster-scoped resources (nodes, PVs) or to grant the same permissions across all namespaces.

Now hand a senior engineer a master keycard that opens doors in every building across the whole port, not just one. The same card also reaches shared facilities that belong to no single building at all, the main gates, the rail yard, the perimeter fence. In Kubernetes a ClusterRole is that port-wide list of doors, a ClusterRoleBinding is the master card linking it to a person, and together they grant access across all namespaces plus cluster-scoped resources like nodes that no namespace owns.

The same cluster entities appear in every day's notes; the <== marks what this day touches.

Role/RoleBinding (Day 23) are namespaced — they can't grant access to:

   - cluster-scoped resources: nodes, persistentvolumes, namespaces, CSRs
   - resources across ALL namespaces at once

ClusterRole + ClusterRoleBinding solve exactly that.

RBAC has two tiers: namespaced objects (Role + RoleBinding) and cluster-wide objects (ClusterRole + ClusterRoleBinding). The binding decides the scope.

   SCOPE        PERMISSIONS        BINDING
   namespace    Role               RoleBinding         -> one namespace
   cluster      ClusterRole        ClusterRoleBinding  -> whole cluster

Concretely, that means each permission object can reach a different set of resources:

   Role         -> verbs on namespaced resources, in ONE namespace
   ClusterRole  -> verbs on cluster-scoped resources, OR namespaced
                   resources across EVERY namespace

Trick: a ClusterRole can be reused by a RoleBinding to grant it in just one namespace — write the permission once, scope it where you like.

Ask the API which resources live outside namespaces — those are the ones that require a ClusterRole to grant access.

kubectl api-resources --namespaced=false    # cluster-scoped (nodes, pv, ns...)
kubectl api-resources --namespaced=true     # namespaced (pods, svc, cm...)

A ClusterRole defines a set of verbs on resources, just like a Role, but it is not tied to any namespace.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-reader
rules:
  - apiGroups: [""]
    resources: ["nodes"]
    verbs: ["get", "list", "watch"]

A ClusterRoleBinding attaches a ClusterRole to a subject across the entire cluster, every namespace included.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: node-reader-binding
subjects:
  - kind: User
    name: adam
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: node-reader
  apiGroup: rbac.authorization.k8s.io

The same objects can be created in one line with kubectl create, handy in the exam and for quick experiments.

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

kubectl create clusterrolebinding node-reader-binding \
  --clusterrole=node-reader --user=adam

Use kubectl auth can-i with --as to confirm the binding actually grants the access you intended.

kubectl auth can-i list nodes --as adam        # -> yes (cluster-wide)
kubectl auth can-i get pods  --as adam -A      # only if also granted

Kubernetes ships with default ClusterRoles you can bind directly instead of writing your own.

   cluster-admin -> god mode (all verbs, all resources) — handle with care
   admin / edit  -> common namespace-level roles (used via RoleBinding)
   view          -> read-only

Nodes live outside any namespace, so only a ClusterRole can grant access.

Cluster-scoped resources like nodes can only be granted through a ClusterRole.

• ClusterRole/ClusterRoleBinding = cluster-wide RBAC.
• Needed for cluster-scoped resources (nodes, PVs, namespaces, CSRs) and for granting access across all namespaces.
• A ClusterRole can be bound by a RoleBinding to limit it to one namespace.
• Use kubectl api-resources --namespaced=false to see what's cluster-scoped.

• [ ] Listed cluster-scoped resources with api-resources --namespaced=false
• [ ] Created a node-reader ClusterRole + ClusterRoleBinding
• [ ] Verified kubectl auth can-i list nodes --as adam
• [ ] Understand reusing a ClusterRole via a RoleBinding for one namespace