Completed upto lesson 28

lessons/0022-kube-apiserver-hardening.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 22: API server hardening</title><link rel="stylesheet" href="../assets/course.css"></head><body><main><p class="eyebrow">Lesson 0022 · 45 minutes · Cluster Hardening</p><h1>Remove weak API-server access paths</h1><p class="lede">The API server is the cluster’s security boundary. A permissive flag can bypass all the careful RBAC and workload policy built above it, so secure the control-plane configuration first.</p><div class="callout"><strong>Exam reflex:</strong> inspect every API-server flag before changing it. Preserve unrelated required flags, remove or replace weak settings, and make audit logging explicit.</div><h2>Timed task: 35 minutes</h2><p>Review <code>lab/lesson-22-kube-apiserver-insecure.yaml</code>. Create <code>lab/lesson-22-kube-apiserver-answer.yaml</code> as a complete replacement static-Pod manifest.</p><p>Preserve the API version, kind, Pod name, namespace, host networking, container name, image, <code>--etcd-servers</code>, and <code>--service-cluster-ip-range</code>. Harden the API server so it:</p><ul><li>Rejects anonymous API requests.</li><li>Uses <code>Node,RBAC</code> authorization rather than <code>AlwaysAllow</code>.</li><li>Validates ServiceAccount tokens against the API server.</li><li>Disables profiling endpoints.</li><li>Writes audit events to <code>/var/log/kubernetes/audit/audit.log</code> instead of standard output.</li></ul><p>Do not add a new API server, change the image, or use an API object such as a Deployment. This is a static control-plane Pod manifest. It must not be applied to the Kind lab.</p><h2>Verification</h2><pre><code>Get-Content .\lab\lesson-22-kube-apiserver-answer.yaml
+
+# On a real kubeadm control-plane node, inspect the active static Pod:
+sudo grep -E -- '--anonymous-auth|--authorization-mode|--service-account-lookup|--profiling|--audit-log-path' /etc/kubernetes/manifests/kube-apiserver.yaml</code></pre><p>Production changes to the API-server manifest require the approved control-plane maintenance process. A kubelet automatically restarts its static Pod when the manifest changes, so do not make experimental edits on a live production control plane.</p><h2>Retrieval check</h2><div class="quiz"><h3>Question</h3><p>Why is <code>--authorization-mode=AlwaysAllow</code> dangerous even if Roles and RoleBindings are carefully designed?</p><label><input type="radio" name="q" value="always">It allows requests without applying RBAC authorization decisions.</label><label><input type="radio" name="q" value="logs">It disables audit logs.</label><label><input type="radio" name="q" value="pods">It makes every Pod privileged.</label><button onclick="check()">Check answer</button><p id="feedback" class="feedback" aria-live="polite"></p></div><h2>Documentation target</h2><p>Use the Kubernetes <a href="https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/">kube-apiserver command reference</a> to confirm the security-flag behavior.</p><h2>What to send me</h2><p>Paste your complete command list. I’ll review one flag at a time and preserve your request not to reveal the next correction early.</p><footer>Previous: <a href="0021-pod-security-admission-modes.html">Pod Security Admission modes</a> · CKS domain: Cluster Hardening</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==='always'){f.textContent='Correct. AlwaysAllow bypasses the authorization controls that RBAC is meant to enforce.';f.className='feedback good';}else{f.textContent='Not quite. The authorization mode decides whether RBAC is evaluated for a request.';f.className='feedback bad';}}</script></body></html>