multi-tenancy

Multi-Tenancy

A namespace is an organizational boundary in the Kubernetes API, not a security or resource boundary by itself. Left alone, tenants in different namespaces on the same cluster can still see each other's Services via DNS, exhaust shared node capacity, and — depending on RBAC — read each other's resources entirely. Multi-tenancy is the work of turning that organizational boundary into an actual isolation boundary, one control at a time.

Decide up front how much isolation each tenant actually needs, because that decision changes everything downstream — quotas, network policy, and whether namespaces are even enough. Namespaces are the unit of ownership; isolation has to be built on top of them deliberately.

1. Decide soft or hard multi-tenancy before you provision anything

Soft multi-tenancy assumes tenants are mutually trusted (different teams in the same org) and namespaces plus quotas/RBAC are sufficient. Hard multi-tenancy assumes tenants are mutually untrusted (external customers, regulated separation requirements) and needs isolation namespaces can't provide alone — separate node pools, or separate clusters entirely, because a shared kernel and shared control plane are themselves an attack surface between untrusted tenants.

• Soft tenancy: namespace-per-tenant + ResourceQuota + RBAC + NetworkPolicy is a legitimate, well-trodden pattern.
• Hard tenancy: needs kernel-level isolation (dedicated nodes via taints/tolerations, or gVisor /Kata sandboxing) at minimum, and often separate clusters — the blast radius of a container escape or control-plane compromise has to stop at the tenant boundary.
• This decision drives cost directly — hard tenancy's dedicated infrastructure is real spend; see cost-optimization for that tradeoff once the isolation requirement is fixed.

Done when: the tenancy model is written down as a decision (soft or hard) with the trust assumption that justifies it, not left implicit.

2. Give every tenant a ResourceQuota before their first workload