Kubernetes RBAC is powerful enough to express almost any access policy — which also makes it easy to get wrong. Roles copied between teams, wildcard verbs granted "just to unblock someone," and bindings nobody remembers creating are how a reasonable starting policy turns into an unreviewable mess. A few practices keep it from getting there.
Know the building blocks
A Role (or ClusterRole) defines a set of permissions — which verbs (get, list, create, delete...) are allowed on which resources. A RoleBinding (or ClusterRoleBinding) grants that role to a user, group or service account. Roles are namespace-scoped; ClusterRoles apply cluster-wide or can be bound within a single namespace for reusable role definitions.
Default to least privilege
Grant the specific verbs and resources a role actually needs, not a broad set "in case it's needed later." A role that can get and list Pods is very different from one that can also delete and exec into them — treat those as separate grants, not a bundle.
Prefer namespace-scoped Roles over ClusterRoles
A ClusterRoleBinding gives permissions across every namespace in the cluster — appropriate for cluster administrators, rarely appropriate for an application team. Scoping Roles to the namespace a team actually owns keeps a mistake in one namespace from becoming a cluster-wide incident.
Bind to groups, not individual users
Binding roles directly to individual users means every access change is a direct RBAC edit. Binding to groups — managed through SSO — means access changes when someone joins or leaves a team, without touching the cluster's RBAC objects at all.
Avoid wildcard verbs and resources
verbs: ["*"] or resources: ["*"] is the RBAC equivalent of chmod 777 — it works, and it's exactly what makes an eventual audit unreviewable. Enumerate what's actually needed, even when it's more typing up front.
Audit on a schedule, not just after an incident
Roles and bindings drift as teams and projects change. A periodic review — who can do what, and does that still match who should be able to — catches over-permissioned accounts before they're relevant to an incident, not during one.
Extend RBAC across clusters, and to VMs
Every practice above still matters once there's more than one cluster — see Kubernetes multi-cluster management for the added complexity — and it matters for virtual machines too, which is easy to miss if RBAC policy was only ever designed around containers. AetherVirt applies the same RBAC, with SSO or local authentication, to VM actions as it does to container actions, so "least privilege" doesn't quietly stop at the container boundary.