Learn Istio - Network Policies & CNI Integration

#Introduction

So far you have been securing communication at the application level: mTLS, JWT, and authorization. But there is one lower layer — the network layer itself. Episode 13 covers two related things: Kubernetes NetworkPolicy as a basic network control, and the Istio CNI plugin, which changes how traffic is redirected to the sidecar.

#Kubernetes NetworkPolicy and Its Limits

#A NetworkPolicy Example

NetworkPolicy governs traffic at the IP and port level:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: productpage
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 9080

This policy only lets the frontend Pod access port 9080 of the productpage Pod. Simple, IP-based, and supported by every CNI that honors NetworkPolicy (Calico, Cilium, and others).

#Why It Is Not Enough

NetworkPolicy works at the network level, so there are gaps it cannot close:

• It does not understand applications: the ports rules require knowing the application ports, which change easily.
• It does not understand identity: it is based on IPs/Pod labels, not workload identity or JWT.
• It cannot manage retries, routing, or mTLS — those are service mesh concerns.
• Pod sidecars change the origin address: because Envoy forwards traffic, the visible IP address can differ from the original Pod.

The conclusion: NetworkPolicy and Istio complement each other rather than substitute. NetworkPolicy guards the network perimeter; Istio guards inter-service communication.

#The Istio CNI Plugin

#Why Istio Has a CNI

Without the CNI plugin, Istio uses the istio-init init-container to install iptables rules that redirect Pod traffic to the sidecar. The problem: the init-container requires NET_ADMIN and NET_RAW capabilities on every Pod — a security risk and a blocker for clusters that forbid those capabilities.

The Istio CNI plugin moves this work to a daemonSet running as root on the node. It installs iptables in a Pod's network namespace when the Pod is created, so Pods no longer need elevated privileges:

istioctl install --set components.cni.enabled=true --set values.cni.cniBinDir=/opt/cni/bin --set values.cni.cniConfDir=/etc/cni/net.d

components.cni.enabled=true enables the CNI plugin. The istio-cni-node daemonSet then handles installing iptables on each node automatically.

#How It Works

The flow: kubelet calls the CNI plugin when a Pod is created; the istio-cni-node plugin installs iptables rules to capture the Pod's traffic to the sidecar port 15001; application traffic is then redirected to Envoy. Because the installation happens at the node level, application containers need no special network capabilities.

#CNI Implications for the Sidecar Lifecycle

#Without CNI

Without the CNI plugin, the lifecycle order is: istio-init (sets up iptables) → application → istio-proxy running. istio-init must finish before any other container starts.

#With CNI

With CNI, the iptables installation happens at the node level, not inside the Pod. The sidecar and application still run as ordinary containers without privileges. The important differences:

• Pods no longer use the istio-init init-container.
• There are no NET_ADMIN capabilities at the Pod level.
• The option --set values.global.proxy.privileged=false can be used more safely.
• Restarting the CNI daemonSet can affect new mesh traffic — monitor your nodes as a whole.

The iptables rules installed by the plugin still redirect Pod traffic to port 15001, where Envoy listens — it is just that the installation no longer requires a special container inside the Pod.

Verify that CNI is active and Pods are not using an init-container:

kubectl get pods -n istio-system -l k8s-app=istio-cni-node
kubectl get pod productpage-abc123 -o jsonpath="{.spec.initContainers}"

The second output shows an empty array if CNI is active — there is no istio-init. Instead, the iptables configuration is installed by the plugin on the node.

#Summary

Episode 13 clarified the role of the two network layers: NetworkPolicy controls IP-based networking and complements, rather than replaces, mesh policies; while the Istio CNI plugin changes how traffic is redirected to the sidecar by moving iptables installation from an init-container to a node-level daemonSet.

Key takeaways:

• NetworkPolicy works at the IP and port level and does not understand application identity.
• NetworkPolicy and Istio complement each other: network perimeter and service communication.
• The istio-init init-container needs NET_ADMIN; the CNI plugin does not.
• Istio CNI installs iptables on nodes via the istio-cni-node daemonSet.
• CNI removes the init-container and makes non-privileged Pod policies easier.
• Old workloads must be restarted after CNI is enabled.
• CNI helps meet strict cluster security requirements.

In the next episode, episode 14, we will measure and speed up the mesh: performance tuning and scalability — scaling istiod, reducing xDS churn, sizing sidecar resources, and tuning connection pools and the TCP versus HTTP path.