Security Analysis

Threat model

The primary adversary in a multi-tenant cluster is another tenant — via a compromised dependency in their own workload, a misconfigured application, or, in SaaS contexts, malicious intent. The secondary adversary is an external attacker who has compromised one tenant's application and is now attempting to pivot laterally or escalate to the shared infrastructure.

Attack surface

The attack surface spans: the Kubernetes API server (via any leaked or over-privileged ServiceAccount token), the pod network (via the flat networking model absent NetworkPolicy), the container runtime and kernel (via container breakout techniques), and the CI/CD pipeline that deploys into the cluster (via supply-chain compromise of a base image or dependency).

Authentication and authorization

Kubernetes authenticates identities (users, groups, ServiceAccounts) but delegates all authorization decisions to RBAC (or webhook authorizers). Every RoleBinding and ClusterRoleBinding in the cluster is part of the authorization surface — a single overly broad ClusterRoleBinding undermines every namespace boundary built on top of it.

Network isolation

Covered in depth above. The critical point for a security review: NetworkPolicy is enforced by the CNI, and a cluster running a CNI without NetworkPolicy support (or with it disabled) has zero network isolation regardless of how many NetworkPolicy manifests are applied.

Secrets

Kubernetes Secrets are base64-encoded, not encrypted, by default in etcd unless encryption at rest is explicitly configured. In a multi-tenant cluster, anyone with read access to etcd backups, or with the RBAC permission to read Secrets in a namespace they shouldn't have access to (see the RBAC section), can read tenant credentials in plaintext.

Privilege escalation and container security

Pod Security Standards' restricted profile blocks the most common escalation paths — privileged containers, host namespace sharing, arbitrary Linux capabilities. It does not eliminate every container-to-host escape; the residual risk is a kernel vulnerability exploitable even from a properly restricted container, which is why mutually distrustful tenants on the same kernel remains a real risk even with every control in this article applied.

Supply-chain and misconfiguration risks

Tenants pulling images from public registries introduce supply-chain risk into a shared cluster. An admission controller restricting allowed registries, combined with image signature verification, reduces this. Misconfiguration — a missing NetworkPolicy in a newly created tenant namespace, a ClusterRoleBinding added during an incident and never removed — is more common in practice than any exploit and should be caught by continuous policy validation, not a one-time review.

Logging, monitoring, detection, and incident response

Kubernetes audit logs record every API request, including who accessed what in which namespace — this is the primary detection surface for cross-tenant access attempts. Network flow logs from the CNI (Calico and Cilium both support this) show attempted connections that a NetworkPolicy blocked, which is direct evidence of either a misconfigured legitimate service or an active lateral-movement attempt.

Before / After Comparison

BEFORE — flat trust, no isolation:

Cluster (single flat network, no default-deny)
   |
   +-- tenant-a namespace
   |      +-- web pods  (reachable from anywhere in the cluster)
   |      +-- database  (reachable from anywhere in the cluster)
   |
   +-- tenant-b namespace
          +-- web pods  (reachable from anywhere in the cluster)
          +-- database  (reachable from anywhere in the cluster)

RBAC: broad ClusterRoleBinding grants "view" across all namespaces
Pods: run as root, no Pod Security enforcement
  

AFTER — enforced tenant boundaries:

Cluster
   |
   +-- tenant-a namespace [pod-security: restricted]
   |      +-- default-deny NetworkPolicy
   |      +-- allow: ingress-system -> web:8080, egress -> kube-system:53
   |      +-- RoleBinding scoped to tenant-a only
   |
   +-- tenant-b namespace [pod-security: restricted]
          +-- default-deny NetworkPolicy
          +-- allow: ingress-system -> web:8080, egress -> kube-system:53
          +-- RoleBinding scoped to tenant-b only

Cross-namespace ClusterRoleBindings: removed / audited
  

What changed: network reachability moved from allow-all to explicit-allow-only per namespace; RBAC moved from cluster-wide bindings to namespace-scoped bindings; and pod creation is now checked against a security profile at admission time instead of being unconstrained. None of these changes require a different cluster — they are policy applied on top of the same infrastructure.

Common Mistakes

