A Network Policy is a Kubernetes API object that specifies how pods are allowed to communicate with each other and with external network endpoints. Network policies implement micro-segmentation — fine-grained network controls that restrict traffic to only what is explicitly permitted, rather than allowing all-to-all communication within a cluster.
The default-deny imperative
By default, Kubernetes allows all pods to communicate with all other pods across all namespaces — a flat network model that is convenient but deeply insecure. A single compromised application pod can attempt to connect to any other service in the cluster, potentially accessing databases, identity services, or sensitive APIs it has no legitimate reason to contact.
The first and most important network policy configuration in any production cluster is a default-deny-all policy in each namespace — blocking all ingress and egress traffic except what is explicitly permitted. Applications then declare the specific traffic they require, which is allowed. This implements the zero-trust principle of least-privilege at the network layer.
Network policies and the CNI plugin
Network policies are defined at the Kubernetes API level, but they are enforced by the Container Network Interface (CNI) plugin — the software component responsible for pod networking. Not all CNI plugins enforce network policies (the basic Flannel plugin does not, for example). Production-grade CNI plugins — Calico, Cilium, WeaveNet — implement network policy enforcement at the kernel level using iptables or eBPF.
Beyond Kubernetes: VLAN segmentation
For highly regulated environments, network segmentation extends beyond the Kubernetes layer to physical network infrastructure. VLAN-based segmentation isolates different security zones at the hardware switch level — ensuring that even a Kubernetes networking bug or misconfiguration cannot allow traffic to cross security boundaries, because the physical network prevents it.