Role-Based Access Control (RBAC) is an access control model in which permissions to perform operations (read, write, execute, delete) on resources (files, APIs, databases, cluster namespaces) are assigned to roles rather than directly to individual users. Users are then assigned to roles, and inherit the permissions of those roles. This intermediate layer — the role — makes permission management tractable at enterprise scale.
RBAC vs. other access control models
Discretionary Access Control (DAC): Resource owners control access to their resources individually. Flexible but difficult to audit and enforce at scale (Unix file permissions are DAC).
Mandatory Access Control (MAC): Access decisions are made by a central authority based on security labels. Used in highly classified environments (government, defence). Inflexible for commercial enterprise use.
Attribute-Based Access Control (ABAC): Access decisions consider multiple attributes — user attributes, resource attributes, environment conditions (time of day, location). More expressive than RBAC but more complex to manage.
RBAC is the dominant model in enterprise software because it maps naturally to organisational structures and is auditable: you can enumerate who has access to what by listing role assignments.
Kubernetes RBAC
Kubernetes has a built-in RBAC system that controls access to the Kubernetes API — which in turn controls everything in the cluster. Subjects (users, service accounts) are bound to ClusterRoles or namespace-scoped Roles via RoleBindings. Every API call is checked against the RBAC policy. In a multi-tenant platform, namespace-scoped RBAC ensures that a user in Tenant A's namespace cannot perform operations in Tenant B's namespace.
RBAC and the principle of least privilege
RBAC enables least-privilege access — giving each user and service exactly the permissions they need, and no more. This is a core principle of zero trust: if a credential is compromised, the blast radius is limited to the permissions of the compromised role. A developer credential that cannot delete production databases limits the impact of a supply chain attack or phishing incident.
