Namespaces organize tenants; authority comes from policy

Authentication establishes which principal the API server recognizes; authorization decides whether that principal may perform the requested action. Namespace-scoped RoleBindings and cluster-wide ClusterRoleBindings have different scopes, and RBAC permissions are additive. A narrowly intended RoleBinding does not subtract authority already granted through another binding. Inspect the complete effective set, including group membership and service accounts, rather than treating a role’s name as proof of least privilege. Cluster-scoped resources also need their own analysis because putting a workload in a namespace does not make every resource namespaced.

Admission is a separate decision after the relevant authentication and authorization stages. A principal allowed to create pods can potentially cause code to run with a service account available in that namespace, mount accessible secrets, or request dangerous host features unless additional policy constrains those choices. Therefore “cannot read secrets directly” does not settle the indirect authority of a pod creator. Follow the authority of the resulting workload and the controllers that act on its specifications. Record who can change policy, bindings, admission configuration, and the service accounts that privileged automation uses.

A ResourceQuota constrains specified aggregate resource requests, limits, or object counts through admission semantics. It can prevent a tenant from creating another object once the configured budget is exhausted. That does not mean every already running request has a dedicated physical resource reservation, nor that API object counts are a per-second traffic limit. Scheduling, node-level cgroups, storage policies, network enforcement, and application tenant checks remain separate mechanisms. Identify the controller and enforcement point responsible for each promise rather than attaching all promises to the namespace label.

A shared control plane also contains expensive paths: list operations, watches, admission webhooks, custom controllers, and reconciliation work. Namespace separation does not prevent one tenant’s permitted requests from stressing a shared dependency. Bound and observe those paths according to the actual supported mechanisms. Likewise, an allowed network connection is not permission to read every object the target service can reach. The service must retain the tenant’s authenticated authority when acting on its behalf, particularly when it uses a more powerful common storage credential.

Build an identity-action-resource matrix that includes intended allows and intended denials. Test actual operations using isolated fixtures, including creation paths that can indirectly gain authority. Preserve audit evidence and distinguish a denial by the intended policy from a denial caused by a missing object or broken network. Repeat after relevant role, controller, or admission changes. A finite matrix is valuable regression evidence, but it covers only its listed principals, verbs, resources, and configurations; it does not prove every custom resource or future service obeys the same boundary.

For a detection-probability analogy, Reset the probability lab, explicitly set success probability 0.1 and trials ten, predict the probability of at least one success, then Play or Step. Compare a fresh Reset with both settings explicitly restored as 0.1 and 20. Playback tours an exact binomial distribution rather than issuing API requests. Independent trials with known probability are assumptions, not properties of authorization tests. Carefully selected adversarial cases can be more informative than many repetitive random cases, especially when the untested boundary is a privileged creation path.