Luca BertonThe Multi-Tenancy Challenge
Regulated enterprises need multiple teams, environments, and potentially customers sharing Kubernetes infrastructure — but with strict isolation guarantees. A developer in Team A shouldn't access Team B's pods, secrets, or network. A staging workload shouldn't impact production performance. Customer data must be segregated for GDPR compliance.
Kubernetes was not designed for multi-tenancy by default. Building secure multi-tenancy requires layering multiple isolation mechanisms.
Multi-Tenancy Models
Soft Multi-Tenancy (Namespace-Based)
Tenants share a cluster, isolated by namespaces:
- RBAC: Users can only access resources in their namespace
- Network policies: Default deny between namespaces; explicit allow for permitted communication
- Resource quotas: CPU, memory, and storage limits per namespace
- Limit ranges: Default and maximum resource requests per pod/container
- Pod security: Pod Security Standards (restricted) enforced per namespace
Best for: Internal teams sharing development and staging clusters. Acceptable for production with strong policy enforcement.
Hard Multi-Tenancy (Virtual Clusters)
Each tenant gets a virtual Kubernetes cluster within a host cluster:
- vCluster: Creates lightweight virtual clusters with their own API server, controller manager, and etcd (or SQLite)
- Complete isolation: Each tenant has their own Kubernetes API — they can create CRDs, cluster roles, and namespaces without affecting others
- Resource efficiency: Virtual clusters share the host cluster's worker nodes — more efficient than separate physical clusters
- Security boundary: Stronger isolation than namespaces — closer to separate clusters
Best for: Multi-customer SaaS platforms, highly regulated environments where namespace isolation isn't sufficient, and CI/CD ephemeral environments.
Essential Isolation Controls
| Control | What It Does | Compliance Relevance |
|---|---|---|
| RBAC | Controls who can do what in which namespace | NIS2 Art. 21(2)(i) — access control |
| Network Policies | Controls pod-to-pod network communication | NIS2 Art. 21(2)(j) — network segmentation |
| Resource Quotas | Limits total resources per namespace | DORA — prevent noisy-neighbour DoS |
| Pod Security | Restricts container privileges | NIS2 Art. 21(2)(e) — secure development |
| Encryption | etcd encryption at rest, mTLS in transit | GDPR Art. 32, NIS2 Art. 21(2)(h) |
Kubernetes Recipes
Practical guide for container orchestration and deployment — hands-on patterns you can use today.
View on Amazon →Multi-Tenancy Frameworks
- Capsule: Multi-tenancy for namespace-based isolation — groups namespaces into "tenants" with shared policies, quotas, and network rules
- vCluster: Virtual clusters for hard isolation — each tenant gets a full Kubernetes API
- Hierarchical Namespaces (HNC): Kubernetes SIG project for parent-child namespace inheritance
- Loft: Commercial platform for vCluster management with self-service portal
Implementation Guide
- Define your tenancy model — Who are your tenants? (Teams, environments, customers?) What isolation level do they need?
- Implement namespace-level controls first — RBAC, NetworkPolicy (deny-all default), ResourceQuota, LimitRange
- Add policy enforcement — Kyverno or OPA Gatekeeper for admission control
- Consider virtual clusters for tenants needing stronger isolation or Kubernetes API access
- Document and audit — Map each isolation control to your regulatory requirements for audit evidence
API Validation with Postman
Master API validation and testing using Postman. In collaboration with Starweaver.
Start on Coursera →