Completed upto lesson 28

lessons/0005-pod-security-standards.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>CKS lesson 5: Pod Security Standards</title><link rel="stylesheet" href="../assets/course.css"></head><body><main><p class="eyebrow">Lesson 0005 · 25 minutes · Minimize Microservice Vulnerabilities</p><h1>Enforce a restricted workload boundary</h1><p class="lede">A hardened Pod is useful; preventing the next insecure Pod is better. This CKS-style task combines namespace labels, admission behavior, and a compliant workload.</p><div class="callout"><strong>Exam reflex:</strong> first identify the enforcement scope. Pod Security Admission is configured with labels on the Namespace, not annotations on an individual Pod.</div><h2>Timed task: 15 minutes</h2><p>In namespace <code>cks-pss</code>, enforce the <code>restricted</code> Pod Security Standard for the Kubernetes version running in the cluster. Then make the existing <code>orders</code> Pod compliant and running. Create your answer as <code>lab/pod-security-standards-answer.yaml</code>.</p><p>Start with <code>kubectl --context kind-cks-lab apply -f .\lab\pod-security-standards-starter.yaml</code>. Your answer must add the required Namespace labels and preserve the Pod name, namespace, image, command, and label.</p><h2>Proof, not assumption</h2><pre><code>kubectl --context kind-cks-lab apply -f .\lab\pod-security-standards-answer.yaml
+kubectl --context kind-cks-lab -n cks-pss wait --for=condition=Ready pod/orders --timeout=60s
+kubectl --context kind-cks-lab -n cks-pss get pod orders -o jsonpath='{.spec.securityContext.seccompProfile.type}{"\n"}{.spec.containers[0].securityContext}'
+kubectl --context kind-cks-lab -n cks-pss run root-test --image=busybox:1.37 --restart=Never -- sh -c 'sleep 60'</code></pre><p>The final command should be rejected by admission. Remove the failed test Pod if one was created.</p><h2>Tricky retrieval check</h2><div class="quiz"><h3>Question</h3><p>A Pod has <code>spec.securityContext.runAsNonRoot: true</code>, but its only container sets <code>securityContext.runAsUser: 0</code>. In a namespace enforcing <code>restricted</code>, what should you expect?</p><label><input type="radio" name="q" value="inherit">It runs as a non-root user because the Pod-level value always wins.</label><label><input type="radio" name="q" value="reject">It is rejected because the container-level setting overrides the Pod-level setting and violates the policy.</label><label><input type="radio" name="q" value="warn">It is admitted with a warning because UID 0 is allowed under restricted.</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/concepts/security/pod-security-standards/">Pod Security Standards</a> reference. Look up the exact Namespace label keys and restricted requirements rather than relying on memory.</p><h2>What to send me</h2><p>Paste your answer YAML plus the rejection message from <code>root-test</code>. I’ll check both the policy scope and whether your workload satisfies it.</p><footer>Previous: <a href="0004-workload-hardening.html">workload hardening</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==='reject'){f.textContent='Correct. A container securityContext takes precedence where it is set. UID 0 fails the restricted runAsNonRoot requirement.';f.className='feedback good';}else{f.textContent='Not quite. Container-level securityContext values override the Pod-level values for that container; UID 0 violates restricted.';f.className='feedback bad';}}</script></body></html>