1. Treating namespaces as a security boundary by themselves

What people do: create one namespace per tenant and consider the isolation work done. Why it's dangerous: namespaces are an administrative and naming boundary in the Kubernetes API — they add zero network or RBAC restriction on their own. How to fix it: pair every namespace with a default-deny NetworkPolicy and namespace-scoped RBAC from the moment the namespace is created, ideally automated via a namespace-provisioning pipeline rather than manual steps.

2. Binding ClusterRoles with ClusterRoleBindings for tenant users

What people do: grant a tenant team's group a convenient ClusterRoleBinding because it's one object instead of one RoleBinding per namespace. Why it's dangerous: it grants that permission in every current and future namespace in the cluster, including other tenants'. How to fix it: use RoleBindings referencing a ClusterRole (this is valid and namespaces the effect), never ClusterRoleBindings, for tenant-scoped access.

3. Forgetting egress rules and only restricting ingress

What people do: write a NetworkPolicy that restricts inbound traffic to a tenant's pods but leaves egress unrestricted. Why it's dangerous: a compromised pod in tenant-a can still reach out to tenant-b's services, exfiltrate data to the internet, or call internal cloud metadata endpoints. How to fix it: apply default-deny to both Ingress and Egress policyTypes, and explicitly allow only DNS and required destinations.

4. Assuming NetworkPolicy is enforced without checking the CNI

What people do: apply NetworkPolicy manifests and assume they work because kubectl apply succeeded. Why it's dangerous: kubectl apply succeeding only means the object was stored in etcd — the API server does not itself enforce NetworkPolicy, the CNI plugin does, and several CNIs (or CNI configurations) silently ignore NetworkPolicy objects entirely. How to fix it: run the adversarial connectivity test from the lab section — attempt a blocked connection and confirm it actually fails — on every cluster, not just once at setup.

5. Sharing a default ServiceAccount token across all pods in a namespace

What people do: leave the default ServiceAccount's automatic token mount enabled for every workload, including ones that never call the Kubernetes API. Why it's dangerous: a compromised pod inherits a live, valid Kubernetes API credential it doesn't need, giving an attacker with only container-level access a path to the control plane. How to fix it: set automountServiceAccountToken: false at the pod or ServiceAccount level for workloads with no legitimate need to call the API, and create narrowly scoped dedicated ServiceAccounts for the ones that do.

6. Running mutually untrusted tenants on the same node pool without runtime sandboxing

What people do: treat namespace + RBAC + NetworkPolicy as sufficient isolation for genuinely adversarial tenants (e.g., running arbitrary customer-submitted code). Why it's dangerous: all tenants still share the same Linux kernel; a kernel-level container escape bypasses every namespace-level control simultaneously. How to fix it: for genuinely untrusted workloads, use dedicated node pools per tenant, or a sandboxed runtime like gVisor or Kata Containers that adds a stronger isolation boundary below the container.

Production Considerations

Security Checklist

• [ ] Every tenant has its own namespace, created via an automated pipeline, not manually
• [ ] Default-deny NetworkPolicy (Ingress + Egress) applied in every tenant namespace
• [ ] Explicit allow rules exist only for required paths (DNS, ingress controller, named dependencies)
• [ ] CNI plugin confirmed to enforce NetworkPolicy (tested, not assumed)
• [ ] RBAC uses namespaced RoleBindings for tenant access; no tenant-facing ClusterRoleBindings
• [ ] `pod-security.kubernetes.io/enforce: restricted` label set on every tenant namespace
• [ ] `automountServiceAccountToken: false` set for workloads that don't call the Kubernetes API
• [ ] ResourceQuota and LimitRange applied per tenant namespace
• [ ] Secrets encryption at rest enabled in etcd
• [ ] Audit logging enabled and reviewed for cross-namespace access attempts
• [ ] Adversarial cross-tenant connectivity test performed and re-run after any CNI or policy change
• [ ] Genuinely untrusted tenants scheduled on dedicated node pools or a sandboxed runtime, not shared nodes

FAQ

Is Kubernetes Namespace isolation enough for multi-tenancy?

