Multi-Tenant Cluster Patterns

Multiple teams on one cluster. The patterns.

Namespace per tenant

Multi-tenant cluster pattern is the discipline of running multiple teams or applications on a shared cluster while preventing them from affecting each other. The pattern uses namespaces, RBAC, and network policies to provide isolation; the discipline is consistent across the cluster.

What namespace-per-tenant provides:

• Hard separation.: Each tenant has their own namespace. Resources are isolated; one tenant's resources do not interfere with another's; the boundary is the namespace.
• Resource quotas per ns.: Each namespace has its ResourceQuota. The tenant's resource consumption is bounded; runaway in one tenant does not starve others; the discipline is enforced.
• Most common pattern.: Namespace-per-tenant is the default multi-tenancy approach. Most production multi-tenant clusters use it; the pattern is well-understood; the operational story is established.
• Hierarchy.: Some teams use namespace hierarchies (parent namespaces with child namespaces). The structure matches the team's organization; the discipline scales.
• vCluster for stronger isolation.: Beyond standard namespaces, virtual clusters (vCluster) provide near-cluster-level isolation per tenant. The pattern is heavier but produces stronger boundaries.

Namespace-per-tenant is the foundation. The discipline is consistent application across all tenants.

RBAC scoped

RBAC controls who can do what within each tenant's namespace. Properly scoped RBAC prevents tenants from affecting other tenants' resources; cross-tenant access requires explicit permission.

• Each tenant has Roles bound in their ns.: Each tenant's users get RoleBindings in their namespace. The Roles grant the necessary permissions within the namespace; nothing outside.
• Cross-tenant access requires explicit permission.: If a tenant needs access to another's resources, the access is explicit. ClusterRoleBindings, namespace-spanning RoleBindings, or shared service accounts all are options; the access is documented.
• Avoid ClusterRoleBindings.: Per-tenant ClusterRoleBindings break the isolation. The team's discipline minimizes them; specific cluster-level needs are accommodated; the default is namespace-scoped.
• Audit cross-tenant access.: The team audits cross-tenant access periodically. Why does this tenant access that tenant? Is it still appropriate? The discipline maintains the boundaries.
• Document the model.: The team's RBAC model is documented. New tenants understand the pattern; existing tenants follow it; the consistency supports operational clarity.

RBAC scoping is what enforces isolation at the API layer. Without it, the namespace boundary is theoretical.

Network policies

Network policies enforce isolation at the network layer. Default-deny prevents tenants from reaching other tenants' pods; explicit allows are documented.

• Default-deny.: The cluster's default network policy denies all pod-to-pod traffic. Tenants cannot reach each other's pods unless explicit allow policies exist; the isolation is structural.
• Tenant ingress/egress limited.: Each tenant has policies allowing their internal traffic. External traffic to/from the tenant is controlled; cross-tenant traffic requires explicit policies.
• Lateral movement bounded.: When a pod is compromised, the attacker's lateral movement is bounded by policies. The blast radius is the tenant's namespace; not the entire cluster.
• CNI must support network policies.: Some CNIs do not enforce network policies. Calico, Cilium, others all do; the team's CNI choice must support the discipline.
• Test the policies.: The team tests network policies. Verify cross-tenant traffic is blocked; verify legitimate intra-tenant traffic flows; the discipline is verified.

Multi-tenant cluster pattern is one of those Kubernetes operational disciplines that produces real isolation when implemented correctly. Nova AI Ops integrates with cluster multi-tenancy telemetry, surfaces patterns, and supports the team's tenant isolation discipline.