Kubernetes Cluster Scoped Access

Kubernetes Cluster Scoped Access is the category of permission that applies across the entire cluster rather than being confined to a single namespace, granted through ClusterRole objects bound with ClusterRoleBindings, and required for any interaction with resources that have no namespace at all. It represents the broadest and most consequential tier of Kubernetes authorization, encompassing both the objects that structurally cannot be namespace-scoped and the administrative operations that are deliberately designed to affect the whole cluster.

Resources That Require Cluster Scope

Inherently Cluster-Scoped Objects

Node, PersistentVolume, Namespace, ClusterRole, ClusterRoleBinding, StorageClass, and CustomResourceDefinition all exist outside any namespace, so granting access to them is only possible through a ClusterRole — there is no namespaced equivalent to fall back on.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: storage-admin
rules:
- apiGroups: ["storage.k8s.io"]
  resources: ["storageclasses"]
  verbs: ["get", "list", "watch", "create", "update", "delete"]
- apiGroups: [""]
  resources: ["persistentvolumes"]
  verbs: ["get", "list", "watch"]

Cluster-Wide Views Across Namespaces

Even for namespaced resources like pods or deployments, an operation that spans every namespace at once — kubectl get pods --all-namespaces, for instance — requires a ClusterRoleBinding (or a ClusterRole bound in every namespace individually), since a single RoleBinding only ever grants visibility into its own namespace.

Granting Cluster-Scoped Access

ClusterRoleBinding as the Delivery Mechanism

A ClusterRoleBinding is the only object capable of granting a ClusterRole's permissions cluster-wide; binding the same ClusterRole through a RoleBinding instead confines its effect to a single namespace, so the choice of binding type — not the role definition itself — determines whether access is namespace-scoped or cluster-scoped.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: storage-admins
subjects:
- kind: Group
  name: storage-team
roleRef:
  kind: ClusterRole
  name: storage-admin
  apiGroup: rbac.authorization.k8s.io

Built-In Cluster-Scoped Roles

cluster-admin grants unrestricted access to every resource in every namespace plus all cluster-scoped resources; more narrowly, roles like system:node, system:kube-scheduler, and system:kube-controller-manager grant exactly the cluster-scoped access each control-plane component needs to function, serving as a model for how to scope custom cluster-wide roles narrowly rather than defaulting to cluster-admin.

Governance for Cluster-Scoped Access

Smaller, More Trusted Grant Pool

Because cluster-scoped access affects every namespace and every tenant sharing the cluster, the set of identities holding any ClusterRoleBinding — not just cluster-admin — should be materially smaller and more carefully vetted than the set of identities holding namespace-scoped permissions.

Separating Cluster-Scoped Administration From Application Operations

Platform teams responsible for nodes, storage classes, and custom resource definitions typically hold distinct cluster-scoped roles from application teams, who should rarely if ever need cluster-scoped access for ordinary day-to-day deployment and operational work.

Auditing Cluster-Scoped Grants

Enumerating Cluster-Wide Bindings

kubectl get clusterrolebindings -o wide lists every cluster-scoped grant in one call, in contrast to namespace-scoped access which must be reconstructed namespace by namespace; this makes cluster-scoped access, despite being the higher-risk category, also the easier one to audit comprehensively in a single pass.

kubectl get clusterrolebindings -o json | \
  jq '.items[] | {name: .metadata.name, role: .roleRef.name, subjects: .subjects}'

Reviewing Cluster-Scoped Resource Access Specifically

Beyond reviewing ClusterRoleBinding subjects, auditing which ClusterRoles grant access to genuinely cluster-scoped resources (nodes, persistent volumes, CRDs) — as opposed to ClusterRoles that merely bundle namespaced resource access for reuse across namespaces — clarifies which grants actually carry cluster-wide consequence versus which are simply reusable templates applied narrowly.

Common Risks

Unnecessary Cluster-Scoped Grants for Namespaced Needs

Granting cluster-scoped access to satisfy a need that is genuinely namespace-specific — binding a ClusterRole with a ClusterRoleBinding when a RoleBinding would have sufficed — needlessly expands a subject's reach and should be caught during access request review.

Node and Persistent Volume Access as an Escalation Path

Broad access to Node objects or PersistentVolumes can, depending on the cluster's configuration, provide a path toward broader compromise — for example, through node-level secrets or volumes containing sensitive data from multiple namespaces — making these particular cluster-scoped resources worth restricting even more tightly than other cluster-scoped grants.