No. A namespace is an API-level grouping mechanism with no inherent network, compute, or identity isolation. It becomes a security boundary only once RBAC, NetworkPolicy, Pod Security Standards, and resource quotas are applied on top of it.

Can NetworkPolicies completely isolate tenants?

They isolate at the network layer (L3/L4) and are a necessary control, but not sufficient alone. RBAC still governs API-level access, Pod Security Standards govern what a container can do on its node, and the underlying kernel is still shared — a container-breakout vulnerability bypasses NetworkPolicy entirely.

Do I need a service mesh for multi-tenant Kubernetes?

Not strictly. A service mesh adds L7 controls (mTLS between services, fine-grained authorization by HTTP path/method) that NetworkPolicy cannot express. It's valuable when tenants need cryptographic proof of peer identity or fine-grained API-level authorization between services, but namespace + RBAC + NetworkPolicy + Pod Security Standards is a complete baseline without one.

What's the difference between soft and hard multi-tenancy?

Soft multi-tenancy assumes tenants trust each other and the platform (typical for internal teams); hard multi-tenancy assumes tenants do not trust each other (typical for SaaS customers) and requires stronger enforced boundaries — RBAC, NetworkPolicy, Pod Security Standards, and often dedicated nodes — rather than relying on tenant goodwill.

Should I use dedicated clusters instead of shared namespaces?

Use dedicated clusters when regulatory requirements demand a separate control plane per tenant, when tenants are fully adversarial and a kernel-level compromise is unacceptable risk, or when the operational cost of managing many clusters is lower than the cost of a namespace-isolation failure for your business. Otherwise, namespace-based hard multi-tenancy with the controls in this article is the common production choice.

How do I test that my isolation actually works?

Deploy a throwaway pod in one tenant's namespace and attempt to reach another tenant's Service ClusterIP and the Kubernetes API server directly. A successful isolation setup produces connection timeouts and RBAC "Forbidden" errors respectively. Re-run this test after any change to the CNI, RBAC, or admission configuration.

Does Pod Security Admission replace PodSecurityPolicy?

Yes — PodSecurityPolicy was removed from Kubernetes as of v1.25. Pod Security Admission, using the predefined privileged/baseline/restricted profiles applied via namespace labels, is its built-in replacement; OPA Gatekeeper or Kyverno are used when requirements go beyond the built-in profiles.

Conclusion

Kubernetes gives you the primitives for multi-tenancy — namespaces, RBAC, NetworkPolicy, Pod Security Admission, ResourceQuota — but none of them are isolating by default, and none of them are optional if tenants don't fully trust each other. The most important lesson is that isolation is additive: each layer closes a specific gap the others don't cover, and skipping any one of them (especially egress NetworkPolicy or namespace-scoped RBAC) leaves a real, exploitable path between tenants.

What should be done next: audit your current cluster for ClusterRoleBindings that shouldn't exist, confirm your CNI actually enforces NetworkPolicy, and add the adversarial connectivity test from the lab section to your CI/CD pipeline so isolation failures are caught before they reach production. If your tenants are genuinely adversarial rather than merely separate, start evaluating dedicated node pools or a sandboxed runtime now, before an incident forces the decision.

The practical recommendation: build tenant namespace provisioning as a single automated, version-controlled pipeline that applies every control in the checklist atomically. Isolation that depends on a human remembering a manual step will eventually fail; isolation encoded as policy-as-code will not.

Related reading on 0thman.tech:

• [Internal Link: Zero Trust Cloud Security Architecture]
• [Internal Link: Kubernetes RBAC Deep Dive]
• [Internal Link: DevSecOps Pipeline Design]
• [Internal Link: GitOps with ArgoCD]
• [Internal Link: Container Security Fundamentals]

References

• Kubernetes Documentation — Network Policies
• Kubernetes Documentation — RBAC Good Practices
• Kubernetes Documentation — Pod Security Standards
• Kubernetes Documentation — Resource Quotas
• Kubernetes Documentation — Multi-tenancy
• CNCF — Multi-Tenancy Working Group guidance
• OWASP — Kubernetes Top Ten
• CIS — Kubernetes Benchmark
• MITRE ATT&CK — Containers Matrix
• Project Calico — Network Policy documentation