Read the standard material on Kubernetes multi-tenancy and you will find a familiar set of controls: namespaces, resource quotas, network policies, RBAC, maybe a service mesh. All of it assumes one organisation dividing its own infrastructure between its own teams.
That assumption is doing more work than it appears. It means a single risk appetite, one compliance boundary, and a shared authority that can settle disputes. Take it away and the technical controls stay the same while the decisions around them change completely.
The first question is no longer technical
In a single-organisation estate you ask what level of isolation you need. Across independently regulated tenants you ask a different question first: who is accountable when this control fails, and to whom?
That is not pedantry. It determines whether a shared control plane is acceptable at all, whether one tenant incident can be investigated using data from another, and whether an engineer with production access to tenant A may hold it for tenant B. None of those are answered by a network policy.
Shared by default becomes separate by default
The economics of a single-organisation platform push towards sharing: fewer clusters, better bin packing, less to operate. When tenants answer to different regulators, the default inverts, because the cost of proving separation after the fact is far higher than the cost of not sharing in the first place.
You are not designing for the failure. You are designing for the conversation about the failure.
This is the point most technical writing on the subject misses. A namespace boundary with strict policy may genuinely be secure. It is still a harder thing to evidence to an auditor than a separate account with no path between them, and the evidencing is a recurring cost you pay every year.
What we ended up standardising
Across an estate that eventually ran more than a hundred clusters, the pattern that held was this. Standardise the machinery aggressively, and let the placement decisions differ.
- One way to build a cluster, expressed as code, used by every tenant regardless of regime.
- One delivery mechanism, so the path from commit to running workload looked identical everywhere.
- Tenant-specific placement, network segmentation and policy attachment, carried by the provisioning layer rather than by the person requesting.
- Separate identity boundaries, so access to one tenant granted nothing anywhere else.
The developer asking for a service did not need to know which regime applied. The composition knew, and produced different placement and different policy depending on where the request came from.
The observability problem this creates
Separation is straightforward until you need to operate the estate. An on-call engineer looking at a cross-tenant incident needs a view across the whole thing, and that view is exactly what the separation is designed to prevent.
The resolution is federation rather than centralisation: telemetry stays within its tenant boundary, and a query layer above it reads across without moving the underlying data into one place. It is more work than a single shared monitoring stack, and it is the difference between an architecture that survives review and one that does not.
What we would tell someone starting
Decide the isolation boundary with whoever owns the compliance risk in the room, before you write any of it down as code. The technical implementation of either answer is straightforward. Changing the answer after two years of accumulated workloads is not.
And write down why you chose it. In three years someone will propose consolidating for cost reasons, and the reasoning behind the original boundary is the only thing that will make that a real conversation rather than a guess.
