CKA Day 24 — Kubernetes RBAC Continued: ClusterRole and ClusterRoleBinding

Day 24 of the 40-day CKA course by Tech Tutorials with Piyush. This session continues the RBAC deep-dive from Day 23, shifting focus from namespace-scoped Roles and RoleBindings to cluster-scoped ClusterRoles and ClusterRoleBindings. The lesson demonstrates when cluster-wide permissions are required, how to create them imperatively and declaratively, and the critical distinction between binding a ClusterRole inside a single namespace versus across the entire cluster.

Key Takeaways

ClusterRole vs Role

A ClusterRole is structurally identical to a Role but operates at cluster scope. It can grant permissions on:

• Cluster-scoped resources such as Nodes, PersistentVolumes, Namespaces, and ClusterRoles themselves
• Namespace-scoped resources across all namespaces — for example, listing every Pod in every Namespace
• Non-resource URLs such as /healthz or /metrics for API server health and metrics endpoints

Whereas a Role is confined to one Namespace, a ClusterRole is not bound to any Namespace in its definition. Its effective scope is determined by the binding object that references it.

ClusterRoleBinding vs RoleBinding

The binding object determines where the permissions apply:

Binding Type	Scope	Can Reference	Result
RoleBinding	Single Namespace	Role or ClusterRole	Grants permissions only inside that Namespace
ClusterRoleBinding	Entire cluster	ClusterRole only	Grants permissions everywhere in the cluster

A common production pattern is to bind a built-in ClusterRole like edit or view with a RoleBinding inside a specific Namespace. This gives a user or group cluster-level permissions (on many resource types) but restricts them to one Namespace. Conversely, a ClusterRoleBinding to cluster-admin grants full cluster-wide superuser access.

Built-in ClusterRoles Revisited

Kubernetes ships with default ClusterRoles that are designed for reuse:

• cluster-admin — Full control over all resources cluster-wide. Equivalent to root.
• admin — Full control within a Namespace, including Role and RoleBinding management. Cannot modify cluster-scoped resources.
• edit — Read/write on most namespace resources, excluding RBAC objects.
• view — Read-only on most namespace resources.

These are typically bound with RoleBindings for namespace-level delegation or ClusterRoleBindings for cluster-wide access.

Imperative Generation for Exam Speed

The CKA exam rewards imperative command fluency:

# Create a ClusterRole imperatively
kubectl create clusterrole node-reader --verb=get,list --resource=nodes --dry-run=client -o yaml
 
# Create a ClusterRoleBinding imperatively
kubectl create clusterrolebinding node-reader-binding --clusterrole=node-reader --user=alice --dry-run=client -o yaml
 
# Bind a built-in ClusterRole cluster-wide
kubectl create clusterrolebinding alice-admin --clusterrole=cluster-admin --user=alice --dry-run=client -o yaml

Exam trap: kubectl create clusterrolebinding only accepts --clusterrole, never --role. Using --role produces an error because ClusterRoleBindings require ClusterRoles.

Practical Demo Workflow

The lesson follows a hands-on pattern similar to Day 23:

1. Create a user with client certificates (or reuse an existing user like “krishna” from Day 23).
2. Create a ClusterRole defining permissions on cluster-scoped resources (e.g., get/list on nodes).
3. Create a ClusterRoleBinding attaching the ClusterRole to the user.
4. Verify permissions with kubectl auth can-i list nodes --as <user> (no namespace flag needed for cluster-scoped checks).
5. Test namespace-scoped access to confirm the cluster-wide binding also grants cross-namespace visibility where the rules allow.

Non-Resource URLs

ClusterRoles uniquely support nonResourceURLs for paths that do not map to Kubernetes API objects:

rules:
- nonResourceURLs: ["/healthz", "/metrics"]
  verbs: ["get"]

This is used by monitoring systems and health-check proxies that need to scrape the API server without accessing actual resources.

The RoleBinding + ClusterRole Pattern

Perhaps the most important pattern for the exam and production: a RoleBinding can reference a ClusterRole. This avoids duplicating Role definitions across dozens of Namespaces. You define the permissions once in a ClusterRole, then create a RoleBinding in each Namespace that needs those permissions. The user gets the ClusterRole’s rules, but only within the Namespace of the RoleBinding.

# Grant "edit" permissions in the "dev" namespace only
kubectl create rolebinding dev-edit --clusterrole=edit --user=dev1 --namespace=dev

---

See Also

Wiki Concepts

• Kubernetes RBAC — Deep dive into all four RBAC objects, rule anatomy, and testing patterns
• Kubernetes Authentication & Authorization — The two-gate security model and request pipeline
• Kubernetes Kubeconfig — Context switching and user identity for RBAC testing
• Kubernetes Namespaces — Scope boundaries and the RoleBinding + ClusterRole pattern
• Kubernetes Architecture — API server request flow and cluster-scoped resources
• TLS Fundamentals — Client certificate authentication underpinning RBAC users
• Kubernetes ConfigMaps and Secrets — Namespace-scoped resources governed by RBAC

Related Sources

• CKA Day 23 — Kubernetes RBAC Explained — Namespace-scoped Roles and RoleBindings
• CKA Day 22 — Kubernetes Authentication and Authorization — AuthN/AuthZ pipeline
• CKA Day 21 — Manage TLS Certificates — Client cert creation for RBAC users

Creator / Entity

• Tech Tutorials with Piyush — Day 24 of the 40-day CKA course