Completed upto lesson 28

lessons/0019-platform-binary-verification.html

@@ -0,0 +1 @@
+<!doctype html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width,initial-scale=1"><title>CKS lesson 19: Binary verification</title><link rel="stylesheet" href="../assets/course.css"></head><body><main><p class="eyebrow">Lesson 0019 · 25 minutes · Cluster Setup</p><h1>Verify a platform binary before deployment</h1><p class="lede">A checksum does not prove who produced an artifact, but it detects whether the bytes match a checksum obtained through a trusted channel. Treat a mismatch as a release blocker, not a warning to work around.</p><div class="callout"><strong>Exam reflex:</strong> verify the artifact before copying it into a privileged path, making it executable, or restarting a control-plane component. A failed checksum means stop and investigate.</div><h2>Timed task: 15 minutes</h2><p>In <code>lab/lesson-19-artifacts</code>, the trusted-release team supplied <code>SHA256SUMS</code> separately from the two received artifacts. Verify both artifacts using a Linux checksum command. Then create <code>lab/lesson-19-answer.md</code> containing:</p><ol><li>The exact verification command you ran.</li><li>Which artifact is verified and may proceed to the next deployment-review stage.</li><li>Which artifact must not be deployed.</li><li>Two appropriate next actions for the mismatched artifact.</li></ol><p>Do not edit either artifact or the checksum file. The artifacts are small training stand-ins, not real Kubernetes executables.</p><h2>Verification</h2><pre><code>cd lab/lesson-19-artifacts&#10;sha256sum -c SHA256SUMS&#10;&#10;# PowerShell equivalent for a single artifact:&#10;Get-FileHash .\kubelet-v1.35.0-linux-amd64 -Algorithm SHA256</code></pre><p>One result should be <code>OK</code>; one should be <code>FAILED</code>. A command can return non-zero when any verification fails—that non-zero result is expected evidence, not a reason to skip the check.</p><h2>Retrieval check</h2><div class="quiz"><h3>Question</h3><p>What is the correct immediate response to a checksum mismatch for a proposed kubelet binary?</p><label><input type="radio" name="q" value="stop">Do not deploy it; quarantine the artifact and obtain or verify a trusted replacement.</label><label><input type="radio" name="q" value="retry">Install it, then re-download the checksum file later.</label><label><input type="radio" name="q" value="ignore">Ignore the mismatch if the version tag is correct.</label><button onclick="check()">Check answer</button><p id="feedback" class="feedback" aria-live="polite"></p></div><h2>Documentation target</h2><p>Review the official Kubernetes release process and the security guidance for obtaining release artifacts. In production, pair checksums with signed provenance and trusted release channels.</p><h2>What to send me</h2><p>Send the four requested items from your Markdown answer. I’ll check your operational decision, not just the command syntax.</p><footer>Previous: <a href="0018-secrets-encryption-at-rest.html">Secrets encryption at rest</a> · CKS domain: Cluster Setup</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==='stop'){f.textContent='Correct. A mismatch is a supply-chain incident signal; fail closed and re-establish artifact trust.';f.className='feedback good';}else{f.textContent='Not quite. Integrity verification must fail closed; do not deploy an artifact whose bytes do not match trusted evidence.';f.className='feedback bad';}}</script></body></html>