How Kubernetes NetworkPolicy Works with Calico: A Step‑by‑Step Guide

Introduction

Kubernetes can connect Pods across nodes, and by default Pods can talk to each other. In some scenarios isolation is required, which can be achieved with NetworkPolicy. This article, originally published on opsdev, explains how Kubernetes NetworkPolicy works on Calico.

NetworkPolicy Overview

Kubernetes provides the NetworkPolicy feature, supporting namespace‑level and pod‑level network access control using labels. Under the hood it translates policies into iptables rules via Calico.

Control Plane Data Flow

NetworkPolicy resources are created with kubectl , Calico’s policy‑controller watches them and writes them to Calico’s etcd, then calico‑felix on each node reads the policies from etcd and configures iptables.

Policy Templates

Example templates for restricting traffic based on pod labels or namespace labels.

Restrict pods in namespace myns with label role: backend to only allow inbound TCP traffic on port 6379 from pods labeled role: frontend .

Restrict pods with label role: frontend to only allow inbound TCP traffic on port 443 from namespaces labeled user: bob .

Corresponding diagrams illustrate the selectors.

NetworkPolicy Data Structure

The spec defines podSelector for the target pods and ingress.from selectors for allowed source pods or namespaces.

Test Environment

Versions used:

Kubernetes master and node: v1.9.0

Calico: v2.5.0, calico‑policy‑controller (quay.io/calico/kube-policy-controller:v0.7.0)

Runtime Configuration

Additional resources created on the Calico side include a service account, RBAC roles, and a deployment for the policy controller. On the Kubernetes side a NetworkPolicy resource is applied.

Running Status

The calico‑policy‑controller container runs a controller process that opens ports 6443 (Kubernetes API) and 2379 (Calico etcd).

Calico‑felix Policy Configuration

Each node’s calico‑felix fetches policies from etcd and programs iptables, primarily using the cali-pi-[POLICY]@filter chain. Packet processing marks are defined (e.g., 0x2000000 indicates the packet has passed policy checks).

Diagram shows the packet flow and iptables chains.

Flow Analysis Example

A “deny all traffic” policy is applied to a pod. Before and after packet counters demonstrate that packets are marked and dropped by the cali-pi-default.web-deny-all target.

Case Study: Deny All Traffic

The test creates a service app‑web in the default namespace, inspects its labels, applies a deny‑all NetworkPolicy, and verifies that connections to port 80 and ping requests fail as expected.

Conclusion

Kubernetes NetworkPolicy provides network isolation but is still evolving; some features like egress are incomplete, and Calico generates many iptables rules, increasing operational complexity. Users must weigh these factors when deciding to adopt it.

References

https://ahmet.im/blog/kubernetes-network-policy/

https://github.com/ahmetb/kubernetes-network-policy-recipes

https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.9/#networkpolicy-v1-networking

http://www.lijiaocn.com/项目/2017/04/11/calico-usage.html