SafeOps Academy

Chapter 05: Network Policies (Production Isolation)

Chapter 05: Network Policies (Production Isolation)

Why This Chapter Exists

Without network isolation, one compromised pod can move laterally across environments. This chapter introduces a safe baseline:

  • default deny
  • explicit allow rules
  • DNS and ingress paths opened intentionally

The Incident Hook

A debug pod in develop reaches internal services it should never touch. No exploit sophistication is needed, only open east-west traffic. When incident starts, responders cannot quickly prove or limit blast radius. Network policies turn this into an auditable allowlist model.

What AI Would Propose (Brave Junior)

  • “Skip policies for now to avoid breaking traffic.”
  • “We can secure networking later after release.”

Why This Is Dangerous

  • Flat networking means high lateral-movement risk.
  • Production and non-production boundaries become weak.
  • Incidents are harder to contain under pressure.

Guardrails

  • Start from default deny in target namespace.
  • Add minimum allow rules one by one with verification.
  • Keep policy changes isolated from application changes.
  • Keep rollback manifest ready before applying restrictive policies.

Repo Mapping

  • Namespace manifests: flux/bootstrap/infrastructure/base/namespaces.yaml
  • App namespaces used in this repo: develop, staging, production
  • Ingress usage: flux/apps/backend/base/ingress.yaml, flux/apps/frontend/base/ingress.yaml
  • NetworkPolicy manifests: flux/infrastructure/network-policies/base/
  • Flux wiring: flux/bootstrap/flux-system/infrastructure.yaml, flux/bootstrap/flux-system/apps.yaml

Lab Files

  • lab.md
  • quiz.md

Done When

  • learner can apply default deny without losing control of the environment
  • learner can allow only required DNS + ingress traffic
  • learner can debug and explain blocked traffic with evidence

Lab: Default Deny and Controlled Traffic Allowlist

Lab: Default Deny and Controlled Traffic Allowlist

Goal

Build namespace isolation in develop:

  • deny all ingress/egress by default
  • allow DNS egress
  • allow ingress only from ingress controller namespace
  • validate blocked and allowed traffic paths

Prerequisites

  • cluster CNI supports NetworkPolicy
  • access to namespace develop
  • ingress controller namespace identified (commonly ingress-nginx)

Quick checks:

kubectl get ns
kubectl api-resources | rg -i networkpolicies
kubectl -n flux-system get kustomization network-policies-develop network-policies-staging network-policies-production

Set namespace variables:

Quiz: Chapter 05 (Network Policies)

Quiz: Chapter 05 (Network Policies)

Questions

  1. Why is default deny a safer starting point than allow-all networking?

  2. What two policy types are usually set for full baseline isolation?

  3. After applying default deny, DNS fails. What is the minimal next policy you should add?

  4. Which statement is correct?

  • A) Network policies are optional in production if pods are trusted.
  • B) Network policies reduce lateral movement by enforcing explicit traffic allow rules.
  • C) One broad allow policy is enough for all namespaces.

  1. Why is it risky to merge network policy changes together with app rollout changes?