Kubernetes network policy: how it works, examples, and best practices

A Kubernetes network policy (the NetworkPolicy API object) is a namespaced resource that controls which pods can send traffic to, and receive traffic from, other pods, namespaces, and IP ranges at layers 3 and 4. By default, every pod can reach every other pod, so one compromised container can scan and pivot across namespaces. NetworkPolicy limits that lateral movement, enforces least privilege between services, and stops accidental calls, such as staging reaching production. This guide is current as of October 2026 and covers evaluation, YAML for DNS, databases and cloud metadata, testing, troubleshooting, and safe rollout.

How Kubernetes network policy works

A policy selects pods by label and attaches allow rules for ingress (incoming) and egress (outgoing) traffic, which the CNI plugin turns into packet filters. The API server stores policies but does not enforce them. On plain Flannel, policies apply with no effect. Calico, Cilium, Antrea, and Weave Net enforce them, and managed services usually need enforcement switched on:

• EKS: the network policy option in the Amazon VPC CNI
• GKE: network policy enforcement or Dataplane V2
• AKS: Azure NPM, Calico, or Cilium

The four building blocks

• podSelector: the pods in the policy’s namespace it applies to. {} selects all of them.
• policyTypes: Ingress, Egress, or both. If you omit it, Ingress is assumed, and Egress is added only when egress rules exist.
• ingress.from / egress.to: allowed peers, defined with podSelector, namespaceSelector, or ipBlock.
• ports: optional protocol (TCP, UDP, SCTP) and port restrictions.

Where you place a selector changes what a rule means. When namespaceSelector and podSelector sit in the same list element, both must match (AND), giving “pods labelled X in namespaces labelled Y”. In separate elements, either can match (OR), so one misplaced dash can open a rule to every pod in a namespace. A podSelector on its own matches pods in the policy’s namespace only.

The standard API has no deny rules, so you select pods to isolate them and then add allows. This is microsegmentation in Kubernetes environments written as YAML.

Kubernetes network policy examples

Start from a default deny and add a narrow allow for each real dependency. All examples use a namespace called shop. More patterns live in the community NetworkPolicy example repository.

Default deny ingress and egress

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: shop
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

The empty podSelector selects every pod in shop, and with no rules listed, nothing is allowed. Many teams apply an ingress-only version first, because egress deny breaks DNS and outbound calls until allows exist.

Allow DNS egress

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-egress
  namespace: shop
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53
    - protocol: TCP
      port: 53

This AND selector allows only CoreDNS pods in kube-system on port 53. TCP matters because large responses fall back to TCP. Kubernetes sets the kubernetes.io/metadata.name label on every namespace automatically.

Allow frontend to backend on one port

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend-8080
  namespace: shop
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

Allow external database egress and block cloud metadata

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend-to-db
  namespace: shop
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 10.20.0.0/24
    ports:
    - protocol: TCP
      port: 5432

Only this managed PostgreSQL subnet is allowed, so 169.254.169.254 stays blocked. That address is the instance metadata service, which attackers use to steal node credentials. For broad internet egress, use cidr: 0.0.0.0/0 with except: [169.254.169.254/32]. API server egress works the same way. Add an ipBlock for its endpoint IP on 443 or 6443.

What each policy allows and blocks

Kubernetes network policy tutorial: apply, verify, and migrate

To create and apply a policy, write the YAML, apply it with kubectl, and prove the result with real connections, following the flow in the CKS network policy lesson:

1. Confirm labels: kubectl get pods -n shop --show-labels and kubectl get ns --show-labels.
2. Apply the policy: kubectl apply -f allow-frontend-to-backend.yaml.
3. Inspect it: kubectl describe networkpolicy allow-frontend-to-backend-8080 -n shop.
4. Test the allowed path: kubectl run t --rm -it -n shop --labels app=frontend --image=nicolaka/netshoot -- curl -m 3 backend:8080.
5. Test a blocked path from a pod with another label: nc -zv -w 3 backend 8080 should time out.
6. After egress changes, run nslookup kubernetes.default inside a pod.

Troubleshooting Kubernetes network policy

Most failures come from a CNI that is not enforcing policies, mismatched labels, or a missing DNS allow. Check in this order:

1. Enforcement: apply a deny-all in a test namespace. If traffic still flows, enforcement is off.
2. Labels: a typo such as app: front-end makes a policy select nothing.
3. policyTypes: an egress policy without Egress listed may be read as ingress-only.
4. DNS: if a service name fails but its IP works, the port 53 allow is missing.
5. Selectors: check the AND/OR dashes in from and to.
6. ipBlock: use it for cluster-external IPs, because pod IPs change and load balancers can rewrite source IPs.
7. Packets: run tcpdump in a netshoot pod, or hubble observe --verdict DROPPED on Cilium.

Best practices for production Kubernetes network policy

Production clusters work best with a default-deny baseline and small, named, version-controlled allows:

• ✓Apply default deny to every application namespace, ingress first and egress second.
• ✓Scope each allow to one source, one destination, and specific ports, named allow-<source>-to-<dest>-<port>.
• ✓Allow DNS and observability explicitly: Prometheus scraping, log shippers, and the ingress controller’s namespace.
• ✓Enforce label hygiene with admission policies so selectors stay reliable.
• ✓Store policies in Git, deploy through GitOps, and test in CI with kubectl apply --dry-run=server and test pods.

Isolate whole namespaces (podSelector: {} as the ingress peer) when they map to tenants or environments. Select individual pods when one namespace mixes a payment API with low-risk workloads.

How Upwind supports Kubernetes network segmentation

Upwind shows which workloads actually run and which are actually exposed, so you know which namespaces to lock down first. Its lightweight eBPF sensors collect runtime evidence across Kubernetes, APIs, and cloud workloads, so NetworkPolicy work connects to your wider cloud network security posture. Teams that only need to lint NetworkPolicy YAML for a single cluster may find a full CNAPP more than they need.

• ✓Shows which vulnerabilities are loaded and reachable inside running pods.
• ✓Detects and responds when traffic patterns turn into active threats.
• ✓Agentic Pack AI agents investigate threats, validate exposure, and generate fixes.

A solid Kubernetes network policy setup combines default deny, explicit DNS and dependency allows, verified labels, and tested rollouts. Together they turn a flat cluster network into segments that contain a breach.

FAQ