RBAC Authorization

Authorization as Pairs

RBAC grants permissions through four objects, used in pairs:

• Role (namespace-scoped) or ClusterRole (cluster-scoped) — the rules: which verbs on which resources.
• RoleBinding or ClusterRoleBinding — the subjects that receive those rules.

Subjects are Users, Groups, or ServiceAccounts. Kubernetes stores no User objects — identities come from client certificates, OIDC claims, or tokens.

rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]

A ClusterRole referenced by a RoleBinding is the common trick for granting cluster-wide resource types (like nodes or * non-resource rules) inside one namespace. RBAC is allow-only: there are no deny rules, so restricting further requires admission webhooks.

Building Least Privilege

Start from the smallest working grant and verify each step:

kubectl auth can-i list pods --namespace=prod
kubectl auth can-i create secrets -n prod \
  --as=system:serviceaccount:ci:deployer
kubectl create role deployer --verb=create,update \
  --resource=deployments.apps -n prod --dry-run=client -o yaml
kubectl create rolebinding ci-deployer --role=deployer \
  --serviceaccount=ci:deployer -n prod

Aggregation eases management: a ClusterRole with an aggregationRule selects other ClusterRoles by label (for example rbac.authorization.k8s.io/aggregate-to-admin: "true") and folds their rules in automatically — edit once, every aggregated role grows.

The built-in cluster-admin ClusterRole grants * on everything; never bind it casually to a service account.

Pitfalls and Debugging 403s

Pitfall 1 — wrong binding namespace. A RoleBinding in default does nothing for work in prod. The request is authenticated, authorized against that namespace, and rejected — intermittent 403s on some commands usually mean a missing binding where the action happens.

Pitfall 2 — escalating to "fix" it. Broadening bindings to silence errors hides the gap. Reproduce with kubectl auth can-i --as=..., add one rule, retest, and commit the change through review.

Interview-ready: recite the four objects and the allow-only model, explain why ClusterRole plus RoleBinding scopes cluster-granular resources to one namespace, and describe audits: kubectl auth can-i --list --as=... plus reviewing bindings in Git.