## TL;DR
Kubernetes lets all pods talk to all pods by default. NetworkPolicies fix that: write policies that allow only the traffic each app needs and deny the rest. Start with a default-deny in each namespace, then add allow rules for DNS, ingress, and app-to-app calls. Test in audit mode before enforcing.

## The query
```
how to configure Kubernetes network policies
```

## Use this when
- You want to limit blast radius so one compromised pod cannot scan the cluster
- You need namespace isolation between teams or environments
- An audit flagged your cluster for flat networking with no policy
- You are setting up a new cluster and want segmentation from day one

## Not for
- Encrypting pod traffic; that is mTLS or a service mesh, not NetworkPolicy
- Clusters whose CNI does not enforce NetworkPolicy; check your CNI first
- Blocking egress to the internet at the firewall level; do that separately

## Steps
1. Confirm your CNI enforces NetworkPolicy. Calico, Cilium, and most managed CNIs do; some lightweight ones do not. Expected output: your CNI docs confirm policy enforcement is on.
2. Add a default-deny policy in each namespace. A policy selecting all pods with no ingress or egress rules drops everything by default. Expected output: pods can no longer reach each other across the namespace until allow rules land.
3. Allow DNS first. Add an egress rule to kube-dns on port 53 (UDP and TCP) so name resolution keeps working. Expected output: pods resolve service names again.
4. Add allow rules for real traffic. For each app, allow ingress from its callers (by pod selector or namespace) and egress to its dependencies and the API server if needed. Expected output: the app's health checks and dependencies pass with the policies applied.
5. Test with the app running. Exercise every flow, including cron jobs and background workers, and watch for dropped connections in CNI logs. Expected output: full app test suite passes, no unexpected drops.
6. Keep policies in git and review changes. NetworkPolicy is code; review it like code and re-verify after every deploy. Expected output: policy manifests live alongside the app manifests and get reviewed in PRs.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_1J-fDNmPoQV5rXIfg5UaSg