Skip to main content
Before diving into Kubernetes NetworkPolicies, let’s align on core networking and security concepts using a simple three-tier application:
  • A user sends an HTTP request to the web server (front end) on port 80.
  • The web server calls the API server (back end) on port 5000.
  • The API server queries the database on port 3306 and returns results back through the chain.
Important: there are two traffic directions for any pod:
  • Ingress — traffic arriving at the pod (for example, a user request to the web server).
  • Egress — traffic that originates from the pod (for example, the web server calling the API).
Always determine ingress/egress based on where the traffic originated. Response packets do not change the original direction classification.
An infographic titled "Traffic" that lists numbered ingress and egress rules with port numbers (e.g., 80, 5000, 3306) and colored arrows. The arrows connect each rule to icons representing the internet, an API, and a database.
Mapping the example flow to concrete allow rules: For this flow to work when using NetworkPolicies you must explicitly allow each of the above directions (ingress on the recipient, and egress on the origin) if you are locking down traffic. Kubernetes cluster networking basics:
  • Each node, pod, and Service has an IP address.
  • The CNI (Container Network Interface) must enable pod-to-pod connectivity across nodes without manual routing.
  • By default, Kubernetes permits all pod-to-pod and pod-to-Service traffic (an “all-allow” baseline). NetworkPolicy resources allow you to restrict that default.
A diagram titled "Network Security" showing three nodes with colored pod icons and IP addresses connected by dashed lines to illustrate inter-pod networking. Each node lists a host IP (192.168.1.11, .12, .13) and several pod IPs in the 10.244.x.x range.
Why use NetworkPolicy?
  • Enforce least privilege between workloads (for example, prevent frontend pods from talking directly to DB pods).
  • Reduce attack surface by limiting which peers and ports can access a pod.
  • Split trust boundaries between namespaces and services.
NetworkPolicy fundamentals
  • Resource type: NetworkPolicy (namespaced).
  • Targeting: uses spec.podSelector to pick which pods the policy applies to.
  • Policy types: set spec.policyTypes to control Ingress, Egress, or both.
  • Rules: use spec.ingress and/or spec.egress to define allowed sources/destinations and ports.
  • Peers: specify allowed peers by podSelector, namespaceSelector, or ipBlock within each rule.
Key points:
  • If a NetworkPolicy selects a pod and declares Ingress rules, any ingress not explicitly allowed by that policy is denied (default deny for ingress). Egress remains unaffected unless Egress rules exist or another policy controls egress for that pod.
  • Policies are additive: multiple policies selecting the same pod combine to form the union of allowed traffic.
  • NetworkPolicy resources only express allowed traffic — they are allow-lists, not deny-lists.
A visual example: allow only the API pod to connect to DB pod on TCP port 3306.
A stylized diagram titled "Network Policy" showing a DB Pod inside a pentagon that represents the policy boundary. It indicates ingress is allowed from an API Pod on port 3306, shown by a dashed line labeled "3306."
Practical example
  • Use pod labels to target pods (for example role: db for database pods and name: api-pod for API pods).
  • Use policyTypes to indicate which directions the policy governs.
Complete NetworkPolicy YAML that allows only pods labeled name: api-pod to connect to pods labeled role: db on TCP port 3306:
Save the manifest (for example db-policy.yaml) and apply it:
Notes about enforcement and CNI support:
NetworkPolicies are enforced by the cluster CNI plugin. Creating a NetworkPolicy resource only defines desired rules — your CNI must implement enforcement for the policy to take effect.
Not every CNI supports NetworkPolicy enforcement. CNIs commonly supporting NetworkPolicy include Calico, Cilium, Kube-router, Romana, and Weave Net. A basic Flannel setup, for example, may not enforce NetworkPolicies. Always consult your CNI provider documentation for current support details.
Quick reference tables NetworkPolicy common fields CNI enforcement examples Additional reminders
  • NetworkPolicy objects are namespaced and affect only pods in their namespace unless you use namespaceSelector.
  • You may create NetworkPolicy objects on clusters whose CNI does not enforce them; Kubernetes will accept the resources but no enforcement will occur. Always test connectivity after applying policies.
  • Policies are additive: multiple policies can apply to the same pod and combine to form allowed traffic.
Further reading and references Try applying the example policy in a test namespace and verify connectivity with simple curl or tcp checks between pods to observe the policy behavior.

Watch Video