Completed upto lesson 28

This commit is contained in:
Mosiur Rahman
2026-08-23 15:29:06 +06:00
parent fb86f0b60a
commit 8e43c00cd6
104 changed files with 1888 additions and 0 deletions

View File

@@ -0,0 +1,8 @@
<!doctype html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width,initial-scale=1"><title>CKS lesson 3: RBAC least privilege</title><link rel="stylesheet" href="../assets/course.css"></head><body><main><p class="eyebrow">Lesson 0003 · 20 minutes</p><h1>RBAC: grant the minimum—and prove the boundary</h1><p class="lede">Security work is not “make it work.” It is “make the required action work while every unnecessary action stays blocked.”</p><div class="callout"><strong>Career connection:</strong> least-privilege reviews are a routine platform-security responsibility. The fastest path is always: identify subject → scope → resource → verb → verification.</div><h2>Timed task: 12 minutes</h2><p>In namespace <code>cks-rbac</code>, grant ServiceAccount <code>report-reader</code> permission to <strong>get</strong> and <strong>list</strong> only <code>configmaps</code>. It must <strong>not</strong> create ConfigMaps or read Secrets. Use a namespace-scoped Role and RoleBinding.</p><ol><li>Set up only the challenge objects: <code>kubectl --context kind-cks-lab apply -f .\lab\rbac-starter.yaml</code>.</li><li>Create your answer in <code>lab/rbac-answer.yaml</code>. Use the official <a href="https://kubernetes.io/docs/reference/access-authn-authz/rbac/">RBAC reference</a>—documentation use is expected.</li><li>Apply it to the isolated lab.</li><li>Run the four verification commands below. Do not stop after the first success.</li></ol><h2>Proof commands</h2><pre><code>kubectl --context kind-cks-lab auth can-i get configmaps \
-n cks-rbac --as=system:serviceaccount:cks-rbac:report-reader
kubectl --context kind-cks-lab auth can-i list configmaps \
-n cks-rbac --as=system:serviceaccount:cks-rbac:report-reader
kubectl --context kind-cks-lab auth can-i create configmaps \
-n cks-rbac --as=system:serviceaccount:cks-rbac:report-reader
kubectl --context kind-cks-lab auth can-i get secrets \
-n cks-rbac --as=system:serviceaccount:cks-rbac:report-reader</code></pre><p>Expected result sequence: <strong>yes, yes, no, no</strong>.</p><h2>Retrieval check</h2><div class="quiz"><h3>Question</h3><p>A requirement is confined to one namespace. Which binding usually best supports least privilege?</p><label><input type="radio" name="q" value="cluster"> ClusterRoleBinding</label><label><input type="radio" name="q" value="role"> RoleBinding in that namespace</label><label><input type="radio" name="q" value="admin"> Binding to cluster-admin</label><button onclick="check()">Check answer</button><p id="feedback" class="feedback" aria-live="polite"></p></div><h2>Debrief</h2><p>Send me your four results and your YAML. I’ll review scope, subject, resource names, verbs, and whether a narrower permission is possible. That review is the feedback loop that builds confidence.</p><footer>Primary source: <a href="https://kubernetes.io/docs/concepts/security/rbac-good-practices/">Kubernetes RBAC good practices</a> · Review: <a href="../reference/cks-four-week-field-guide.html">CKS four-week field guide</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==='role'){f.textContent='Correct. A RoleBinding lets you scope authorization to the namespace where it is needed.';f.className='feedback good';}else{f.textContent='Not quite. Prefer namespace scope when the requirement does not need cluster-wide access.';f.className='feedback bad';}}</script></body></html>