Namespaces Are Not Security Boundaries in Kubernetes
“Don’t worry, that service runs in its own namespace.”
Every platform engineer has heard this phrase in an architecture review. And in vanilla Kubernetes, it is one of the most dangerous misconceptions in cloud-native security.
By default, Kubernetes uses a flat pod network. Unless your CNI enforces network policies, a compromised pod in namespace-marketing-dev can open a direct TCP connection to a database or internal API in namespace-payments-prod using nothing more than its cluster IP or DNS name.
A Namespace is just an API naming scope—not a firewall.
If you want real tenant or environment boundaries inside a shared cluster, every namespace provisioning template needs three non-negotiable defaults on Day 1:
- A default-deny ingress & egress
NetworkPolicythat blocks all cross-namespace traffic unless explicitly allow-listed. ResourceQuotaandLimitRangeso a runaway deployment in one namespace cannot starve node CPU/memory for neighbors.- Dedicated
ServiceAccountbindings withautomountServiceAccountToken: falsewherever pods don’t talk to the Kubernetes API.
A vanilla Kubernetes Namespace is just an organizational folder until you lock it down with default-deny NetworkPolicies, ResourceQuotas, and least-privilege ServiceAccounts.