# Guided Exercise: Planning Egress Restriction

Paper-and-thinking exercise before the Labs.

## The scenario

A `payment-processor` Pod handles sensitive transactions. It legitimately needs to reach:
- an internal `payments-db` Service, and
- one external payment gateway API.

It should NOT be able to reach anything else — including the public internet in general, other
internal services, or any other namespace.

## Your task

1. Why is restricting this Pod's OUTBOUND (egress) traffic just as important as restricting who
   can reach IT (ingress), given what this Pod handles?
2. If this Pod were compromised via a vulnerable dependency, what would UNRESTRICTED egress let
   an attacker do that restricted egress would prevent?
3. Sketch (in words) what an egress policy for this Pod needs to allow, and — just as
   important — what it must NOT allow by omission.
4. Why might a security review flag a Pod with `policyTypes: ["Egress"]` but an EMPTY `egress`
   list as suspicious, rather than assume it's simply "not configured yet"?

## A worked answer to check yourself against

1. A Pod handling sensitive data that's compromised is far more dangerous if it can freely
   exfiltrate that data anywhere (unrestricted egress) than if its only reachable destinations
   are pre-approved and narrow.
2. Unrestricted egress would let an attacker exfiltrate transaction data to an external server,
   or download additional malicious tooling. Restricted egress limits it to only the
   pre-approved destinations, even after compromise.
3. Allow: egress to `payments-db` (internal, by label/namespace selector) and the specific
   external payment gateway (by IP range or, if supported, a domain-based egress rule). Must NOT
   allow: general internet access, other internal Services, or any other namespace by default.
4. An empty `egress` list under `policyTypes: ["Egress"]` means DENY ALL outbound — exactly like
   the ingress case from the lesson. A reviewer seeing this should confirm it's intentional
   (a Pod that genuinely needs zero outbound network access) rather than assume it's an
   oversight, since the two look identical in the YAML.

## Instructor Notes

**Facilitation:** Question 4 reinforces the same "empty rules list means deny-all, not
unconfigured" point from earlier lessons — a good moment to confirm it generalizes correctly to
egress, not just ingress.

**Approximate timing:** 10-12 minutes live with discussion; 10 minutes self-paced.

**Optional extension:** ask what additional control (beyond NetworkPolicy) a team might want for
truly sensitive egress, like restricting DNS resolution itself for this Pod — a forward pointer
to defense-in-depth without requiring a hands-on Lab here.