Kubernetes Network Policies

NetworkPolicy spec, ingress/egress rules, podSelector and namespaceSelector, and CNI support (Calico/Cilium).

Overview

Overview Kubernetes NetworkPolicy resources define rules for how pods can communicate with each other and with endpoints outside the cluster. By default, Kubernetes applies no network isolation — all pods can communicate with all other pods regardless of namespace. NetworkPolicy is the mechanism for implementing Zero Trust microsegmentation within a Kubernetes cluster.

A NetworkPolicy applies to a set of pods (selected by a podSelector label query) and defines which inbound (ingress) and outbound (egress) traffic is allowed. Once at least one NetworkPolicy selects a pod, that pod's traffic is restricted to what the policies explicitly allow — unmatched traffic is denied. A pod with no NetworkPolicy selecting it remains unrestricted.

The NetworkPolicy spec has three key selectors: podSelector (which pods this policy applies to), ingress rules (inbound traffic — from which pods/namespaces/CIDR blocks), and egress rules (outbound traffic — to which pods/namespaces/CIDR blocks). Each ingress or egress rule can specify a combination of podSelector, namespaceSelector, and ipBlock.

A critical implementation detail: NetworkPolicy is enforced by the CNI (Container Network Interface) plugin, not by the Kubernetes control plane itself. The default CNI plugins (Flannel, kubenet) do not enforce NetworkPolicy — they simply ignore the resources. You must use Calico, Cilium, Weave Net, or Antrea. If you apply NetworkPolicy rules without a supporting CNI, the policies exist in the API server but have no effect.

Calico implements NetworkPolicy using iptables rules on each node. It also provides GlobalNetworkPolicy (cluster-wide policies) and host endpoint policies. Cilium implements NetworkPolicy using eBPF programs, achieving higher performance and adding L7-aware policies (HTTP path and method matching) that standard NetworkPolicy cannot express.

Key concepts

Default deny vs default allow: Without any NetworkPolicy, all pod-to-pod traffic is allowed. Once a NetworkPolicy selects a pod, that pod is isolated — only explicitly allowed traffic passes. To achieve cluster-wide deny-all, apply a policy selecting all pods with empty ingress/egress rules.
podSelector: A label selector that determines which pods a NetworkPolicy applies to. An empty podSelector ({}) matches all pods in the namespace.
namespaceSelector: Selects traffic from (ingress) or to (egress) pods in namespaces matching the label query. Combined with podSelector in the same rule element with AND semantics. Separate rule elements combine with OR.
CNI enforcement requirement: NetworkPolicy resources are enforced by the CNI plugin, not Kubernetes itself. Flannel and kubenet do not enforce NetworkPolicy. Calico (iptables), Cilium (eBPF), Weave Net, and Antrea enforce NetworkPolicy.
Cilium L7 policy: Cilium extends standard NetworkPolicy with L7-aware rules that can restrict HTTP methods, paths, gRPC service methods, and Kafka topics. Standard Kubernetes NetworkPolicy only operates at L3/L4.

When to use it

Implementing network isolation between namespaces in a multi-tenant Kubernetes cluster
Restricting pod-to-pod communication so only specific services can reach the database pods
Implementing a default-deny posture and selectively allowing required traffic
Choosing between Calico and Cilium CNI for a cluster that requires NetworkPolicy enforcement
Debugging a connectivity failure caused by a NetworkPolicy blocking expected traffic

Interview questions

Write Kubernetes NetworkPolicy resources to implement a three-tier isolation: frontend can talk to backend, backend can talk to database, no other pod-to-pod traffic allowed.
What is the difference between Calico and Cilium for NetworkPolicy enforcement, and when would you choose Cilium?

Kubernetes Network Policies

Overview

Key concepts

When to use it

Interview questions

More Networking topics