Kubernetes RBAC: Roles vs. ClusterRoles

WHY IT EXISTS: Kubernetes needs a granular way to control who can do what. Without a system like Role-Based Access Control (RBAC), anyone with cluster access could potentially view secrets or delete critical components. RBAC provides a structured API to enforce the principle of least privilege for both human users and automated processes.

THE MENTAL MODEL: An RBAC Role is a keycard for a specific floor in an office building (a Kubernetes Namespace). It defines what you can do on that floor, like use the printer (create pods) or look in a filing cabinet (get secrets). A ClusterRole is a master keycard that works on every floor and also opens special rooms like the server room (nodes) that don't belong to any single floor. A RoleBinding or ClusterRoleBinding is the act of giving a person (a User or ServiceAccount) one of these keycards.

HOW IT WORKS: RBAC is defined by four object types. First, a Role contains rules that grant permissions (verbs like get, list, create) on a set of resources (pods, deployments) within a single namespace. Second, a ClusterRole is just like a Role, but its permissions apply across the entire cluster. It's also used for non-namespaced resources like nodes. Third, a RoleBinding grants the permissions in a Role to a subject (user, group, or ServiceAccount) within that Role's namespace. Finally, a ClusterRoleBinding grants the permissions from a ClusterRole to a subject across the entire cluster.

WHEN TO USE IT: Use a Role when you need to grant permissions confined to a single namespace. This is perfect for an application-specific ServiceAccount, like a deployment pipeline that only needs to manage resources in the production namespace. Use a ClusterRole for permissions that must apply everywhere, like for a monitoring tool that needs to scrape metrics from pods in all namespaces, or for an administrator who needs to manage cluster nodes.

WHEN NOT TO USE IT: Avoid using ClusterRoles when a namespaced Role would suffice. Granting broad, cluster-wide permissions violates the principle of least privilege and increases the blast radius of a compromised account. The biggest footgun is binding a powerful ClusterRole with a namespaced RoleBinding; this grants the permissions only within that one namespace, which is often an unintended and confusing limitation.

ONE CANONICAL EXAMPLE: A common pattern is creating a Role for a "pod-reader" in the default namespace. The Role would specify the pods resource and the get, watch, and list verbs. You would then create a RoleBinding to grant this "pod-reader" Role to a specific user. Now, that user can list and view pods in the default namespace, but cannot access pods in any other namespace or perform actions like deleting them.