Chapter 06: Network Policies (Production Isolation)
Learning Objectives
By the end of this chapter, you will be able to:
- Explain what NetworkPolicies protect: how far one compromised or misused pod can reach, and why a flat network makes every pod as dangerous as the most exposed one
- Read the platform’s policies and prove with a probe which connections they allow and which they block - telling a blocked connection from a failed name lookup
- Write an allow rule for one connection: the right pods on both ends, the right direction, the right port
- Explain why policies only add allowances - and why one “allow everything” policy undoes every other rule
Recall Check
Before continuing, quickly recall:
- Who may write to
develop, and who may only readproduction? (Chapter 01) - What does Flux do with a NetworkPolicy someone deleted by hand? (Chapter 03)
- Where does a change to a shared
basefolder land - in one environment, or in all of them? (Chapter 03)
If you can’t answer these, revisit the corresponding chapter before proceeding.
Context
Chapter 01 limited what a person may do in each namespace. This chapter limits what a pod may reach. Without a NetworkPolicy, every pod in a Kubernetes cluster can open a connection to every other pod, in every namespace: the frontend to the production database, a load-test tool in develop to Postgres in production, a debugging container to anything with an open port. The network is flat.
That matters on the day something goes wrong in one pod - and that day comes:
- A mistake travels. A test run in
developwith the production database’s address copied into its config writes test data into production. Nothing stopped it but luck. - A compromise travels. A vulnerability in one application lets an attacker run code in its pod. On a flat network, that pod is a door to every database and internal API in the cluster.
- Data leaves. A pod that may connect anywhere may also send anything anywhere - to any address on the internet.
NetworkPolicies turn the flat network into the paths the platform actually uses. In each environment (develop, staging, production) the default is nothing, and every allowed connection is written down: the frontend may call the backend on 8080; the backend may call its own database on 5432; nothing may call the database of another environment. The policies are also the platform’s map of who talks to whom - reviewed in Git like everything else.
They have a cost, and the chapter does not hide it: a missing rule breaks a working path, and a policy has to be read, not guessed. But a blocked connection is a visible failure in one place, found with a probe. A connection that should never have been possible is invisible - until the day it is used.
Work through each lesson section; the chapter video, once it is published, gives the concept overview.
From a Flat Network to Written-Down Paths
