Namespace Tenancy
Isolating teams within a shared cluster by namespace plus quota plus network policy, and being explicit about what that does not isolate.
Namespace tenancy is the standard arrangement and it is adequate for most internal use: each team gets a namespace with a resource quota, a default-deny network policy, its own service accounts and its own secrets.
What it does not provide is a hard security boundary. Tenants share a kernel, a node, a control plane and a set of cluster-scoped resources. A container escape, a node-level resource exhaustion or an abusive admission webhook crosses the namespace boundary. For mutually trusting internal teams that is an acceptable risk; for genuinely hostile multi-tenancy it is not, and the answer is separate clusters or a sandboxed runtime rather than more policy.
The subtler failure is noisy neighbours. Quotas bound CPU and memory but not disk I/O, network bandwidth, or the API server request rate — and a team running a tight reconciliation loop can degrade the control plane for everyone. Priority classes, pod disruption budgets and API rate limits are the missing controls, and they are usually added after the first incident rather than before.