Sitemap

Kubernetes -Network Policies

4 min readDec 17, 2024

📖 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.

Zoom image will be displayed
Network policy inside namespace A allow traffic to pod-a from pod-b only

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:

  1. Pod labels
  2. Namespaces
  3. 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:

Zoom image will be displayed

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 treat hostNetwork 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.
Umang Unadakat
Umang Unadakat

Written by Umang Unadakat

DevOps Engineer with 4+ years of experience in automating deployments, managing cloud infrastructure, and working with infrastructure automation.

Responses (1)

Write a response