In this lesson, you will learn how to leverage ClusterRoles to grant permissions that transcend individual namespaces or apply to cluster-wide resources.
Why Cluster-Wide Permissions?
While Roles and RoleBindings are perfect for restricting a user or a service account to a specific sandbox, they fall short when you need to interact with cluster-level resources like Nodes, PersistentVolumes, or Namespaces themselves. Additionally, if you need the same set of permissions to apply uniformly across every namespace in your cluster, creating a Role in every single namespace would be a tedious, error-prone manual task.
ClusterRoles solve this by defining a set of rules that are "cluster-scoped." They exist outside the namespace hierarchy, making them the standard choice for system-wide controllers, monitoring agents, or cluster administrators.
Implementing a ClusterRole
A ClusterRole follows the same structure as a Role, but it does not require a namespace field in its metadata. Here is an example of a ClusterRole that allows read-only access to nodes across the entire cluster:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: node-reader
rules:
- apiGroups: [""]
resources: ["nodes"]
verbs: ["get", "list", "watch"]
Binding the Permission
To activate this ClusterRole, you must create a ClusterRoleBinding. Unlike a RoleBinding, a ClusterRoleBinding links the ClusterRole to a subject (a user, group, or service account) for the entire cluster.
If you wanted to grant these node-reading permissions to a service account, you would apply the following:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: read-nodes-global
subjects:
- kind: ServiceAccount
name: observability-agent
namespace: monitoring
roleRef:
kind: ClusterRole
name: node-reader
apiGroup: rbac.authorization.k8s.io
By using ClusterRoles, you ensure that your security policy remains centralized and consistent. Whether you are managing cluster-level storage or auditing resource usage across all tenants, this approach provides the administrative leverage required for secure, high-level cluster management.
Key Takeaway: Use ClusterRoles to manage non-namespaced resources or to apply uniform, cluster-wide permissions without duplicating configuration across individual namespaces.