A ClusterRoleBinding grants a ClusterRole’s permissions to specified users, groups, or Service Accounts across the cluster. RBAC uses the binding when deciding whether a subject may perform a requested action on the Kubernetes API. section 3.1 section 9.3.2
Choose the binding by the scope of access needed:
- Use a RoleBinding for permissions confined to a namespace. It can reference a Role or a ClusterRole. section 3.1.1
- Use a ClusterRoleBinding to grant a ClusterRole across the cluster. It cannot reference a namespaced Role. section 3.1.1 section 3.4
Grant and check cluster-wide viewing
Run `kubectl create clusterrolebinding audit-view --clusterrole=view --user=auditor`, then inspect it with `kubectl get clusterrolebinding audit-view -o yaml`. Check the resulting access with `kubectl auth can-i get pods -n default --as=auditor` and repeat the check in another namespace. The built-in `view` ClusterRole excludes Secrets; other bindings may still grant the user additional access. 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 an existing ClusterRoleBinding manifest: `roleRef` names the `cluster-admin` ClusterRole, while `subjects` names the group receiving its permissions. The `cluster-admin` role has full access, so check the subject before assigning it. section 3.1.2
Some default ClusterRoleBindings are managed by the control plane. The API server can restore missing subjects in those bindings, so inspect an existing binding before treating it as a permanent manual change. section 3.1.2
