Kubernetes can support multiple teams or customers in one cluster, but it does not provide a built-in tenant boundary. Safe sharing depends on matching the isolation model to how much tenants trust one another, then combining access controls, resource limits, network policy, and workload protections. Namespaces are a useful starting point—not a complete answer, especially for mutually untrusted customers.
What Kubernetes multi-tenancy means
A tenant might be an internal engineering team, a customer group using a shared application, or a customer running workloads without direct access to Kubernetes. Those arrangements have different trust and access requirements. Kubernetes describes the distinction plainly: “While Kubernetes does not have first-class concepts of end users or tenants, it provides you several features that allow you to configure your cluster in order to support multi-tenancy.” (Kubernetes documentation: Multi-tenancy)
As an Amazon Associate I earn from qualifying purchases.
Design for two boundaries, not just one:
- Control plane: who can view or change Kubernetes API resources, and which resources are in scope for that access.
- Data plane: how workloads share worker-node capacity, storage, and network connectivity.
A policy that limits API access does not by itself separate workload traffic or prevent resource contention. Conversely, isolated network paths do not prevent an over-privileged user from changing cluster configuration.
Are namespaces enough?
Namespaces group namespaced objects and provide a scope for controls such as Roles, NetworkPolicies, and ResourceQuotas. They are resource-efficient and often work well for trusted internal teams when platform administrators configure and maintain the surrounding policies. They are not a complete security boundary: some Kubernetes resources are cluster-scoped, and namespace separation alone does not isolate every API object or workload interaction. (Kubernetes multi-tenancy guidance)
#1 Best Overall
So, a namespace per team or tenant is a useful organizational starting point, not a declaration that the tenant is isolated. If customers are mutually untrusted, tenants can access the Kubernetes API, or the workload handles sensitive data, evaluate whether policy-based sharing meets the actual risk requirement. A namespace-per-workload arrangement can also be useful when distinct identities and policies are needed within one tenant.
Choose an isolation model
The main options trade isolation scope for infrastructure sharing and operational effort. The Kubernetes guidance presents these as patterns with tradeoffs, not as a universal ranking. (Kubernetes multi-tenancy guidance)
| Model | What it separates | Advantages | Costs and limits | Consider it when |
|---|---|---|---|---|
| Namespaces per tenant or workload | Namespaced API objects and the policies scoped to them | Low resource overhead; native Kubernetes controls; can support shared services | Requires correct RBAC, quotas, network policies, and ongoing policy management. Cluster-scoped resources remain shared. | Tenants have an acceptable trust relationship and policy-based isolation meets the requirement. |
| Virtual control plane per tenant | More of each tenant’s Kubernetes API and control-plane view, including concerns involving otherwise cluster-wide API state | Stronger control-plane separation while sharing worker infrastructure | More resources and operational complexity; cross-tenant sharing is harder. Workload-level data-plane protections are still needed. | Namespace isolation is insufficient, but separate full clusters are not desirable. |
| Dedicated cluster per tenant | Control plane and worker infrastructure are separated by cluster boundary | Greater separation and independent cluster administration | Higher cost and operational overhead, with less resource sharing | Requirements or risk tolerance justify the additional isolation and management burden. |
Make the choice against concrete requirements: tenant trust, whether tenants use the Kubernetes API directly, data sensitivity, required service sharing, treatment of cluster-scoped resources, and the cost and complexity the platform team can operate. A hybrid arrangement is possible: keep lower-risk workloads on shared infrastructure and give sensitive tenants stronger isolation. Provider guidance, such as AWS guidance for tenant isolation on Amazon EKS and Google Cloud’s cluster multi-tenancy overview, is implementation context for those services, not a guarantee that every Kubernetes distribution behaves identically.
Layer the controls for a shared cluster
For namespace-based sharing, use several controls together. A practical setup sequence is:
Rank #3
- Map tenants to namespaces. Choose one or more namespaces for each tenant or workload, and use a consistent naming scheme across clusters where that helps administration. Keep cluster-wide objects and permissions under trusted platform administration.
- Grant least-privilege access with RBAC. Limit each user or service account to the namespaces and resource actions it needs. Review broad permissions carefully: cluster-wide access can let a tenant alter or disable protections intended to protect other tenants. See the Kubernetes blog’s overview of three tenancy models.
- Set ResourceQuotas. Use namespace quotas to constrain resource consumption and selected object counts, reducing the risk that a tenant monopolizes shared capacity or the API. Workloads may need resource requests and limits that satisfy the quota configuration. Protect quota policy from tenant modification if tenants can access the API. Kubernetes documents ResourceQuota as stable since Kubernetes v1.24; that feature-state note does not mean every provider or cluster configuration is identical. (Kubernetes Resource Quotas)
- Define network policy deliberately. Kubernetes permits pod communication by default. For strict separation, begin with a default-deny policy and add only necessary flows, including DNS where required. Confirm that the installed CNI plugin supports and enforces NetworkPolicy; otherwise the policy objects are ignored. Quotas and network policies address different risks: quotas do not prevent every noisy-neighbor effect, including network contention. (Kubernetes multi-tenancy guidance)
- Harden workloads and admission. Apply workload hardening and admission controls appropriate to the threat model. Kubernetes’ tenancy-model guidance recommends Restricted Pod Security Standards as a default starting point, with exceptions only when justified. (Kubernetes tenancy-model guidance)
- Review shared dependencies. Account for cluster-scoped objects, shared services, storage, and worker-node exposure. Namespace policies do not automatically segregate those concerns.
- Reassess when trust changes. A setup suitable for internal teams may be inadequate if tenants become mutually untrusted, gain more direct API access, or handle more sensitive workloads. Move to a stronger boundary where the risk requires it.
What each control does—and does not—solve
- RBAC limits API actions, but overly broad permissions can undermine other protections.
- ResourceQuotas constrain specified namespace consumption and object counts; they do not eliminate all forms of contention.
- NetworkPolicies can restrict pod traffic only when the cluster’s CNI implements them, and permitted flows still need deliberate design.
- Namespaces scope namespaced resources and policies, but do not isolate every cluster-wide resource.
- Virtual or dedicated clusters strengthen parts of the boundary, but do not remove the need to consider workload communication, shared services, storage, and operational access.
The practical test is not whether a cluster has namespaces, but whether the complete set of API, resource, and workload controls matches the tenants’ trust relationship and the consequences of a boundary failure.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
