Network Policy: Egress Control

Default-deny egress prevents data exfiltration.

Idea

The default in most Kubernetes clusters is that any pod can reach any external destination on the internet. This is convenient for development and catastrophic for security. A compromised pod can dial out to an attacker-controlled command-and-control server, exfiltrate data, or pull additional malware payloads. The fix is default-deny egress: pods cannot reach the internet unless they have explicit permission.

What default-deny egress actually means:

• Pods explicitly allow outbound.: The default network policy denies all egress from every pod. Each application that legitimately needs to make outbound calls declares the specific destinations it requires (host, port, protocol). The cluster only allows traffic that matches a declared rule.
• No default internet access.: A pod that does not declare any egress rules can talk to its in-cluster dependencies (other pods, the cluster DNS, the local cache) but cannot reach external services. The internet is opt-in, not opt-out. This is the inverse of the default Kubernetes behavior.
• Default is the security posture.: The most important security policy is the one that applies when nobody has thought about a workload. Default-deny egress means the unspecified workload is locked down, not exposed. The team has to explicitly grant network access for a new workload to function.
• Forces explicit dependency declarations.: Every external dependency a service has is now declared in source control as part of the network policy. The declarations document the service's actual runtime dependencies, which is information that often only existed in someone's head before.
• Surfaces unknown dependencies.: When applying default-deny to an existing workload, traffic that gets blocked is traffic the team did not know about. That is itself information: a service the workload was talking to that nobody documented. The discovery process is one of the first benefits of adoption.

Default-deny egress is one of the highest-impact, lowest-cost security investments a Kubernetes operator can make. The discipline is mostly about doing the migration carefully, not about novel technology.

Setup

The mechanism for default-deny egress is the Kubernetes NetworkPolicy resource (or its more sophisticated equivalents in Cilium, Calico, or service meshes). Setting it up is straightforward; doing the migration without breaking existing workloads is the operational work.

• NetworkPolicy with egress rules.: The Kubernetes NetworkPolicy resource declares both ingress (what can reach this pod) and egress (where this pod can reach). For default-deny egress, every namespace gets a default policy that denies all egress except for explicitly whitelisted destinations.
• Per-app destinations.: Each application's policy lists the destinations its code legitimately reaches: the API of the third-party SaaS it integrates with, the DNS resolver, internal services in other namespaces, the artifact registry, the metrics endpoint. The list is specific and reviewable.
• Whitelist destinations, not block-list.: The policy is allow-by-rule, deny-by-default. Block-listing specific bad destinations does not scale; an attacker can route through any unblocked destination. Whitelisting is the only defensible model.
• FQDN-based rules where supported.: Vanilla Kubernetes NetworkPolicy uses pod selectors and IP CIDRs; FQDN rules (api.stripe.com, *.amazonaws.com) require an extension like Cilium. FQDN rules are much more useful in practice because external services have variable IPs.
• Migration strategy.: Roll out default-deny in dry-run or audit mode first. The policy reports what would have been blocked without actually blocking. The team analyzes the audit log, identifies legitimate traffic that needs to be whitelisted, and only then enables enforcement. Skipping the dry-run produces an outage at the moment of enforcement.

The NetworkPolicy adoption is a multi-month project for an existing fleet. Done in stages with audit-then-enforce, it is straightforward and low-risk. Done as a big-bang migration, it produces an outage.

Benefit

The benefit of default-deny egress is that it changes the calculus of compromise. An attacker who lands in a pod no longer has the entire internet at their disposal; they have only the destinations that pod was allowed to reach. The blast radius of a compromise drops dramatically.

• Lateral movement bounded.: An attacker who compromised pod A cannot reach pod B unless A's network policy allowed it. The cluster topology becomes a graph that the attacker has to navigate, not an open mesh. Each compromise is contained to the destinations the compromised workload legitimately reached.
• Exfiltration cannot use the obvious paths.: The attacker cannot dial out to their command-and-control server, cannot push captured data to an attacker-controlled S3, cannot pull additional payloads from an attacker-controlled CDN. Every attempted external connection has to fit within the workload's declared egress rules. Most do not.
• Forces attackers to use specific destinations.: The attacker is constrained to the destinations the policy allows. If those destinations include an attacker-controlled service, the attack succeeds. But the attacker now has to pre-position infrastructure on a domain the workload reaches, which is a much higher bar than dialing out to anywhere.
• Detectable via volume anomalies.: Even allowed destinations have characteristic traffic patterns. A workload that normally sends 1 KB per minute to api.example.com but is now sending 1 GB is anomalous. The constrained set of destinations makes anomaly detection more effective because the baseline is tighter.
• Compliance-friendly.: Most regulatory frameworks (PCI DSS, HIPAA, SOC 2 in some contexts) explicitly recognize network segmentation as a control. Default-deny egress is the strongest implementation of segmentation in Kubernetes; it satisfies the control directly.

Default-deny egress is the network security posture that turns Kubernetes from a flat, internet-attached mesh into a structured, gated network. Nova AI Ops integrates with NetworkPolicy enforcement, audits the whitelist for over-permissive rules, and surfaces the egress traffic patterns so the security team can see whether the policy is being respected and where the exceptions are.