Files
CKS-Lessons/lessons/0007-serviceaccount-token-exposure.html
2026-08-23 15:29:06 +06:00

2 lines
3.5 KiB
HTML
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
<!doctype html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width,initial-scale=1"><title>CKS lesson 7: ServiceAccount token exposure</title><link rel="stylesheet" href="../assets/course.css"></head><body><main><p class="eyebrow">Lesson 0007 · 20 minutes · Minimize Microservice Vulnerabilities</p><h1>Remove API credentials a workload does not need</h1><p class="lede">Every automatically mounted ServiceAccount token is a potential credential exposed through a container compromise. Disable it when the workload does not call the Kubernetes API.</p><div class="callout"><strong>Exam reflex:</strong> distinguish identity from credential mounting. A Pod can name a ServiceAccount for policy clarity while still opting out of its token volume.</div><h2>Timed task: 12 minutes</h2><p>The <code>checkout</code> Pod runs in the <code>checkout</code> namespace and does not need to call the Kubernetes API. Apply <code>lab/serviceaccount-token-starter.yaml</code>, then create <code>lab/serviceaccount-token-answer.yaml</code> that preserves its name, namespace, label, image, command, and <code>serviceAccountName</code> while preventing the token from being mounted into this Pod.</p><p>Use the smallest-scoped native control: make the change at the Pod specification, rather than changing the ServiceAccount globally.</p><h2>Proof, not assumption</h2><pre><code>kubectl --context kind-cks-lab apply -f .\lab\serviceaccount-token-answer.yaml&#10;kubectl --context kind-cks-lab -n checkout wait --for=condition=Ready pod/checkout --timeout=60s&#10;kubectl --context kind-cks-lab -n checkout exec checkout -- sh -c 'test ! -e /var/run/secrets/kubernetes.io/serviceaccount/token'&#10;kubectl --context kind-cks-lab -n checkout get pod checkout -o jsonpath='{.spec.automountServiceAccountToken}{"\n"}'</code></pre><p>The token-path check must return success and the final command must print <code>false</code>.</p><h2>Retrieval check</h2><div class="quiz"><h3>Question</h3><p>Where should you set the control when only one Pod must not receive a ServiceAccount token, while other Pods using the same ServiceAccount might still need one?</p><label><input type="radio" name="q" value="pod">On that Pod’s spec.</label><label><input type="radio" name="q" value="namespace">On the Namespace.</label><label><input type="radio" name="q" value="cluster">On the API server.</label><button onclick="check()">Check answer</button><p id="feedback" class="feedback" aria-live="polite"></p></div><h2>Documentation target</h2><p>Use the official <a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/">Configure Service Accounts for Pods</a> guide to confirm the precedence of Pod and ServiceAccount token-mount settings.</p><h2>What to send me</h2><p>Paste your answer YAML and the output of both proof commands. I’ll check the scope and the runtime credential boundary.</p><footer>Previous: <a href="0006-read-only-root-filesystem.html">Read-only root filesystem</a> · CKS domain: Minimize Microservice Vulnerabilities</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==='pod'){f.textContent='Correct. The Pod-level field limits the change to this workload.';f.className='feedback good';}else{f.textContent='Not quite. Set the Pod-level control when the exception is specific to one workload.';f.className='feedback bad';}}</script></body></html>