Kubernetes RBAC in 2026: Roles, Bindings and Least Privilege That Actually Holds

TL;DR: Kubernetes RBAC fails in practice not because the model is weak but because grants accrete: a wildcard here, a cluster-admin binding there, a "temporary" service account that becomes permanent. The model itself is simple — subjects get verbs on resources in a scope, grants are additive only, and nothing is denied, only not granted. Least privilege that holds means: one service account per workload with token automount off by default, namespace-scoped Roles as the default unit, groups (not individuals) as human subjects, secrets treated as the crown jewels they are, and a regular audit of who can do what — verified with kubectl auth can-i , not assumed.

Originally published on DevOps Enginer .

Why RBAC is where cluster security is won or lost

The security-basics guide in this series covered the checklist; this guide goes deep on the one control that decides what a compromised credential can actually do.…