Kubernetes Networking Without Default-Deny: The Flat Trap

Overview

Every namespace in a fresh Kubernetes cluster can reach every other namespace over the pod network because no NetworkPolicy resources exist anywhere. A single compromised pod in a low-trust namespace can then query internal services directly by ClusterIP or DNS, and existing RBAC and namespace boundaries do nothing to stop it.

At a glance

Unsafe setting: No NetworkPolicy resources exist in any namespace, leaving the pod network fully open by default.
Failure trigger: A compromised pod in one namespace connects directly to services in another namespace with no policy blocking the path.
Blast radius: Attackers pivot laterally across namespaces via pod IPs or ClusterIP DNS with no segmentation, authentication, or logging to stop them.
Recommended control: Deploy a default-deny NetworkPolicy in every namespace and enforce it with a policy-aware CNI such as Calico or Cilium.

The Trap

The absent default-deny NetworkPolicy. Kubernetes ships with no built-in network segmentation model. Unless an administrator explicitly creates NetworkPolicy objects, every pod on the cluster network can initiate a connection to every other pod, on any port, across any namespace, provided the underlying CNI plugin honours NetworkPolicy at all.

The Default State

A vanilla cluster install, whether kubeadm, EKS, AKS, or GKE with a basic CNI, applies zero NetworkPolicy resources at creation time. Namespaces are treated by engineers as logical and administrative boundaries, when in fact they impose no network isolation whatsoever. Teams routinely rely on namespace separation for multi-tenancy or environment isolation (dev, staging, payments, logging) while the pod network underneath remains completely flat. Ingress and egress are unrestricted by default, and this is documented Kubernetes behaviour, not a bug.

The Blast Radius

A single exploited container, say a public-facing web pod with a deserialisation vulnerability, can immediately reach the internal payments namespace, the secrets-management namespace, or kube-system components such as the metrics-server or CoreDNS pods, purely via pod IP or in-cluster DNS. There is no lateral-movement friction: no firewall rule, no segmentation, no authentication layer sits between namespaces. An attacker can port-scan the entire pod CIDR from inside one low-value workload, enumerate ClusterIP services, and pivot straight into databases or internal APIs that were never designed to be reachable from outside their own namespace. RBAC controls the Kubernetes API surface, not the pod-to-pod data plane, so tightly scoped ServiceAccounts and roles provide no protection here at all.

The Lead Mechanic Fix

Apply a default-deny NetworkPolicy in every namespace before any workload is scheduled: a policy with podSelector: {} and policyTypes: [Ingress, Egress] and no rules, which blocks all traffic by default. Layer explicit allow policies on top for required service-to-service paths only, matched by podSelector and namespaceSelector labels, never by CIDR ranges that drift. Confirm the CNI actually enforces NetworkPolicy (Calico, Cilium, or Azure CNI in policy mode; flannel alone does not). For stricter control, deploy Cilium with L7-aware CiliumNetworkPolicy or Calico GlobalNetworkPolicy to enforce a cluster-wide default-deny baseline that new namespaces inherit automatically, rather than relying on per-namespace hygiene.