Multi-Tenancy Policy

Multiple teams; one cluster. Policy.

Isolation primitives

Multi-tenant Kubernetes clusters need three isolation primitives layered together. Each one alone is bypassable; together they enforce real boundaries between tenants sharing the cluster.

• Namespaces. Logical separation boundary; same cluster, separate namespace per tenant. The container all other isolation rides in.
• Resource quotas. Per-tenant capacity caps on CPU, memory, pod count, and storage; prevents any tenant from consuming the whole cluster.
• Network policies. Cross-tenant traffic block at the namespace boundary; blocks lateral movement between tenants on a compromised pod.
• IaC source per tenant. Terraform-managed namespace config so tenant onboarding is repeatable and audit trail is automatic.

Trust model

The trust model decides shared-versus-separate cluster. High-trust tenants share; low-trust tenants get their own cluster; mid-trust tenants share with strict policies and active monitoring.

• High-trust shares. Internal teams running known-good workloads; low risk of mutual interference, shared cluster is the right answer.
• Low-trust separates. Customer-running-own-workload cases (PaaS-style); blast radius from a compromised tenant warrants its own cluster.
• Mid-trust shared with strict policies. Most internal multi-tenancy lands here; shared cluster, strict policies, and monitoring catch the edge cases.
• Documented trust level per tenant. Named tier per tenant; "we never decided" defaults to over-shared and unsafe.

Per-cluster policy

Per-cluster policy makes the trust model concrete. Documented model, onboarding script, and quarterly review keep the policy enforced as tenants and workloads change.

• Documented trust model. "Who can deploy here, what isolation is enforced" written down as the source of truth; not folklore.
• Onboarding script per tenant. Namespaces, RBAC, quotas, network policies all created together; manual onboarding produces drift.
• Quarterly review. Tenant list, access audit, policy compliance check; drift surfaces faster on a fixed cadence.
• Named owner per cluster. Maintaining team responsible for changes; "everyone and no one" ownership is how clusters become unmaintainable.

Operating multi-tenant clusters

Operating multi-tenant clusters is a discipline. Noisy-neighbour detection, cost attribution, and annual fit reviews keep the model honest as the tenant mix changes.

• Noisy-neighbour detection. Per-tenant resource-consumption monitor; surfaces tenants whose workload is impacting other tenants on the cluster.
• Cost attribution per tenant. Cost share visible to engineers and finance; teams see their share rather than the aggregate cluster bill.
• Annual fit review. "Should this still be multi-tenant?" question per cluster; some tenants outgrow shared environments and the model has to evolve.
• Tenant-graduation criteria. Documented "when to move tenant to its own cluster" rule; thresholds prevent the strained-shared-cluster pattern.