Kubernetes Network Policies

NetworkPolicy resources control which Pods can communicate. Ingress rules restrict incoming traffic; Egress rules restrict outgoing. Default: all traffic allowed. With policy: only explicitly allowed traffic permitted. Requires CNI with NetworkPolicy support (Calico, Cilium, Weave).

Overview

NetworkPolicy as a Pod firewall

Kubernetes NetworkPolicy resources act as firewall rules for Pods inside the cluster. They are the primary tool for implementing least privilege at the network layer.

Default behavior

Without any NetworkPolicy, every Pod can talk to every other Pod in the cluster on any port. This is intentional for getting started but unsuitable for production.

How policies work

A NetworkPolicy selects a group of Pods with a label-based podSelector. Once at least one policy selects a Pod, that Pod enters a deny-by-default posture for the policy types (Ingress, Egress) the policy covers. Only traffic explicitly permitted by a rule is allowed.

Ingress — Traffic entering a selected Pod — podSelector, namespaceSelector, ipBlock, on specific ports and protocols
Egress — Traffic leaving a selected Pod — Same selectors

> [!WARNING] If you restrict Egress, explicitly allow DNS (UDP 53 to kube-dns) or Pod DNS lookups break.

Enforcement depends on the CNI

NetworkPolicy is enforced by the CNI plugin, not by Kubernetes itself. With a CNI that does not support it, the objects are stored but silently ignored and all traffic keeps flowing.

Flannel — No, policies silently ignored
Calico, Cilium, Weave Net, Antrea, Amazon VPC CNI — Yes

> [!IMPORTANT] Check the CNI before writing policies: on Flannel, a perfect policy does nothing.

Key concepts

podSelector: Label selector within a NetworkPolicy that determines which Pods the policy applies to. An empty podSelector ({}) selects all Pods in the namespace — useful for a namespace-wide default-deny policy.
namespaceSelector: Allows traffic from/to all Pods in namespaces matching the given labels. Must label the namespace (kubectl label namespace name=) for this to work.
policyTypes: Declares whether the policy governs Ingress, Egress, or both. If Ingress is listed, the Pod gets a deny-all-ingress posture modified only by the ingress rules in this policy. Same for Egress.
Default deny all: A NetworkPolicy with an empty podSelector and no ingress/egress rules drops all traffic in that direction for all Pods in the namespace. Standard pattern: apply one default-deny, then add fine-grained allow policies on top.
CNI enforcement requirement: NetworkPolicy objects have no effect if the CNI does not implement them. Flannel does NOT support NetworkPolicy. Calico, Cilium, Weave Net, Antrea, and Amazon VPC CNI do.
DNS egress allow: Any Egress NetworkPolicy must explicitly allow UDP/TCP port 53 to the kube-dns Service or all DNS lookups will fail — apps break with confusing errors that look like service connectivity issues, not DNS.

When to use it

Implementing zero-trust network posture inside a Kubernetes cluster
Isolating namespaces from each other in a multi-tenant cluster
Restricting a compromised Pod from lateral movement to other services
Meeting compliance requirements (PCI-DSS, SOC2, HIPAA) that require network segmentation
Any production cluster — the default allow-all posture is not appropriate for sensitive workloads

Interview questions

What happens when you create a NetworkPolicy for a Pod that previously had no policy?
Write a NetworkPolicy that allows only frontend pods to reach backend pods on port 8080.
Why might a NetworkPolicy not be working even though you applied it correctly?
How do you implement a zero-trust network posture in a Kubernetes namespace?