Multi-Tenancy

The pattern: multiple isolated tenants share underlying infrastructure. Each tenant has scoped permissions, resource limits, network isolation, and data separation. Kubernetes offers namespace-scoped tenancy (cheap, soft); cluster-per-tenant is hard isolation (expensive, secure); virtual clusters (vCluster) sit in the middle. The choice depends on threat model, not preference.

The trade-off: cost vs. isolation strength. Soft multi-tenancy (shared cluster, namespace-scoped) is cheap but a determined attacker or noisy neighbor can affect others. Hard multi-tenancy (cluster-per-tenant, account-per-tenant) is secure but expensive and operationally heavier. Most platforms run soft tenancy with careful policy and monitoring; high-security workloads (PII, financial, regulated data) demand hard tenancy. The mistake is choosing once and never revisiting as the tenant mix evolves.

Deepens in Year 2 Phase 13 — basecamp tenant overlays + RBAC + NetworkPolicy + ResourceQuota stacked into a coherent isolation contract.

Related patterns

• platform-as-product — tenants are the platform’s users; isolation is part of the contract.
• gitops — tenant overlays in git make scope explicit and reviewable.
• least-privilege — RBAC and IAM are how tenants stay in their lane.
• defense-in-depth — namespace + NetworkPolicy + Pod Security stack because no single layer is enough.
• zero-trust-security — tenant boundaries enforced at every hop, not just the perimeter.
• cardinality-as-cost — per-tenant labels are how you bill, alert, and debug — and how you blow up your TSDB.
• Phase 12: Platform Engineering and basecamp — where multi-tenancy becomes a real platform contract.