DevOps Professional · Module 5: Hybrid networks and hard integrations
Restricted Egress: Choosing What May Leave
Outbound traffic deserves the same design as inbound. Default-open egress lets any compromised pod phone anywhere; an allowlist of required flows with tested denials turns exfiltration from trivial into noisy and difficult.
10 min reading
Objectives
- Explain why egress defaults open and why sensitive systems close it
- Build a fixture allowlist of required external flows and enforce it
- Test each allowed flow and quote denials for the rest
- Review the allowlist on schedule so exceptions do not fossilize
Why this matters
A compromised test pod mines cryptocurrency for a week, egressing to pools nobody allow-listed because egress was never listed at all. Discovery comes from the cloud bill, not from any control. Unrestricted egress makes every breach a potential exfiltration channel and every dependency a silent one. The allowlist does not need to be perfect to matter: required flows pass, everything else logs and drops, and the first anomalous flow pages instead of billing.
Concepts
Default-open is the starting posture everywhere: pods reach the internet unless something stops them. Closing it means enumerating required external flows (package registries, APIs, DNS, NTP) with destinations and ports, then enforcing the list at the checkpoint (egress proxy, policy engine, firewall) with default deny. DNS egress returns as a requirement: name resolution must work for allowed flows, and DNS logs become a detection source for the denied ones.
Fixture allowlists teach the mechanics safely. The L63 lab tests required flows against a fixture list inside lab bounds: allowed flows connect with quoted success, unlisted destinations drop with quoted denials, and no real third-party target is ever touched. Real allowlists add change control (new flow needs a request with a reason and an owner), expiry (temporary flows die on schedule), and monitoring (denied-flow logs reviewed, anomaly alerts on new patterns).
Breakage is expected and diagnosable. A new dependency fails closed with a denial naming the missing flow; the fix is a reviewed allowlist addition, not a hole punched in panic. Applications that cannot declare their external dependencies are the finding: unknown egress is unreviewed supply chain, and the allowlist forces the declaration.
Worked example
A fixture namespace starts open: a test pod reaches an unlisted destination, quoted as the baseline fault. The allowlist lands with three required flows; the same pod now reaches the three (quoted) and drops the fourth (quoted denial with the rule). A fourth flow request arrives mid-lab and goes through the request-owner-expiry path.
Common wrong move
Allow-listing by IP ranges copied from a vendor page and never revisited. Ranges change, lists rot, and the fossilized exception quietly permits what the original request never covered. Owners, expiry, review, or the list is decoration.
Quick check
An optional 4-question self-check. Answers never leave your device, are not stored, and never count toward any assessment.
Lesson feedback
No published feedback yet.
Log in and complete the lesson to leave feedback.
Exercise
Enforce a fixture egress allowlist on a lab namespace, quote allowed flows succeeding and unlisted ones denied, and process one new flow request properly.
Pass criteria
The record shows the baseline open fault, the enforced list with quoted allow/deny results, and the reviewed new-flow decision.