Explain Kubernetes RBAC: Role vs ClusterRole, and how bindings work.
Quick Answer
RBAC grants permissions via Roles (a set of allowed verbs on resources). A Role is namespace-scoped; a ClusterRole is cluster-wide. Bindings attach a Role/ClusterRole to a subject (user, group, or ServiceAccount) — RoleBinding in a namespace, ClusterRoleBinding cluster-wide.
Detailed Answer
RBAC is additive and deny-by-default: subjects have no access until a binding grants it. A Role lists rules — verbs (get, list, create, delete...) on resources (pods, secrets...) — scoped to one namespace. A ClusterRole is the same but cluster-scoped, and is also used for cluster-scoped resources (nodes) or to define a reusable permission set. Bindings connect roles to subjects: a RoleBinding grants a Role (or a ClusterRole) within a single namespace; a ClusterRoleBinding grants a ClusterRole across all namespaces. A common pattern is a ClusterRole (e.g., 'view') reused via RoleBindings in many namespaces so the same permission set applies per-namespace. Least privilege is the goal: prefer narrow Roles + RoleBindings, avoid cluster-admin, and audit who can read Secrets or exec into pods.
Code Example
kubectl create role pod-reader --verb=get,list,watch --resource=pods -n team-a kubectl create rolebinding alice-reader --role=pod-reader --user=alice -n team-a kubectl auth can-i list pods -n team-a --as=alice # verify
Interview Tip
Grid it out: Role=namespaced, ClusterRole=cluster-wide; RoleBinding=namespaced grant, ClusterRoleBinding=cluster-wide grant. Then say 'RBAC is deny-by-default and additive' and mention `kubectl auth can-i` to test it.