Share a cluster between teams that trust each other, with RBAC, quotas and network policies. For tenants that do not trust each other, expect to invest far more in data plane isolation, or give each tenant a dedicated cluster. The Kubernetes docs describe this as a spectrum, not a switch.
Soft and hard tenancy
The multi-tenancy docs say hard multi-tenancy implies strong isolation, often for cases where tenants do not trust each other, guarding against attacks such as data exfiltration or denial of service. Soft multi-tenancy implies weaker isolation. They also say the terms are imprecise, and that hardness is better understood as a broad spectrum with many techniques.
They note that data planes typically have much larger attack surfaces, so hard multi-tenancy often requires extra attention to isolating the data plane, though control plane isolation remains critical.
Three common tenant models
- Multiple teams in one organization. The docs say there is often some trust, but RBAC, quotas and network policies are essential to share the cluster safely and fairly. A tenant is typically a team.
- Multiple customers of a vendor. Customers do not access the cluster, Kubernetes is invisible to them, and policies must keep workloads strongly isolated. A tenant is a group of users sharing a workload.
- Hybrid. For example, per-customer workloads for sensitive data combined with shared services.
Decision guide
Ask these questions in order:
- Do tenants run code you did not review? If yes, treat them as untrusted.
- Can a tenant's compromise justify a customer incident? If yes, favor dedicated clusters.
- Do tenants need cluster-scoped objects such as custom resource definitions? Namespaces cannot isolate those.
- Can you afford the operations load of many clusters? If not, invest in namespaces plus strong policy.
The docs also state that it may be easier or necessary to forgo cluster-level sharing and assign each tenant a dedicated cluster, possibly on dedicated hardware if virtual machines are not considered an adequate security boundary.
What namespaces give you
A Namespace isolates groups of API resources. Names can overlap between namespaces, and many security policies, such as RBAC Roles and Network Policies, are namespace-scoped. The docs recommend isolating each workload in its own namespace, even within one tenant, so each has its own identity.
That is control plane isolation. It does not by itself isolate nodes, kernels or networks. For the full picture, see are Kubernetes namespaces a security boundary.
Minimum controls for the shared option
- Namespace per workload and per tenant, with RoleBindings, not cluster-wide ones.
- A default deny network policy in each namespace.
- Resource quotas, including object counts.
- Pod Security labels at Baseline or Restricted.
Our posts cover each of those, including default deny network policy.
Safeguard does not isolate tenants. Asset discovery and SBOM and dependency scanning help you see what each tenant runs.
Click through it at your own pace, or open it full screen.
Quick check
Is one namespace per customer enough for hostile customers?
The docs treat hard tenancy as needing extra data plane isolation, and sometimes dedicated clusters. Namespaces alone are rarely the whole answer.
Sources
Last reviewed: 19 October 2026.
