Kubernetes Network Policies are the firewall of the cluster. They decide which Pods can talk to which, and which connections are blocked. Without them, every Pod can reach every other Pod, giving attackers or broken services a freeway to spread.
Many teams deploy policies but never test them. They trust yaml on paper. This is where socat becomes a dangerous and useful tool. Socat is a small CLI utility that can connect TCP, UDP, and UNIX sockets in almost any way you want. In a Kubernetes cluster, it can turn a Pod into a network probe.
Run two Pods. One as a listener:
kubectl run listener --image=alpine/socat:1.7.4.4 --restart=Never -- \
tcp-listen:8080,fork
Then a client:
kubectl run connector --image=alpine/socat:1.7.4.4 --restart=Never -- \
tcp:listener:8080
If the connection succeeds, your NetworkPolicy allowed it. If it fails, it’s blocked. No guessing. No hoping that selectors match. It’s binary truth.
Complex clusters often have dozens of namespaces and hundreds of policies. Without live verification, you risk assuming isolation that doesn’t exist. Socat tests against reality. It’s fast, stateless, and leaves no service footprint. You can script it to check every path you think is blocked.
For debugging, reverse it and try UDP. Change ports. Run checks at network ingress points. You’ll see exactly how traffic flows. Pair socat tests with your CI pipeline to reject cluster changes that break isolation or compliance.
Network security in Kubernetes is only as strong as the last thing you tested. YAML reviews are not enough. Socat gives you proof, and proof closes the gap between what you think your Network Policies do and what they actually do.
You can script these checks yourself. Or you can see it running in minutes, with real-time visibility and zero setup, at hoop.dev.