Smoke was still clearing from the failed deployment when the team realized the blast radius was wider than expected. Pods were talking to each other they shouldn’t. Data had moved where it was never meant to go. This is why Kubernetes Network Policies must be part of every incident response plan.
Network Policies in Kubernetes control how pods communicate with each other and with external endpoints. During an incident, tight network rules can limit damage, isolate affected workloads, and stop lateral movement. Without them, a single compromised pod can freely scan and connect to others, making containment nearly impossible.
The first step in incident response with Kubernetes Network Policies is identification. Map which pods were involved, what namespaces they belong to, and which services they interacted with. Use native Kubernetes commands like kubectl get networkpolicy to confirm active rules. Log inspection from tools like Fluentd or Loki will reveal whether traffic was blocked or allowed during the incident window.
Next comes containment. Create or update Network Policies to immediately block all ingress and egress traffic to the identified pods, except where absolutely required. Apply namespace-level policies to prevent cross-namespace traffic that can spread an attack. Review default rules—remember that no policies means all traffic is allowed.