Implementing Kubernetes NetworkPolicy with Calico: Concepts, Configuration, and Testing

Kubernetes can connect Pods across different nodes, and by default Pods can communicate with each other. In scenarios where certain Pods must not communicate, NetworkPolicy provides fine‑grained access control based on Namespace and Pod labels, implemented internally with iptables.

The article introduces the NetworkPolicy feature, its workflow on Calico, and a simple example that restricts traffic to Pods labeled role: backend in namespace myns , allowing only Pods with label role: frontend on TCP port 6379.

It then presents a second example that limits Pods with label role: frontend to receive traffic only from Pods in namespaces labeled user: bob on TCP port 443.

The NetworkPolicy resource creation flow is described as:

Use kubectl to create a NetworkPolicy object.

Calico’s policy‑controller watches the object and writes it to Calico’s etcd.

On each node, calico‑felix reads the policy from etcd and programs iptables accordingly.

Component versions used in the test environment are Kubernetes v1.9.0 (master and node) and Calico v2.5.0 with the calico‑policy‑controller image quay.io/calico/kube-policy-controller:v0.7.0 .

Deployment steps include creating a service account, RBAC roles, and a deployment for the Calico policy controller, as well as defining the NetworkPolicy resources on the Kubernetes side.

Runtime status shows that the controller establishes two ports: 6443 for the Kubernetes API server and 2379 for Calico’s etcd.

Calico‑felix processes policies by fetching them from etcd and inserting iptables rules, primarily using the cali‑pi‑[POLICY]@filter chain. Packet marking (e.g., flag 0x2000000 ) indicates whether a packet has passed policy checks.

A “deny all traffic” test case demonstrates the full flow: the packet is marked, matched against the cali‑pi‑default.web‑deny‑all target, and finally dropped, confirming the policy’s effect.

The article concludes that while Kubernetes NetworkPolicy provides essential network security, its support in Kubernetes and Calico is still evolving (e.g., egress rules), and the extensive iptables rules on each node increase operational complexity, so users must weigh the benefits against the maintenance overhead.

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