Enforcing Zero-Trust in Multi-Tenant Kubernetes

How do you isolate tenants in a shared Kubernetes cluster?

Treat every pod as untrusted, including your own. Put a proxy in front of each one so all traffic is authenticated and encrypted between services. Then write policies that say exactly which service may call which. If an attacker gets code running on a node, they land in a box that can only reach the few services you allowed, instead of the whole cluster.

Perimeter security is dead

In a modern cloud-native architecture, assuming internal network traffic is safe is a catastrophic error. A single compromised container in a multi-tenant cluster can laterally scan and exploit the entire network, because the default Kubernetes network model is flat: every pod can reach every other pod.

A namespace does not change this. It scopes names and RBAC. It does not stop packets.

Default-deny, then allow deliberately

The first NetworkPolicy in any cluster should deny everything, so that every subsequent policy is an explicit, reviewable grant rather than a patch on an open network.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: tenant-a
spec:
  podSelector: {}          # every pod in the namespace
  policyTypes: [Ingress, Egress]

Egress matters as much as ingress and is the half teams routinely skip. Most of what an attacker does after landing in a container, reaching a metadata endpoint, exfiltrating to an external host, pulling a second-stage payload, is outbound.

Mutual TLS via service mesh

By injecting an Envoy sidecar proxy into every pod using Istio, we force all traffic to traverse the proxy:

1. Authentication: proxies authenticate each other using short-lived workload certificates, so identity is cryptographic rather than based on IP address, which in a cluster is reassigned constantly.
2. Encryption: all internal traffic is encrypted with mTLS, including traffic that never leaves the node.
3. Authorization: policies define which service may call which. The frontend service can talk to api-gateway, but cannot connect directly to database-core.

Implementing this requires discipline, but it ensures that even if an attacker achieves remote code execution on a worker node, their blast radius is contained to the handful of services that workload identity was permitted to reach.

References

• NIST SP 800-207. Zero Trust Architecture, the reference definition.
• Kubernetes. Network Policies.
• Istio. Mutual TLS authentication.