World map

 

BM

World K6: Guards

NetworkPolicies recap

You will learn: to fence a database so only the pods that need it can reach it.

Checked with Kubernetes 1.37 on 31 Oct 2026

The problem

The gates stop strangers at the door. But inside, any tray can talk to the database. A thief gets into the web pod. Then what?

Watch

Recap from World K3: a NetworkPolicy is a fence between stalls. This one lets the entrance in. Break it: forget the entrance. Then send.

Break one hop so the user gets: a timeout.

  1. BrowserGET /api/menu on port 80
  2. Gateway (entrance)entrance listens on :80
  3. HTTPRoute (signboard)/api → api:80
  4. Service (order number)api: port 80 → 3000
  5. EndpointSlice (ready trays)1 ready of 1
  6. Pod (tray)api-7d4f9-x2kq4 listens on :3000
Break something

Try it

This fence will not apply. Fix the line the API server does not know.

Fix the manifest, then press Apply.

db-from-api.yaml13 lines

Try it

Fence the database for real. Apply the deny-all fence. Then open a gate for api only.

You are here: cluster kind-dev namespace default
  • db1/1 ready
dev-control-planeOpenManager

No trays here.

dev-workerOpen
  • db·vq5t2
  • stranger
dev-worker2Open
  • api
Time: +0s (sped up)

Predict

Your cluster’s network plugin ignores NetworkPolicies. You apply deny-all. What happens?

Check

Good fence habit, or risky? Swipe each one.

Swipe right for good, left for needs work. Or use the buttons.

1 / 4

Start each zone with deny-all, then open small gates

You did it!

You can now fence a database with NetworkPolicies.

Go deeper (optional)

policyTypes: [Egress] fences what goes out. namespaceSelector lets a whole zone through. Plugins like Cilium and Calico enforce policies. Check your plugin’s docs before you trust a fence.

Real mission

  2. kubectl apply -n fence-test -f deny.yaml

0 of 4 steps done · Your ticks are saved.