Nine teams, one cluster, and tenant boundaries that are enforced rather than agreed
Kubernetes — multi-tenancy & policy
Where they started
All teams shared one cluster. Isolation was a README, resource limits were advisory, and a single runaway job had previously starved production for forty minutes.
The problem, precisely
Splitting into per-team clusters was not affordable, but "please be careful" was not an isolation model a regulator would accept.
What we did
Implemented hard boundaries at four layers — admission, network, resources and identity — and made every boundary produce evidence rather than rely on trust.
Delivered
- Policy library: no privileged pods, no hostPath, mandatory resource limits, registry allow-list
- Default-deny network policy per namespace with explicit egress allow-lists
- Fair-share quotas and priority classes so one team cannot starve another
- Per-team RBAC bound to the identity provider, with no shared admin kubeconfig
- Policy violations exported as evidence, not just blocked
Technologies used
Measured result
Every number below was measured and reported to the customer. Where we do not have a measured figure, the entry is a fact rather than a percentage — we would rather be precise than impressive.
- 4 enforcement layers, all producing audit evidence
- 0 shared admin credentials after migration
- 100% of namespaces with default-deny network policy
- 1 noisy-neighbour incident since, contained by quota
Tenant isolation is four separate problems wearing one name: admission, network, resources, identity. Solving three of them is how you get an incident.