Cluster Roles

This lesson builds on Roles and RoleBindings and introduces ClusterRoles and ClusterRoleBindings — the RBAC primitives you use to grant permissions across an entire Kubernetes cluster. Roles and RoleBindings are namespaced objects: they are created inside a namespace (for example, default) and control access only within that namespace.

A slide titled "Roles" showing a dev-user icon pointing to a Developer role. The role card lists permissions: can view PODS, can create PODS, can delete PODS, and can create ConfigMaps.

Cluster-scoped resources, by contrast, are not associated with any namespace. Examples include nodes and PersistentVolumes (PVs). You cannot place a cluster-scoped resource into a namespace (for example, you cannot say node01 is part of the dev namespace) because these resources exist at the cluster scope.

Cluster-scoped resources cannot be created inside a namespace. To list which API resources are namespaced (or not), run kubectl api-resources -o wide and check the NAMESPACED column. See the Kubernetes API resources documentation for more details.

Many Kubernetes objects you manage (Pods, ReplicaSets, Deployments, Services, Secrets, PVCs) are namespaced and are typically managed via Roles and RoleBindings. For cluster-wide resources such as nodes and PVs, use ClusterRoles and ClusterRoleBindings to grant permissions across the whole cluster. ClusterRoles and ClusterRoleBindings themselves are cluster-scoped objects. ClusterRoles are the cluster-wide equivalent of Roles. They are defined the same way — a set of rules that list API groups, resources, and verbs — but their effect applies at cluster scope. For example:

A ClusterRole for a cluster administrator might grant permissions to list, get, create, and delete nodes.
A storage administrator ClusterRole might grant permissions to manage persistentvolumes and persistentvolumeclaims.

A dark slide titled "clusterroles" shows two role cards labeled "Cluster Admin" and "Storage Admin." Each card lists permissions — Cluster Admin can view/create/delete Nodes; Storage Admin can view/create PVs and delete PVCs.

Example: Create a ClusterRole to manage nodes

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-administrator
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["list", "get", "create", "delete"]

To grant that ClusterRole to a user (or a group or ServiceAccount), create a ClusterRoleBinding. The ClusterRoleBinding links subjects to the ClusterRole:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-role-binding
subjects:
- kind: User
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-administrator
  apiGroup: rbac.authorization.k8s.io

You can combine the ClusterRole and ClusterRoleBinding into a single YAML file separated by ---:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-administrator
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["list", "get", "create", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-role-binding
subjects:
- kind: User
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-administrator
  apiGroup: rbac.authorization.k8s.io

Apply the YAML with kubectl:

kubectl apply -f cluster-admin-rolebinding.yaml

Important: ClusterRoles are powerful and flexible. They are not limited to cluster-scoped resources — you can create a ClusterRole that references namespaced resources (for example, pods). When such a ClusterRole is bound using a ClusterRoleBinding, the permissions it grants apply across all namespaces in the cluster (unlike a Role which confines access to a single namespace).

Granting namespaced permissions through a ClusterRole (for example, access to pods) gives the subject access across every namespace. Be deliberate and follow the principle of least privilege when creating ClusterRoles and ClusterRoleBindings.

Earlier, when you created a Role to authorize a user to access Pods, that user had access only to Pods in that specific namespace. With a ClusterRole, authorizing a user to access Pods grants access to Pods across all namespaces. Kubernetes also provisions several ClusterRoles by default. These built-in ClusterRoles (for example, cluster-admin, system:node, system:masters) are used by the system and can be referenced by ClusterRoleBindings. Understanding the built-in roles helps when designing RBAC policies for cluster operators and service accounts. Comparison at a glance

RBAC object	Scope	Use case	Example
Role	Namespaced	Grant permissions limited to a single namespace	`kind: Role` with `resources: ["pods"]`
RoleBinding	Namespaced	Bind a Role to subjects in a namespace	`kind: RoleBinding` referencing a `Role`
ClusterRole	Cluster-wide (but can reference namespaced resources)	Grant permissions across all namespaces or for cluster-scoped resources	`kind: ClusterRole` with `resources: ["nodes"]` or `["pods"]`
ClusterRoleBinding	Cluster-wide	Bind a ClusterRole to subjects for cluster-scoped or all-namespace access	`kind: ClusterRoleBinding` referencing a `ClusterRole`

A slide titled "Cluster Roles" showing a comparison of namespaced vs. cluster-scoped Kubernetes resources. The left (namespaced) column lists items like pods, services, deployments, roles/rolebindings, configmaps and PVCs, while the right lists cluster-scoped items such as nodes, PV, clusterroles/clusterrolebindings, certificate signing requests and namespaces.

Introduction

Core Concepts

Scheduling

Logging & Monitoring

Application Lifecycle Management

Cluster Maintenance

Security

Storage

Networking

Design and Install a Kubernetes Cluster

Install "Kubernetes the kubeadm way"

Troubleshooting

Helm Basics (2025 Updates)

Kustomize Basics (2025 Updates)

Other Topics

Mock Exams

Watch Video

Practice Lab