liveBook · Manning

Clusterrole

As explained in Acing the Certified Kubernetes Administrator Exam, Second Edition

A cluster role is a Kubernetes RBAC object that defines permissions for cluster-scoped resources or permissions usable across namespaces.

A ClusterRole defines RBAC permissions for cluster-scoped resources, such as nodes, persistent volumes, and namespaces. Unlike a Role, it is not confined to one namespace. Its rules specify resources and permitted verbs, such as get, list, create, or delete; a binding grants those rules to a user, group, or ServiceAccount. section 3.1.1 section 9.3.2

Choose the binding to match the intended reach:

  • Use a ClusterRoleBinding to grant a ClusterRole's permissions cluster-wide. section 3.1.1
  • Use a RoleBinding to grant permissions from a ClusterRole within one namespace. A ClusterRoleBinding cannot reference a Role. section 3.1.1 section 3.3

Check an existing grant

Run `kubectl get clusterrole` to find available ClusterRoles. The built-in `cluster-admin`, `admin`, `edit`, and `view` roles offer different levels of access; do not assume that `view` includes Secrets or that `edit` permits changing roles. After binding a role, check a particular subject and action with `kubectl auth can-i`, for example `kubectl auth can-i get pods -n default --as carol`. section 3.1.2 section 3.1.1

kubectl get clusterrolebinding kubeadm:cluster-admins -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  creationTimestamp: "2025-09-02T19:09:30Z"
  name: kubeadm:cluster-admins
  resourceVersion: "241"
  uid: 4b7e6cba-c951-431e-af88-32958326de97
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: kubeadm:cluster-admins

Inspect the ClusterRoleBinding YAML: `roleRef` names the `cluster-admin` ClusterRole, while `subjects` identifies the group receiving it. section 3.1.2

For practice, define a ClusterRole allowing `create` on Deployments, ReplicaSets, and DaemonSets, then bind it to a ServiceAccount only in the default namespace. Verify with `kubectl auth can-i` that the ServiceAccount cannot create Deployments in `kube-system`. The check catches a binding whose reach is broader than intended. section 3.3

How Acing the Certified Kubernetes Administrator Exam, Second Edition covers it

How deep it goes
Explains permission verbs, resource scope, binding combinations, built-in roles, and verification without descending into RBAC implementation internals.
Examples
Uses built-in ClusterRole listings, a ClusterRoleBinding manifest, and a namespace-restricted ServiceAccount practice task.
What it assumes
Assumes basic familiarity with Kubernetes resources and kubectl while explaining RBAC roles, permission verbs, and namespace scope.
What you can do after
Operate/configure ClusterRole grants with an appropriate binding and verify a subject's permissions using `kubectl auth can-i`.
How it connects
Connects ClusterRoles to RBAC, Roles, RoleBindings, ClusterRoleBindings, namespaces, and ServiceAccounts.
Cover of Acing the Certified Kubernetes Administrator Exam, Second Edition
liveBookmanning.com
Read Acing the Certified Kubernetes Administrator Exam, Second Edition on liveBook Get the book at manning.com

Also explained in

Compare how 3 books explain clusterrole →

This explainer was generated by Manning's knowledge graph from the text of Acing the Certified Kubernetes Administrator Exam, Second Edition. The section links point to the parts of the book it draws on.