Four object types and one rule: permissions are **purely additive**, there is no deny. If someone can do something they should not, you remove a binding — you cannot add a rule to stop them.
RBAC answers the authorization question — the second gate in the API server, after authentication has established who you are.
request ──→ ① AUTHN "you are alice@example.com"
│
↓
② AUTHZ "may alice CREATE PODS in namespace prod?" ← RBAC
│ checks every Role bound to her.
│ ANY rule that allows it → allowed.
│ No rule allows it → 403.
↓
③ ADMISSION → ④ VALIDATION → etcd
Four objects, and the only real complexity is the two-by-two grid.
Object
Defines
Scope
Role
What may be done
One namespace
ClusterRole
What may be done
Cluster-wide, or cluster-scoped resources
RoleBinding
Who gets a role
One namespace
ClusterRoleBinding
Who gets a role
Cluster-wide
Role (namespaced) ClusterRole (cluster-wide)
───────────────── ──────────────────────────
RoleBinding permissions in permissions in THAT ONE
(namespaced) that namespace namespace only
← the useful combination
ClusterRole ✘ not allowed permissions in EVERY
Binding (cannot widen a namespace, plus cluster-
(cluster-wide) namespaced Role) scoped resources
← the dangerous one
What is the difference between a Role and a ClusterRole, and when do you combine them?
Role is namespaced; ClusterRole is cluster-wide. The binding determines the effective scope, which is where the useful combination lives.
Role kind
Binding kind
Effective scope
Role
RoleBinding
That one namespace
ClusterRole
RoleBinding
That one namespace — the pattern you want
ClusterRole
ClusterRoleBinding
Every namespace, plus cluster-scoped resources
Role
ClusterRoleBinding
Impossible
Use a ClusterRole with a RoleBinding to define a permission set once and grant it per namespace — that is how the built-in view, edit and admin roles are meant to be used.
You need a ClusterRole with a ClusterRoleBinding for genuinely cluster-scoped resources: nodes, PersistentVolumes, namespaces, CustomResourceDefinitions. Those have no namespace, so a RoleBinding cannot express permission over them.
How would you debug a 403 Forbidden from a pod's application?
The pod acts as its ServiceAccount, so reproduce it as that identity rather than as yourself — that is the whole trick.
# 1. Which ServiceAccount is it actually using?
kubectl get pod <pod> -n prod -o jsonpath='{.spec.serviceAccountName}{"\n"}'
# 2. Ask the API server directly, as that identity
kubectl auth can-i list configmaps \
--as=system:serviceaccount:prod:my-app -n prod
# 3. Everything it CAN do — usually the fastest way to spot the gap
kubectl auth can-i --list --as=system:serviceaccount:prod:my-app -n prod
# 4. Which bindings actually reference it?
kubectl get rolebindings,clusterrolebindings -A -o json | jq -r '
.items[] | select(.subjects[]?.name=="my-app") | .metadata.name'
Read the 403 message itself — Kubernetes names the verb, resource, API group and namespace it wanted. That usually identifies the missing rule immediately.
Common causes, in order: wrong namespace in the RoleBinding; a missing subresource like pods/log; get granted without list; the pod using default because serviceAccountName was never set.
There is no "deny" rule in RBAC. What are the consequences?
RBAC is purely additive: the API server evaluates every rule bound to the subject, and allows the request if any rule permits it. There is no way to subtract.
Four practical consequences:
To remove access you remove a binding, not add a rule. So you must be able to find every binding that grants it — which is why broad ClusterRoleBindings are dangerous: they are easy to add and hard to audit.
A wildcard is unrecoverable except by deletion.verbs: ["*"] on resources: ["*"] cannot be narrowed by a second rule.
Auditing means enumerating, so kubectl auth can-i --list --as=... is the only reliable answer to "what can this identity do?" Reading individual Roles will mislead you.
For real deny semantics you need admission control — a validating webhook, OPA Gatekeeper or Kyverno — because that stage can reject. RBAC answers "may you", admission answers "should this specific object be allowed".