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>Supplemental lesson 26: Istio workload authorization</title><link rel="stylesheet" href="../assets/course.css"></head><body><main><p class="eyebrow">Supplemental Lesson 0026 · 25 minutes · Istio service-mesh security</p><h1>Allow one workload identity to call the payments API</h1><p class="lede">Strict mTLS proves the client has a mesh identity. An Istio AuthorizationPolicy decides which authenticated identity may actually call a workload. Together, they turn encrypted traffic into least-privilege service access.</p><div class="callout"><strong>Security reflex:</strong> use a SPIFFE-style principal when access must be tied to one ServiceAccount. A Namespace name alone is broader: every workload in that Namespace could match it.</div><h2>Timed task: 15 minutes</h2><p>Read <code>lab/lesson-26-fixture.yaml</code>. Assume Lesson 25 strict mTLS is already active in <code>payments-mesh</code>. Create <code>lab/lesson-26-answer.yaml</code> from scratch with one Istio <code>AuthorizationPolicy</code>.</p><p>The policy must:</p><ul><li>Be named <code>payments-api-only-frontend</code> in namespace <code>payments-mesh</code>.</li><li>Select only workloads labelled <code>app=payments-api</code>.</li><li>Use action <code>ALLOW</code>.</li><li>Allow only the ServiceAccount <code>frontend</code> in namespace <code>web-mesh</code>.</li><li>Allow only TCP port <code>8080</code>.</li></ul><p>Do not allow an entire Namespace, use a wildcard principal, add an HTTP method/path rule, or create a PeerAuthentication policy. The local Kind cluster does not have Istio, so this is a manifest-reading exercise.</p><h2>Identity shape</h2><pre><code>cluster.local/ns/<namespace>/sa/<serviceaccount></code></pre><p>Istio obtains that identity from mTLS. This is why strict mTLS is the foundation for this type of workload authorization.</p><h2>Verification on an Istio cluster</h2><pre><code>kubectl apply -f .\lab\lesson-26-fixture.yaml kubectl apply -f .\lab\lesson-25-answer.yaml kubectl apply -f .\lab\lesson-26-answer.yaml kubectl -n payments-mesh get authorizationpolicy payments-api-only-frontend -o yaml istioctl x describe pod -n payments-mesh -l app=payments-api</code></pre><h2>Retrieval check</h2><div class="quiz"><h3>Question</h3><p>Why is the source principal safer here than allowing all clients from <code>web-mesh</code>?</p><label><input type="radio" name="q" value="identity">It limits access to the exact frontend ServiceAccount instead of every workload in that namespace.</label><label><input type="radio" name="q" value="tls">It disables mTLS for unrelated clients.</label><label><input type="radio" name="q" value="port">It automatically chooses port 8080.</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/authorization-policy/">AuthorizationPolicy reference</a> and <a href="https://istio.io/latest/docs/concepts/security/">security concepts</a>.</p><h2>What to send me</h2><p>Paste the single policy YAML. I’ll review it one issue at a time and will not reveal the next correction early.</p><footer>Supplemental path: Istio authorization · Previous: <a href="0025-istio-strict-mtls.html">Strict mTLS</a></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==='identity'){f.textContent='Correct. The ServiceAccount principal is the narrowest workload identity in this scenario.';f.className='feedback good';}else{f.textContent='Not quite. A Namespace is a group of workloads; the principal names one exact authenticated workload identity.';f.className='feedback bad';}}</script></body></html>
|