2 lines
3.9 KiB
HTML
2 lines
3.9 KiB
HTML
<!doctype html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width,initial-scale=1"><title>CKS lesson 2: verify NetworkPolicy</title><link rel="stylesheet" href="../assets/course.css"></head><body><main><p class="eyebrow">Lesson 0002 · 20 minutes</p><h1>NetworkPolicy: prove what is denied</h1><p class="lede">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.</p><div class="callout"><strong>Confidence move:</strong> after every security change, state one traffic flow that must work and one that must fail. Then test both.</div><h2>The verification sequence</h2><ol><li><strong>Confirm selection.</strong> <code>kubectl get pods -n payments --show-labels</code>. A correct rule selecting the wrong labels does nothing useful.</li><li><strong>Confirm policy type and direction.</strong> Read <code>spec.policyTypes</code>: ingress and egress are independent. An isolated pod may need explicit DNS egress.</li><li><strong>Test the allow path.</strong> From an <code>app=api</code> pod, connect to the database Service on TCP 5432.</li><li><strong>Test the deny path.</strong> From a deliberately different-labelled pod in the same namespace, repeat the identical connection.</li><li><strong>Check enforcement assumptions.</strong> NetworkPolicy only works when the installed CNI supports and enforces it.</li></ol><p>These mechanics are grounded in the official <a href="https://kubernetes.io/docs/concepts/services-networking/network-policies/">NetworkPolicy documentation</a>. It explicitly warns that behavior depends on the networking solution.</p><h2>Retrieval check</h2><div class="quiz"><h3>Scenario</h3><p>A policy selects <code>app=db</code> and has an ingress rule permitting <code>app=api</code> to TCP 5432. The API pod still cannot resolve <code>db.payments.svc.cluster.local</code> after you add an egress-isolating policy to it. What did you most likely omit?</p><label><input type="radio" name="q" value="rbac"> A RoleBinding for the API ServiceAccount</label><label><input type="radio" name="q" value="dns"> An egress allowance to cluster DNS on port 53</label><label><input type="radio" name="q" value="psa"> A restricted Pod Security Admission label</label><label><input type="radio" name="q" value="audit"> An audit-policy rule for DNS queries</label><button onclick="check()">Check answer</button><p id="feedback" class="feedback" aria-live="polite"></p></div><h2>Timed drill: build a test matrix (12 minutes)</h2><p>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.</p><table><thead><tr><th>Source</th><th>Destination</th><th>Expected</th><th>Observed</th></tr></thead><tbody><tr><td><code>app=api</code></td><td><code>app=db:5432</code></td><td>allowed</td><td></td></tr><tr><td>other labelled pod</td><td><code>app=db:5432</code></td><td>denied</td><td></td></tr><tr><td><code>app=api</code></td><td>cluster DNS :53</td><td>allowed if egress isolated</td><td></td></tr></tbody></table><p>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.</p><footer>Review: <a href="../reference/cks-four-week-field-guide.html">CKS four-week field guide</a> · Next: RBAC scope and escalation paths.</footer></main><script>function check(){const c=document.querySelector('input[name=q]:checked'),f=document.getElementById('feedback');if(!c){f.textContent='Choose one answer.';f.className='feedback bad';return;}if(c.value==='dns'){f.textContent='Correct. Egress isolation can block DNS; allow the required DNS destination and port explicitly.';f.className='feedback good';}else{f.textContent='Not quite. The symptom is name resolution after egress isolation, so inspect DNS traffic first.';f.className='feedback bad';}}</script></body></html>
|