Kubernetes -Network Policies
📖 Overview
A NetworkPolicy is a Kubernetes resource that defines rules for controlling the traffic flow to/from pods. It works at layer 3 (IP) and layer 4 (TCP/UDP) of the OSI model. The policies are namespaced and use labels to identify the target pods and define allowed traffic.

Kubernetes Network Policies are resources used to control the flow of ingress (incoming) and egress (outgoing) traffic to and from pods.
By default, pods in Kubernetes can communicate freely with each other.
Network Policies allow you to define rules to allow or deny traffic based on:
- Pod labels
- Namespaces
- IP blocks
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-traffic-from-pod-b
namespace: namespace-a # Network Policy applies to this namespace
spec:
podSelector: # Select target pods
matchLabels:
pod: pod-a
ingress: # Define allowed incoming traffic
- from:
- namespaceSelector: # Allow traffic from namespace-b
matchLabels:
kubernetes.io/metadata.name: namespace-b
- podSelector: # Allow traffic from pod-b with specific labels
matchLabels:
pod: pod-b
ports: # Allow only traffic to port 80
- protocol: TCP
port: 80
👀 Behind the Scenes
When the CNI plugin receives the NetworkPolicy, it programs the rules into the Linux kernel using:

1. iptables
Many CNI plugins (e.g., Calico, Weave) use iptables
to enforce Network Policies by manipulating the Netfilter subsystem in the kernel.
Packet Traversal: Packets travel through chains (tables) defined by iptables in the following order:
PREROUTING
: Before routing decisions (used for NAT).INPUT
: For packets destined to the host machine.FORWARD
: For packets being routed (e.g., between pods).OUTPUT
: For packets generated by the host.POSTROUTING
: After routing decisions.
Iptables Rules for Network Policies:
When you define a Network Policy:
- The CNI plugin programs iptables rules into the
FORWARD
chain for pod-to-pod traffic. It uses pod IP addresses and labels mapped to IP ranges to create rules. The rules allow or drop packets based on the Network Policy definition.
Example:
- A pod has a Network Policy allowing ingress only from specific pod selectors.
- The CNI plugin creates an iptables rule:
-A FORWARD -s <source-pod-IP> -d <destination-pod-IP> -p tcp --dport 80 -j ACCEPT
-A FORWARD -d <destination-pod-IP> -j DROP
- This ensures only packets from allowed pod IPs can access the target pod on port 80. All other traffic is dropped.
2. eBPF/XDP
Modern CNI plugins like Cilium use eBPF to enforce Network Policies at the kernel level. eBPF is faster and more flexible compared to iptables.
How eBPF works under the hood:
- eBPF allows developers to attach custom programs to hooks in the Linux kernel (e.g., network interfaces, sockets).
- These programs run in kernel space and can inspect, filter, or modify packets efficiently.
eBPF programs are attached to hooks like XDP (eXpress Data Path) or TC (Traffic Control) to intercept packets as soon as they hit the network interface.
The eBPF program extracts packet headers (e.g., source/destination IP, ports, protocols). It evaluates the packet against the Network Policy rules (ingress/egress).
If the packet matches the policy, it’s allowed to pass. If not, the packet is dropped immediately without traversing the rest of the network stack.
Example:
- A Network Policy allows ingress from specific pods.
- An eBPF program inspects packets:
if (packet.src_ip == allowed_ip && packet.dest_port == 80) {
return XDP_PASS; // Allow packet
}
return XDP_DROP; // Drop packet
The kernel or iptables filters packets based on:
- Pod IP: Kubernetes allocates a unique IP for each pod.
- Ports: Protocols and port numbers are evaluated.
If traffic does not match an allowed rule, it’s dropped at the node level before reaching the pod.
🌟 Gotchas
- When you apply an ingress or egress Network Policy, all traffic is denied by default unless explicitly allowed.
- Network Policies only apply within a namespace unless you use
namespaceSelector
. - Policies in one namespace cannot directly affect pods in another namespace.
- Network Policies may not apply to pods using
hostNetwork
. Most CNIs treathostNetwork
traffic as part of the node’s traffic, bypassing policies. - Isolation applies to init containers, sidecar containers, and regular containers because NetworkPolicies are applied at the pod level.
- After a NetworkPolicy is applied, all newly created pods affected by the policy will start isolated, ensuring filtering is effective from the very first moment a pod starts.
- If a pod is created before the NetworkPolicy is fully handled, that pod may temporarily start unprotected. The isolation and allow rules will be applied eventually once the NetworkPolicy is handled.
- Kubernetes does not provide a way to determine exactly when a NetworkPolicy has been enforced. The enforcement happens eventually, but there is no direct signal in the Kubernetes API to confirm it.
- Behavior and enforcement of NetworkPolicy may vary depending on the CNI being used. Always refer to your CNI’s documentation to understand how policies are applied.
- Calico: Supports iptables and eBPF for enforcement. eBPF provides better performance and visibility.
- Cilium: Fully utilizes eBPF for high performance, scalability, and deeper visibility into network traffic.
- Misconfigured CNIs can result in policies being ignored or applied inconsistently. CNI logs are critical to debugging such issues. Use tools like kubectl describe, CNI logs, and network analysis tools (kube-hunter, kubectl-trace) for troubleshooting.