2 lines
3.9 KiB
HTML
2 lines
3.9 KiB
HTML
<!doctype html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width,initial-scale=1"><title>CKS lesson 24: RBAC remediation</title><link rel="stylesheet" href="../assets/course.css"></head><body><main><p class="eyebrow">Lesson 0024 · 20 minutes · Cluster Hardening</p><h1>Remove an unnecessary Secret-read permission</h1><p class="lede">This is an exam-style remediation: an existing workload identity has more access than it needs. Change only the permission rule, preserve the established identity and binding, and prove the boundary.</p><div class="callout"><strong>Exam reflex:</strong> before creating new RBAC objects, inspect the existing Role and RoleBinding. Often the smallest safe fix is simply to narrow one Role rule.</div><h2>Timed task: 12 minutes</h2><p>Apply <code>lab/lesson-24-fixture.yaml</code>. The <code>release-bot</code> ServiceAccount in namespace <code>release</code> is overprivileged.</p><p>Create <code>lab/lesson-24-answer.yaml</code> containing a replacement for only the existing Role <code>release-bot-reader</code>. Preserve its name and namespace. After your change, the ServiceAccount must:</p><ul><li>Be able to <code>get</code>, <code>list</code>, and <code>watch</code> ConfigMaps in <code>release</code>.</li><li>Have no permission to read Secrets.</li><li>Have no permission to create ConfigMaps.</li></ul><p>Do not create another Role, RoleBinding, ClusterRole, or ServiceAccount. The RoleBinding already connects the correct identity to the correct Role.</p><h2>Verification</h2><pre><code>kubectl --context kind-cks-lab apply -f .\lab\lesson-24-fixture.yaml kubectl --context kind-cks-lab apply -f .\lab\lesson-24-answer.yaml $sa = 'system:serviceaccount:release:release-bot' kubectl --context kind-cks-lab auth can-i get configmaps --as=$sa -n release kubectl --context kind-cks-lab auth can-i list configmaps --as=$sa -n release kubectl --context kind-cks-lab auth can-i watch configmaps --as=$sa -n release kubectl --context kind-cks-lab auth can-i get secrets --as=$sa -n release kubectl --context kind-cks-lab auth can-i create configmaps --as=$sa -n release</code></pre><p>Expected results: <code>yes yes yes no no</code>.</p><h2>Retrieval check</h2><div class="quiz"><h3>Question</h3><p>Why is it better to remove the Secret permission from the existing Role than to create a second, narrower Role and binding?</p><label><input type="radio" name="q" value="additive">RBAC permissions are additive; the original Role would still grant Secret access.</label><label><input type="radio" name="q" value="names">A ServiceAccount can only have one RoleBinding.</label><label><input type="radio" name="q" value="namespace">Roles cannot grant Secret access.</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 Kubernetes <a href="https://kubernetes.io/docs/reference/access-authn-authz/rbac/">RBAC reference</a> for rules, bindings, and ServiceAccount subject names.</p><h2>What to send me</h2><p>Paste only the replacement Role and the five <code>can-i</code> results. I’ll review it one issue at a time and will not reveal the next correction early.</p><footer>Previous: <a href="0023-cilium-wireguard-encryption.html">Cilium WireGuard encryption</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==='additive'){f.textContent='Correct. RBAC allows the union of permissions granted by all applicable bindings.';f.className='feedback good';}else{f.textContent='Not quite. Adding a narrower Role does not subtract the broader permission that already exists.';f.className='feedback bad';}}</script></body></html>
|