Guardrails That Stop It

• Default Deny Baseline: Every namespace starts with a block-all policy.
• Minimal Allowlist: Add only the required source/destination pairs.
• Isolated Changes: Change network policies separately from application code.
• Rollback Preparation: Keep a “known-good” manifest ready before applying restrictive policies.

Blocked Traffic Triage Playbook

When traffic is unexpectedly blocked:

1. Check DNS: Can the source pod resolve the target’s name?
2. Verify Labels: Do the source and target pod labels match the policy selectors?
3. Verify Namespaces: Ensure namespace labels are correct for namespaceSelector rules.
4. Protocol Check: Validate port and protocol (TCP/UDP) correctness.
5. IP Blocks: If using ipBlock, confirm the CIDR range covers the destination.

Safe Workflow (Step-by-Step)

1. Start in Develop: Apply the default-deny-all policy in the develop namespace.
2. Enable DNS: Permit egress to kube-dns on port 53.
3. Open Ingress: Allow traffic from the traefik namespace to your app.
4. Test & Verify: Run smoke tests from the Frontend to the Backend.
5. Promote: Once validated, promote the policies to staging and production via Flux overlays.

Common AI Trap

AI often suggests broad rules to “fix” connectivity quickly. Do not apply these shortcuts:

• ❌ 0.0.0.0/0 egress (too broad)
• ❌ Namespace-wide allow-all (removes isolation)
• ❌ Disabling the policy engine (unacceptable risk)

This builds on: CI/CD pipeline (Chapter 05) — policies are deployed through the same GitOps flow. This enables: Security context (Chapter 07) — pod hardening works within network boundaries.