Lesson 0002 · 20 minutes

NetworkPolicy: prove what is denied

Using documentation is a strength, not a weakness. In CKS and in real operations, the differentiator is proving that a policy has the intended effect—not merely applying YAML without errors.

Confidence move: after every security change, state one traffic flow that must work and one that must fail. Then test both.

The verification sequence

Confirm selection. kubectl get pods -n payments --show-labels. A correct rule selecting the wrong labels does nothing useful.
Confirm policy type and direction. Read spec.policyTypes: ingress and egress are independent. An isolated pod may need explicit DNS egress.
Test the allow path. From an app=api pod, connect to the database Service on TCP 5432.
Test the deny path. From a deliberately different-labelled pod in the same namespace, repeat the identical connection.
Check enforcement assumptions. NetworkPolicy only works when the installed CNI supports and enforces it.

These mechanics are grounded in the official NetworkPolicy documentation. It explicitly warns that behavior depends on the networking solution.

Retrieval check

Scenario

A policy selects app=db and has an ingress rule permitting app=api to TCP 5432. The API pod still cannot resolve db.payments.svc.cluster.local after you add an egress-isolating policy to it. What did you most likely omit?

A RoleBinding for the API ServiceAccount An egress allowance to cluster DNS on port 53 A restricted Pod Security Admission label An audit-policy rule for DNS queries

Timed drill: build a test matrix (12 minutes)

For the policy you wrote in Lesson 1, make this table in a note before touching the cluster. Then run every row your lab permits.

Source	Destination	Expected
`app=api`	`app=db:5432`	allowed
other labelled pod	`app=db:5432`	denied
`app=api`	cluster DNS :53	allowed if egress isolated

Write one command you used to test each row and record any mismatch. Then ask me with the result; I’ll help you diagnose it, as you would in a security incident.