Apply Kubernetes network policies

The fix

# Default-deny all ingress in a namespace — the foundation
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: orders
spec:
  podSelector: {}
  policyTypes: [Ingress]

Then add allow-policies for the traffic that should exist. Default-deny first, allow-specific second.

Why it matters

Kubernetes networking is flat by default: every pod can open a connection to every other pod, in every namespace, with nothing in the way. Your frontend can reach your database directly, one team’s workload can reach another’s, and — the part that matters for security — a single compromised pod can reach the entire cluster’s internal services.

That flat network is what turns one foothold into lateral movement. An attacker who compromises a low-value pod (a public-facing web app) can, with no further exploit, scan and connect to every internal service: databases, caches, the metadata endpoint, other apps’ APIs. Network policies are the segmentation that stops that — the pod can only reach what you explicitly allowed.

Default-deny is the foundation

A NetworkPolicy is allow-only and additive: policies grant traffic, and the moment any policy selects a pod, everything not allowed is denied for that pod. So the pattern is:

1. Default-deny ingress (and egress) in the namespace — a policy selecting all pods (podSelector: {}) that allows nothing.
2. Allow-specific policies layered on top — “the API pods may receive traffic from the frontend on port 8080.”

Without the default-deny, a namespace with a few allow-policies still lets unselected pods talk to anything. The deny-all is what flips the namespace from “allow by default” to “deny by default,” which is the posture you want.

Egress policies matter as much as ingress here: default-deny egress stops a compromised pod from reaching the metadata service, exfiltrating to the internet, or scanning internal ranges — often more valuable than ingress rules.

The CNI has to enforce it — check first

This is the trap that makes network policies silently useless: NetworkPolicy objects do nothing unless your CNI plugin enforces them. The API accepts the object, kubectl get networkpolicy shows it, and it has zero effect if the network plugin ignores it.

• Calico, Cilium, Antrea, Weave enforce them.
• Flannel does not — a very common CNI with no NetworkPolicy support.
• Some managed clusters need network policy explicitly enabled at creation.

So before writing policies, confirm the CNI enforces them, or you’re writing security theatre. The verify block below tests this directly.

DNS is the classic self-inflicted outage

A default-deny egress policy blocks DNS, because DNS is a pod-to-pod call to CoreDNS in kube-system. Every allow-egress policy needs to also permit DNS, or every pod in the namespace loses name resolution — which looks like everything breaking at once:

  egress:
    - to:
        - namespaceSelector:
            matchLabels: { kubernetes.io/metadata.name: kube-system }
      ports:
        - { protocol: UDP, port: 53 }
        - { protocol: TCP, port: 53 }

Forgetting this is the single most common network-policy mistake.

Verify it worked

First — does the CNI even enforce policies? Check what’s installed:

kubectl get pods -n kube-system -o wide | grep -iE 'calico|cilium|antrea|weave|flannel'

flannel alone means NetworkPolicy is not enforced. Then prove enforcement with a test: apply a default-deny and confirm traffic is actually blocked.

kubectl -n orders run probe --image=nicolaka/netshoot --restart=Never -- sleep 3600
# with default-deny applied, this should FAIL:
kubectl -n orders exec probe -- curl -s --max-time 5 http://some-service:80 -o /dev/null -w '%{http_code}\n'

A timeout means the policy is enforced. A 200 means the CNI is ignoring your policy — the finding.

Find namespaces with no default-deny — the unprotected ones:

for ns in $(kubectl get ns -o name | cut -d/ -f2); do
  n=$(kubectl -n "$ns" get networkpolicy -o name 2>/dev/null | wc -l)
  printf '%-24s policies: %s\n' "$ns" "$n"
done

policies: 0 on an application namespace is a flat, wide-open namespace.

Clean up the probe: kubectl -n orders delete pod probe.

Before you apply this

A default-deny policy breaks all traffic that isn’t explicitly allowed — the instant it’s applied. Unlike most changes here, this is immediate, not deferred to the next deploy, and it hits every pod the policy selects. Applied without the matching allow-policies, it takes the namespace’s applications offline.

The order that avoids the outage:

1. Map the real traffic first. What talks to what, on which ports. A service mesh or the CNI’s flow logs (Cilium’s Hubble, Calico’s flow logs) show actual connections; without them, work from the architecture and confirm on staging.
2. Write the allow-policies for that traffic — including DNS egress, which everything needs.
3. Apply default-deny last, in a namespace where you’ve staged and tested the allows.

Test in one namespace before rolling out. A default-deny in kube-system or a namespace running your ingress controller can break cluster networking or take all inbound traffic down. Start with a single, well-understood application namespace.

Egress default-deny is higher-value and higher-risk. It’s the one that stops exfiltration and metadata-service access, but it’s also the one that breaks DNS, external API calls, and pulling from external services. Adopt ingress default-deny first (lower blast radius), then egress once you’ve mapped what each workload legitimately calls out to.

On Flannel or a non-enforcing CNI, none of this protects anything — and believing it does is worse than knowing it doesn’t. If you need segmentation and your CNI can’t enforce it, the fix is a CNI change (or a service mesh), which is a cluster-level project, not a manifest.

Related

• Restrict privileged containers — reduces the compromise that lateral movement follows.
• Disable service account automount — the other thing a compromised pod would use.