API authorization model
Kubernetes Role-Based Access Control (RBAC) authorizes an authenticated API request from a user, group, or ServiceAccount. A Role contains allow rules within one namespace. A ClusterRole can describe cluster-scoped resources or be bound in a namespace. A RoleBinding grants a Role or ClusterRole within one namespace. A ClusterRoleBinding grants cluster-wide authority.
RBAC rules name API groups, resources or non-resource URLs, verbs, and sometimes resource names. RBAC has no deny rule. A request succeeds when an active authorizer allows it.
Build least authority
Start from captured API operations. Grant the exact verbs and resource types. Prefer namespace bindings when the resource is namespaced. Treat create, update, patch, delete, deletecollection, watch, impersonate, bind, and escalate as distinct authority.
Review indirect privilege. Reading Secrets can expose credentials. Creating Pods can mount ServiceAccounts, host paths, or privileged settings when admission does not prevent it. Updating workloads can run attacker code under the workload identity. Binding or escalating roles can create new authority.
Failure and residual risk
Wildcards silently include new resources or verbs. Built-in role aggregation can change an aggregated role when matching labels appear. Group bindings can expand through an external directory. An authorization check can be correct while an admission policy still allows a dangerous object configuration.
RBAC protects the Kubernetes API. It does not restrict network traffic between Pods, authorize application records, or validate the software running inside an allowed Pod.
Pomerium boundary
Pomerium can protect access to the Kubernetes API and carry authenticated user context according to the documented integration. Kubernetes remains the API authorizer. Operators own user and group mapping, impersonation controls, RBAC, admission policy, audit, and direct API-server reachability.
Evaluation checklist
- Does each binding name the intended human, group, or ServiceAccount and scope?
- Are wildcards and cluster-wide bindings absent unless a tested requirement needs them?
- Have secret read, workload write, impersonate, bind, escalate, and admission interactions been reviewed?
- Can
kubectl auth can-iand a real negative request prove the expected boundary? - Can no alternate API endpoint bypass the identity-aware access path?
