Most teams invest heavily in locking down inbound traffic — ingress rules, service meshes, mutual TLS — while leaving outbound traffic largely uncontrolled. That oversight creates a significant attack surface: a compromised container can silently reach out to an adversary-controlled server, exfiltrate sensitive data, or retrieve a second-stage payload without triggering a single alert, because nothing was monitoring traffic in the outbound direction.
Zero-trust networking applies the principle of least privilege in both directions. The default answer to "can this pod initiate this connection?" is no — for both ingress and egress. This guide walks through implementing that model for egress using native Kubernetes NetworkPolicy objects: deny all outbound traffic by default, then explicitly allow only what each workload legitimately requires. No service mesh, no additional tooling — just declarative YAML you can apply to any compliant cluster today.
Prerequisite: CNI Enforcement
Before applying any NetworkPolicy manifest, verify that your CNI plugin actually enforces policy. This is the single most common source of confusion when getting started.
NetworkPolicy is a Kubernetes API abstraction, not an implementation. The API server will accept any well-formed policy object, but the policy has no effect unless the underlying CNI plugin is configured to enforce it. The default CNI on a standard kind cluster or many stock configurations does not enforce NetworkPolicy.
