RBAC

Role-Based Access Control (RBAC) is how Kubernetes decides what an authenticated identity may do. You grant permissions through Roles (sets of allowed verbs on resources) and bindings that attach those roles to users, groups, or ServiceAccounts. It is the primary authorization mechanism, and the one you will configure most.

RBAC is additive and deny-by-default: nothing is allowed until a binding grants it. The discipline it demands — and the one most often skipped — is least privilege, because the easy path of broad grants quietly undoes the whole point.

Roles and ClusterRoles

A Role is a namespaced set of rules: these verbs (get, list, create, delete…) on these resources (pods, configmaps…), in one namespace. A ClusterRole is the same idea but cluster-wide, and is also used for cluster-scoped resources (nodes, PVs) and for permissions you want to reuse across namespaces.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: shop
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]

Bindings

A role grants nothing until it is bound. A RoleBinding attaches a Role (or a ClusterRole) to subjects within one namespace; a ClusterRoleBinding attaches a ClusterRole cluster-wide. Subjects are users, groups, or ServiceAccounts. A common and useful pattern is binding a ClusterRole into a single namespace with a RoleBinding, reusing the permission definition while scoping where it applies.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: shop
  name: read-pods
subjects:
  - kind: ServiceAccount
    name: viewer
    namespace: shop
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Least Privilege in Practice

RBAC's value is entirely in the discipline of granting only what is needed. The anti-patterns are well worn: binding cluster-admin because it is easy, using verbs: ["*"] or resources: ["*"], and binding to the system:authenticated group (which is everyone). Particularly dangerous are the escalate, bind, and impersonate verbs and write access to RBAC objects themselves — they let a subject grant itself more. Audit these specifically.

Auditing and Aggregation

Over time RBAC sprawls. kubectl auth can-i checks whether a subject can perform an action, which is invaluable for verifying intent. Aggregated ClusterRoles let you compose roles from labeled rule sets, useful for extending the built-in roles cleanly. The built-in view, edit, and admin ClusterRoles are good starting points — prefer binding and composing them over hand-writing broad rules.