Multi-tenancy models — soft vs hard, namespaces vs clusters

Multi-tenancy in Kubernetes comes in two models: soft (namespaces) and hard (separate clusters). This lesson walks the models, the trade-offs, and the operational discipline.

The two models

flowchart LR
    A[Soft multi-tenancy] --> B[Namespaces within a cluster]
    C[Hard multi-tenancy] --> D[Separate clusters]

The two models:

• Soft multi-tenancy. Tenants share a cluster and a control plane; isolation is via namespaces with RBAC, NetworkPolicy, ResourceQuota, PSS.
• Hard multi-tenancy. Each tenant has a separate cluster with its own control plane; isolation is physical.

Soft multi-tenancy

flowchart LR
    A[Cluster] --> B["Namespace: tenant-a"]
    A --> C["Namespace: tenant-b"]
    A --> D["Namespace: tenant-c"]
    B --> E["RBAC: tenant-a"]
    B --> F["NetworkPolicy: deny-all + allow"]
    B --> G["ResourceQuota: bounded"]
    B --> H["PSS: restricted"]

Soft multi-tenancy components:

• Namespaces. Each tenant has a namespace.
• RBAC. Roles and RoleBindings scoped to the namespace.
• NetworkPolicy. Default-deny with explicit ingress/egress allowances.
• ResourceQuota. Bounded CPU, memory, object counts.
• PSS (Pod Security Standards). Restricted by default.

These policies together provide strong isolation within a single cluster. The cost is moderate; the benefit is shared control plane and shared capacity.

Hard multi-tenancy

flowchart LR
    A[Tenant A cluster] --> B[Control plane A]
    C[Tenant B cluster] --> D[Control plane B]
    E[Tenant C cluster] --> F[Control plane C]

Hard multi-tenancy components:

• Separate clusters. Each tenant has its own cluster.
• Separate control planes. No shared etcd, no shared API server.
• Separate node pools. No shared nodes.

The isolation is physical: a tenant cannot break out because there is no shared infrastructure. The cost is high (each cluster has its own control plane).

The trade-offs

flowchart LR
    A[Soft] --> B["+ Moderate isolation (with policies)"]
    A --> C[+ Shared capacity]
    A --> D[+ Low operational cost]
    A --> E["- Tenant can break out (in principle)"]
    F[Hard] --> G["+ Strong isolation (physical)"]
    F --> H[+ No shared infrastructure]
    F --> I["- High cost (control plane per tenant)"]
    F --> J["- Operational complexity (multiple clusters)"]

The trade-offs:

Soft:

• Pros: Moderate isolation with proper policies; shared capacity; low operational cost.
• Cons: A tenant can potentially break out (e.g., via privileged container if PSS is misconfigured).

Hard:

• Pros: Strong physical isolation; no shared infrastructure.
• Cons: High cost (each cluster needs its own control plane); operational complexity (multiple clusters).

When to use each

The decision framework

flowchart TD
    A[Choose model] --> B{Trust level}
    B -->|Trusted tenants| C["Soft: namespaces with policies"]
    B -->|Untrusted tenants| D["Hard: separate clusters"]
    C --> E{Compliance}
    E -->|PCI, HIPAA, FedRAMP| F["Evaluate: hard may be required"]
    F -->|Hard required| D
    F -->|Soft acceptable| C

The framework:

1. Assess trust level (trusted internal teams vs untrusted external).
2. Assess compliance (PCI/HIPAA/FedRAMP may require hard).
3. Assess cost (hard is more expensive).
4. Choose the model that matches.

Quiz

The operational discipline

Multi-tenancy model choice in production rests on five non-negotiable elements:

• Choose based on driver. Trust level and compliance drive the model.
• Document the model. The architecture diagram shows the model.
• Apply policies consistently. Soft multi-tenancy requires every policy to be correctly configured.
• Audit policies. Periodic review of RBAC, NetworkPolicy, ResourceQuota, PSS.
• Test isolation. Quarterly test: can a tenant access another tenant’s resources?

Multi-tenancy is a model, not a checkbox. The discipline is to choose deliberately and to enforce the model’s policies consistently.