Kubernetes Multi-Tenant Isolation

Running one cluster per team or per customer is simple to reason about and expensive to operate. Sharing clusters saves money and effort, but Kubernetes is not multi-tenant by default: every pod can reach every other pod, a namespace without a quota can consume the whole cluster, a service account with broad permissions can read other teams' secrets, and a container running as root with host access can escape onto the node. Multi-tenant isolation is the set of controls that turn namespaces into real boundaries — and the tests that prove those boundaries hold.

The right level of isolation depends on who the tenants are. Internal teams that trust each other need guardrails against accidents; external customers running untrusted code need hard boundaries close to separate machines.

TL;DR

Choose a tenancy model: namespaces per tenant (soft), virtual clusters (medium), or dedicated node pools or clusters (hard).
Isolate each tenant on every axis: identity (RBAC), network, resources, workload security, nodes, and control plane.
Start every tenant namespace with default-deny NetworkPolicies, a ResourceQuota and LimitRange, and Pod Security Admission at restricted.
Give workloads their own service accounts and cloud identities; never share credentials across tenants.
For untrusted code, add dedicated nodes and sandboxed runtimes (gVisor, Kata Containers), or separate clusters.
Test isolation explicitly: attempt cross-tenant access for each boundary in CI and after platform changes.

Quick Example

A tenant namespace baseline: Pod Security labels, default-deny traffic, and resource limits.

Tests that the boundaries hold:

Core Concepts

Tenancy Models

Isolation Axes

Cluster-Scoped Resources

Some Kubernetes objects — CRDs, ClusterRoles, admission webhooks, StorageClasses, IngressClasses — are cluster-wide. Tenants should not create or modify them; platform teams own them and expose safe, namespaced options. Virtual clusters exist largely to give tenants their own copy of these.

Noisy Neighbors

Even with quotas, tenants share nodes, disks, network bandwidth, and the API server. Heavy workloads can degrade others through CPU contention, disk I/O, or floods of API requests. Dedicated node pools, priority classes, and API Priority and Fairness limit the impact. See Tenant Isolation and Noisy Neighbor Testing.

Testing Isolation

Treat each boundary as a claim to verify:

RBAC: kubectl auth can-i --list --as=<tenant service account> and targeted cross-namespace checks.
Network: probe pods that try to reach other tenants' services, the node network, and the cloud metadata endpoint.
Pod Security: attempt to create privileged, host-network, and root pods in tenant namespaces; expect rejection.
Quotas: deploy workloads that exceed the quota; expect admission errors, not cluster-wide pressure.
Secrets and identity: confirm a tenant workload's cloud identity cannot access another tenant's buckets or databases.

Run these tests in CI against a staging cluster and after every platform change. See Authorization Testing Across Tenant Boundaries.

Best Practices

Automate Tenant Onboarding

Create namespaces, RBAC, policies, quotas, and identities from a template or operator so every tenant gets the same baseline with no manual steps.

Default Deny, Then Allow

Start every namespace with no network access and no permissions, then add explicit allows. Additive mistakes are far easier to spot than missing denies.

Match Isolation to Trust

Use namespace isolation for trusted internal teams, and dedicated nodes, sandboxes, or clusters for untrusted code or regulated data.

Block the Metadata Endpoint

Prevent tenant pods from reaching the cloud instance metadata service, which can expose node credentials.

Common Mistakes

Namespaces Without Network Policy

Cluster-Wide Roles for Convenience

Shared Nodes for Untrusted Code

FAQ

Is Kubernetes multi-tenant?

Not by default. It provides the building blocks — namespaces, RBAC, NetworkPolicies, quotas, Pod Security Admission — but they must be configured deliberately for each tenant, and some resources remain cluster-wide.

Are namespaces a security boundary?

Only partly. With RBAC, network policies, quotas, and Pod Security in place, namespaces provide reasonable isolation for trusted tenants. They still share the control plane, nodes, and kernel, so untrusted tenants need stronger isolation.

What is a virtual cluster?

A tenant-specific Kubernetes control plane running inside a namespace of a host cluster. Tenants interact with their own API server and can install CRDs, while workloads still run on the host cluster's nodes.

How do I stop one tenant from using all cluster resources?

Use ResourceQuotas and LimitRanges per namespace, priority classes for important workloads, dedicated node pools for heavy tenants, and API Priority and Fairness to protect the API server.

How do I prove tenants are isolated?

Write tests that attempt cross-tenant access for each boundary — API permissions, network paths, pod security, quotas, and cloud identities — and run them in CI and after platform changes.