Kubernetes Multi-Tenancy: Beyond Namespaces

Six months ago, your team built a shared Kubernetes platform. The first few internal teams onboarded smoothly. Namespaces per team, RBAC configured, NetworkPolicy deployed. Everyone felt good about it.

Then the payments team asks to run PCI-scoped workloads. Your security team runs an isolation assessment and asks one question: “Can the marketing team’s pods reach the payment namespace over the network?” You check. With your current Cilium configuration and the default-allow egress policy nobody thought to restrict, the answer is yes.

Separate floors. All the doors unlocked. Marketing just walked into finance.

The PCI DSS requirements are unambiguous on network segmentation. The Kubernetes Multi-Tenancy Working Group defines the isolation models. But most teams discover the gaps the same way you just did.

The Three Isolation Models

The isolation model sets the security ceiling for your entire platform. Choose it before the first tenant onboards. Changing it later means re-architecting under load. Remodeling the building with tenants already in it.

Namespace isolation works for internal teams that trust each other. Pods share nodes and the control plane. Separate floors, same building, same hallways. If compromise in one namespace triggers breach notification to another tenant, this model is not enough.

vCluster occupies the sweet spot that most teams overlook. Each tenant gets a virtual API server, scheduler, and controller manager running as pods in the host cluster. A building-within-a-building. Own reception, own mailroom, shared parking lot. Shared nodes keep costs down. Each virtual cluster adds only a few hundred megabytes of memory overhead, so a single host cluster can run dozens of them affordably. Tenants can install their own CRDs and get cluster-admin on their virtual cluster without affecting neighbors.

Cluster per tenant provides the strongest isolation but the highest operational cost. Separate buildings. Beyond a dozen tenants, manual cluster management breaks down. Cloud-native automation for cluster lifecycle becomes mandatory.

NetworkPolicy Gaps the Docs Won’t Warn You About

Four gaps catch teams after they’ve already shipped what they believed was production-grade network isolation. Four unlocked doors that look locked.

Your CNI might not enforce policies at all. NetworkPolicy is an API object. Enforcement is a CNI feature. Flannel does not enforce NetworkPolicy. If you’re running Flannel and you have NetworkPolicy objects deployed, those objects are decoration. Every last one. Locks installed but nobody connected the wiring. They click but don’t lock. Clusters have run carefully crafted policies for months with zero enforcement. Calico and Cilium enforce. Verify yours does before you trust a single rule.

# Default-deny + DNS allow - deploy to every tenant namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: tenant-commerce
spec:
  podSelector: {}  # Applies to all pods
  policyTypes: ["Ingress", "Egress"]
  egress:
    - to:  # Allow DNS only
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

    

      ×
      ❚❚
      ‹
      ›
      +
      −
    
    


  

Past 20 tenants, the only sustainable answer is admission controllers. OPA Gatekeeper or Kyverno policies validate RBAC resources on creation, preventing overly broad bindings, enforcing naming conventions, and requiring ownership labels. The security guard who checks every badge at the door. Same principle as [automated remediation](/technology/reliability-operations/automated-remediation/) in reliability engineering: when the system grows past what humans can review, enforcement must be automatic.

A practical starting policy set: block any RoleBinding referencing `cluster-admin` outside the platform namespace, require a `team` label on every ServiceAccount, deny ClusterRoleBindings from tenant namespaces, and require all Roles to specify explicit resource names rather than wildcards.

<details>
<summary>Example OPA Gatekeeper constraint: block wildcard resource access</summary>

```yaml
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sBlockWildcardResources
metadata:
  name: deny-wildcard-resources
spec:
  match:
    kinds:
      - apiGroups: ["rbac.authorization.k8s.io"]
        kinds: ["Role", "ClusterRole"]
    excludedNamespaces: ["kube-system", "platform-system"]
  parameters:
    message: "Roles must specify explicit resource names. Wildcards are not allowed in tenant namespaces."

This constraint prevents tenants from creating Roles with resources: ["*"], which would grant access to every resource type in the namespace. A master key for the floor. Explicit resource lists make RBAC auditable and prevent privilege creep.

Resource Isolation: Preventing Noisy Neighbors

RBAC governs who can do what. Resource isolation governs how much they can consume. Without both, the platform is only half-secured. The badge opens the right doors. But one tenant’s industrial equipment is shaking the entire building.

ResourceQuota sets hard limits per namespace: maximum CPU requests, maximum memory limits, maximum pod count, maximum storage claims. LimitRange sets defaults and maxima for individual containers, preventing pods without resource specs from consuming unbounded node resources. You need both. Without LimitRange, a single pod can eat an entire node. Without ResourceQuota, a namespace can spread pods across every node in the pool. Without desk size limits, one person brings a 12-foot desk. Without floor space limits, one company takes over the building.

Profile actual consumption for 2-4 weeks, set quotas at the 95th percentile plus 20% headroom, and review quarterly. Starting tight is always easier than tightening after the fact, because reducing quotas on running workloads triggers pod evictions and scheduling failures that generate urgent tickets. Shrinking someone’s office while they’re sitting in it.

Taint-and-toleration for dedicated node pools. Platform engineering starts tight and loosens deliberately. The reverse never ends.

Can the marketing team’s pods reach the payment namespace? With default-deny network policies, namespace-scoped RBAC, and admission controllers enforced from day one, the answer is no before the security team even asks. Separate floors. Locked doors. Keys for the right rooms only. The building is quiet for the right reason.