Skip to content
Glossary

Role-Based Access Control (RBAC)

A method of restricting system access to authorised users based on their role within an organisation — users are assigned roles, and roles are assigned permissions.

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.

See it in action

Request a demo of AravaliStack and see how these concepts come to life in a production platform.