Completed upto lesson 28

lessons/0025-istio-strict-mtls.html

@@ -0,0 +1,4 @@
+<!doctype html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width,initial-scale=1"><title>Supplemental lesson 25: Istio strict mTLS</title><link rel="stylesheet" href="../assets/course.css"></head><body><main><p class="eyebrow">Supplemental Lesson 0025 · 20 minutes · Istio service-mesh security</p><h1>Require mTLS for one application namespace</h1><p class="lede">Istio sidecars can automatically use mTLS, but permissive acceptance may still allow plaintext requests. <code>PeerAuthentication</code> with <code>STRICT</code> tells receiving workloads to accept only mTLS traffic.</p><div class="callout"><strong>Security reflex:</strong> PeerAuthentication controls what the destination workload accepts. For namespace-wide policy, use no workload selector; a selector narrows the policy to only matching Pods.</div><h2>Timed task: 12 minutes</h2><p>Read <code>lab/lesson-25-fixture.yaml</code>. Create <code>lab/lesson-25-answer.yaml</code> from scratch with one Istio <code>PeerAuthentication</code> resource.</p><p>The policy must:</p><ul><li>Use API version <code>security.istio.io/v1</code>.</li><li>Be named <code>default</code> in namespace <code>payments-mesh</code>.</li><li>Require <code>STRICT</code> mTLS for every workload in that namespace.</li><li>Contain no workload selector and no port exceptions.</li></ul><p>The local Kind cluster does not have Istio installed, so do not apply this manifest there. This is API and policy-scope practice; on an Istio cluster, first apply the supplied fixture so the Namespace receives sidecar injection.</p><h2>Verification on an Istio cluster</h2><pre><code>kubectl apply -f .\lab\lesson-25-fixture.yaml
+kubectl apply -f .\lab\lesson-25-answer.yaml
+kubectl -n payments-mesh get peerauthentication default -o yaml
+istioctl x describe pod -n payments-mesh -l app=payments-api</code></pre><p>The first command creates the injection-enabled namespace and workload. The final command confirms the workload is in the mesh and helps diagnose mTLS policy state.</p><h2>Retrieval check</h2><div class="quiz"><h3>Question</h3><p>Why should this namespace-wide policy omit <code>spec.selector</code>?</p><label><input type="radio" name="q" value="scope">Without a selector, it applies to every workload in its own namespace.</label><label><input type="radio" name="q" value="tls">Selectors disable automatic certificates.</label><label><input type="radio" name="q" value="cluster">A selector would make the policy cluster-wide.</label><button onclick="check()">Check answer</button><p id="feedback" class="feedback" aria-live="polite"></p></div><h2>Documentation target</h2><p>Use Istio’s official <a href="https://istio.io/latest/docs/reference/config/security/peer_authentication/">PeerAuthentication reference</a> and <a href="https://istio.io/latest/docs/tasks/security/authentication/authn-policy/">mTLS authentication task</a>.</p><h2>What to send me</h2><p>Paste the single policy YAML. I’ll check it one issue at a time and won’t reveal the next correction early.</p><footer>Supplemental path: Istio mTLS · Next: workload-scoped mTLS and authorization</footer></main><script>function check(){const c=document.querySelector('input[name=q]:checked'),f=document.getElementById('feedback');if(!c){f.textContent='Choose an answer.';f.className='feedback bad';return;}if(c.value==='scope'){f.textContent='Correct. A PeerAuthentication without a selector applies to all workloads in that policy namespace.';f.className='feedback good';}else{f.textContent='Not quite. Omitting the selector is what makes this a namespace-wide destination policy.';f.className='feedback bad';}}</script></body></html>