How Kubernetes Multi-Tenancy Works Without Sacrificing Security

Picture this. Your platform team just spun up a shiny new Kubernetes cluster, and within a week, five different teams want a slice of it. Marketing wants their analytics dashboard running. The payments team wants their service deployed. The data science group wants GPU access for training jobs. Everyone is asking the same question, can we all just share one cluster?

The straightforward answer is yes, but this is true only when isolation is properly implemented. Sharing infrastructure is one of the oldest tricks in the cost-cutting book, and Kubernetes makes this procedure quite appealing because one cluster can indeed deal with dozens of teams, and nobody would notice that. The issue with this approach is that “it is technically feasible” and “it is possible to carry it out safely” are two different stories. In this post, we will explain the principle of multi-tenant Kubernetes and tell you about the tools you can use to create isolation and explain the situations when it is no longer reasonable to use the cluster.

Why teams share clusters in the first place

Maintenance of Kubernetes clusters isn’t economical. The main issue causing operational expenses are the costs associated with control planes and nodes sitting and waiting; monitoring and logging systems; and the responsibility of a person or a team to keep everything functioning normally. When you multiply these expenses times the number of companies that want their cluster, it’s easy to see how costs can accumulate fast.

This is why companies prefer to use one cluster for a few teams’ working processes. The main advantage of this model is lower infrastructure expenses and fewer responsibilities for the platform development teams that are not required to monitor several clusters anymore.

Namespaces are the starting point, not the whole solution

Most people’s first encounter with multi-tenancy in Kubernetes is the namespace. It feels like isolation. You create a namespace for each team, deploy their workloads inside it, and it looks tidy on paper.

But a namespace by itself is just a naming boundary. It groups resources together and lets you apply policies against that group, but it does not enforce anything on its own. Without additional controls layered on top, a pod in one namespace can still talk to a pod in another namespace over the network. A user with cluster wide permissions can still read secrets across every namespace. A workload with no resource limits can still consume enough CPU and memory to starve its neighbors.

Think of a namespace as drawing a line on a map. The line exists, but nothing stops anyone from walking across it unless you put up a fence.

Building the actual fences

This is where the real multi-tenancy work happens, and it comes down to a handful of layered controls.

Role based access control decides who can do what inside each namespace. A well scoped RBAC setup means the payments team’s engineers can deploy and manage resources in their own namespace but cannot even view what is running in marketing’s namespace, let alone modify it.

Network policies control which pods can talk to which other pods. By default, Kubernetes networking is wide open, any pod can reach any other pod on the cluster. Network policies let you lock this down so that traffic only flows where it is explicitly allowed, effectively giving each team their own isolated network segment even though they are sharing the same physical infrastructure.

Resource quotas and limit ranges stop the noisy neighbor problem. Without them, one team’s runaway job can eat all the available memory on a node and crash workloads belonging to someone else entirely. Quotas cap how much CPU, memory, and storage each namespace can consume, and limit ranges enforce sane defaults on individual pods so nobody accidentally deploys something that requests the entire node’s capacity.

Pod security standards restrict what a workload is allowed to do at the container level, blocking things like running as root, mounting the host filesystem, or gaining privileged access to the underlying node. This matters because a compromised or misconfigured container is one of the most common ways an attacker escalates from a single pod into the broader cluster.

Stack these together and you get something that functions much closer to real isolation, even though everyone is technically sharing the same cluster.

Where soft isolation stops being enough

This is an aspect of the process that is often overlooked. In fact, namespaces, RBAC, networking policies, and quotas are referred to as soft multi-tenancy, meaning that they rely on the Kubernetes control plane and isolation of the kernel. Both aforementioned technologies are shared and any vulnerability in the Kubernetes container runtime or exploit of the kernel that can result in escape out of the container results in failure of the namespace mechanism to prevent data access from the workload from one tenant to another.

For almost any internal team that works on internal products, soft isolation is a sufficient solution. There is low risk and the teams trust each other, which justifies any savings from this solution. However, there are cases when soft isolation is unfeasible. If external customers are running workloads and they must not access other tenants’ information in any way, separate clusters should be used.

If you have regulatory requirements that demand physical or logical separation, like healthcare data under HIPAA or financial data under PCI DSS, auditors often want to see actual infrastructure boundaries, not just policy configuration. And if one tenant’s workload is unpredictable enough that even generous quotas cannot fully contain its impact, giving it a dedicated cluster removes the risk of it ever touching anyone else.

This is often described as hard multi-tenancy, and the tradeoff is straightforward. You give up some cost efficiency in exchange for a much smaller blast radius and a much simpler security story.

Finding the right balance for your organization

There is no right answer for that, and those who say otherwise are oversimplifying the situation. The best choice depends on your trust level in your partner teams, the nature of the data they are processing, and your compliance obligations. There is a common way for organizations to approach this – to group teams based on trust levels and sensitivity: low-risk internal applications can share softly isolated namespaces; however, anything that deals with customer data and regulated workloads must be run in a separate cluster to operate efficiently. 

If you are using one shared cluster where teams differ only by their namespace names, it is recommended to do an audit of your setup as soon as possible before something happens that will make you do it anyway, in order to avoid the complications.