Core Track Guardrails-first chapter in core learning path.

Estimated Time

  • Reading: 20-25 min
  • Lab: 45-60 min
  • Quiz: 10-15 min

Prerequisites

Source Code References

  • allow-backend-ingress.yaml Members
  • allow-dns-egress.yaml Members

Sign in to view source code.

What You Will Produce

A reproducible lab result plus quiz verification and incident-safe operating evidence.

Investigation

Start with the boundary, not with ad-hoc firewall guesses.

Safe investigation sequence:

  1. Map the flow: List the source pod, target service, namespace, and port involved.
  2. Prove exposure: Use curl or nc from within the pod to prove what traffic is currently open.
  3. Define requirements: Define the minimum required paths: DNS, Ingress, and specific Egress targets.
  4. Test one by one: Test each allow rule individually against a default-deny baseline.

Containment

Containment narrows traffic fast by shifting to an opt-in model.

Containment steps:

  1. Apply Default Deny: Apply a namespace-wide default-deny-all policy.
  2. Enable DNS: Add back the DNS egress path (port 53) so pods can resolve names.
  3. Enable Ingress: Open the Ingress path from your controller (e.g., Traefik).
  4. Allow Specific Egress: Add rules for only the exact external services the workload truly needs.

The goal is not “network works somehow”; the goal is “network is explainable.”


Pause and Predict: What automated guardrail would have prevented this incident entirely?