NetworkPolicies and Pod-to-Pod Isolation

The Default Is Wide Open

A fresh Kubernetes cluster is a flat network. Every pod can reach every other pod, in every namespace. Your public-facing frontend can open a connection directly to the database. A compromised sidecar in one namespace can scan every service in the cluster.

This is a deliberate default — it makes things work out of the box — and it's rarely what you want past the first week. NetworkPolicy is how you restrict it.

The Model: Additive and Allow-Only

The logic is easy to get backwards, so state it carefully:

1. NetworkPolicies only allow traffic. There is no deny rule.
2. A pod is unrestricted until at least one policy selects it for a given direction.
3. Once selected for a direction, that pod becomes default-deny for that direction, and only explicitly allowed traffic passes.
4. Multiple policies selecting the same pod are additive — the union of what they permit.

Point 3 is the mechanism everything else builds on. You don't write a deny rule; you make a pod subject to policy, and denial becomes the baseline.

Establishing a Default-Deny Baseline

The idiom is a policy that selects every pod and permits nothing:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}          # {} selects EVERY pod in the namespace
  policyTypes:
    - Ingress
    - Egress

An empty podSelector matches all pods; listing both policyTypes with no rules means nothing is allowed in either direction. From here you open specific paths.

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

Opening Specific Paths

Let the API reach the database, and nothing else:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-allow-api
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: postgres        # this policy protects the database pods
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: api     # only pods labelled app=api
        - podSelector:
            matchLabels:
              app: worker
      ports:
        - protocol: TCP
          port: 5432

Three selector types are available in from / to:

- podSelector: { matchLabels: { app: api } }        # pods in THIS namespace
- namespaceSelector: { matchLabels: { env: prod } } # all pods in matching namespaces
- ipBlock:                                          # CIDR, for outside the cluster
    cidr: 10.0.0.0/8
    except: [10.0.5.0/24]

from:
  - podSelector: { matchLabels: { app: api } }
  - namespaceSelector: { matchLabels: { env: prod } }

from:
  - podSelector: { matchLabels: { app: api } }
    namespaceSelector: { matchLabels: { env: prod } }

The Gotcha That Wastes the Most Time

NetworkPolicy is enforced by the CNI plugin, not by Kubernetes itself.

The API server will happily accept, store and display your policy. kubectl get networkpolicy lists it. kubectl describe shows the rules. Everything looks correct.

And if your CNI plugin doesn't implement NetworkPolicy, none of it does anything. Flannel, in its default configuration, is the classic example. Calico, Cilium and most managed-cluster CNIs do enforce.

Verifying Enforcement

Test from a pod that should be blocked:

# Should FAIL once the policy is enforced
kubectl run probe --rm -it --image=busybox --restart=Never -n production \
  -- wget -qO- --timeout=3 http://postgres:5432
 
# Should SUCCEED — a pod with the allowed label
kubectl run probe --rm -it --image=busybox --restart=Never -n production \
  --labels="app=api" -- nc -zv postgres 5432

The first command timing out is your proof. If it connects, your policy isn't being enforced regardless of what kubectl get shows.

A Practical Adoption Path

Going straight to default-deny across a live cluster breaks things you didn't know were connected. A workable sequence:

1. Confirm your CNI enforces policy. Test it before writing anything else.
2. Map actual traffic. Service mesh telemetry or CNI flow logs show what really talks to what — reliably more than the architecture diagram does.
3. Protect the highest-value target first. An ingress policy on the database, allowing only the services that genuinely need it.
4. Add default-deny ingress per namespace, then open the paths your mapping revealed.
5. Add default-deny egress last, with DNS allowed from the start. Egress is where surprises live — metrics endpoints, external APIs, webhooks.
6. Test each step with a pod that should be blocked.

What's Next

Traffic is routed and restricted. Phase 4 covers workloads that remember — persistent storage, StatefulSets, and the resource requests and limits that decide whether your pod gets scheduled at all or quietly OOM-killed.