Member-only story
Kubernetes RBAC Explained: Roles, RoleBindings and Best Practices
Kubernetes Role-Based Access Control (RBAC) determines what actions every entity in your cluster is allowed to take: which users can create deployments, which service accounts can read secrets, which CI/CD pipelines can update images. RBAC is enabled by default in all Kubernetes versions since 1.6 and is the primary access control mechanism for the Kubernetes API.
Most engineers understand RBAC conceptually but get confused when implementing it in practice: what is the difference between a Role and a ClusterRole, when do you use a RoleBinding versus a ClusterRoleBinding, and why do so many tutorials suggest using cluster-admin when that is almost never appropriate? This guide answers all three questions and provides the practical patterns that make RBAC manageable rather than an afterthought.
THE FOUR RBAC CONCEPTS
Kubernetes RBAC has exactly four object types. Subject: who is making the request — a User (human, identified by certificate CN), a Group (set of users), or a ServiceAccount (pod identity). Role: what actions are allowed — a list of verbs (get, list, watch, create, update, patch, delete) on specific API resources (pods, deployments, secrets, configmaps) within a single namespace. ClusterRole: same as Role but applies cluster-wide (across all namespaces) or to…
