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.