ced4568andClaude Sonnet 5
7f6e1857c0
Upgrades six PARTIAL modules to the gold-module standard (lesson/demonstration/ knowledge-check/guided-exercise/lab(s)/reflection), preserving every existing lab activity_id and scenario_id: root-06-m03 (jobs/cronjobs/daemonsets), root-07-m04 (ingress/networkpolicy), root-07-m02 (configuration/secrets, converted in place from a bare 5-lab bank), root-09-m02 (serviceaccounts/rbac), root-09-m03 (network/supply-chain security), root-10-m03 (troubleshooting framework). root-05-m01 (20-task kubectl-fluency bank) gets a minimal bookending lesson + reflection rather than a full redesign, since each task already carries its own explanation. root-12-m01, root-capstone-m01, and root-09-m04 are promoted to READY via documented exceptions (no new activities) where adding one would misrepresent their intentional design. Wires a new rootnode-security-assessment (exam, 60min, hint_policy disabled) using the existing Phase 3B assessment engine: 3 required hands-on CORE scenarios + 4 random-draw pools covering SecurityContext, RBAC, network policy, and the 7 previously-unwired CKS MCQs. Wires the previously-unwired readiness-probe-task scenario as an OPTIONAL practice lab in root-10-m01, using the existing is_required model. Adds root-11-m01-devops-platform-thinking — an honest, lesson-only ROOT 11 orientation module naming DevOps/platform engineering practices already exercised in ROOT 05-10/12, explicit that GitOps/CI-CD/IaC/observability need lab infrastructure this platform doesn't yet provide. No fake labs. Adds infra/scripts/validate-course-content.js: cross-checks the DB against scenario/content files for duplicate ids, orphans, invalid references, cycles, sequence collisions, instructor-notes leakage, and (new) self-paced content deferring explanation to a live instructor. 0 errors against the resulting 22 courses/modules, 163 activities, 98 scenario files. No application code changed — every gap was satisfiable with existing tables (course_modules, module_activities, assessment_definitions) and the existing content-delivery pipeline. Co-Authored-By: Claude Sonnet 5 <[email protected]>
2.1 KiB
Reflection: Permissions Should Reflect What a Workload Actually Needs
You just configured real ServiceAccounts and RBAC rules. Take a few minutes to connect this to production security practice.
Reflection questions
- Before this module, would you have thought twice about a workload's ServiceAccount having broad, unused permissions "just in case"? Has that changed?
- If a workload with cluster-admin-equivalent RBAC access is ever compromised (a vulnerable dependency, a supply-chain issue), what's the realistic blast radius compared to one scoped to exactly what it needs?
- How would you discover, on a real cluster you didn't build, whether any ServiceAccount has more access than it actually uses?
Real Ops takeaway
RBAC over-permissioning is a silent, cumulative risk. Unlike a misconfigured probe or a crashing Pod, an over-broad Role doesn't cause a visible symptom on a healthy day — it just sits there as unused risk until the one day a workload using it is compromised. This makes RBAC review a discipline that has to be practiced deliberately, not one that gets forced on you by an obvious failure.
Least privilege is a default you set once, not a fix you apply after an incident. Every example in this module started from "grant nothing, add exactly what's needed" rather than "grant broadly, restrict later" — the second approach almost never actually happens once something works, because there's no pressure forcing the cleanup.
This module is complete. Continue to the next module.
Instructor Notes
Discussion questions for a live classroom: question 3 is a good one to leave partially open
— acknowledge that real answers involve tooling beyond plain kubectl (RBAC audit tools) that
this course doesn't build hands-on, while still reinforcing that the QUESTION itself is the
right one to ask.
Approximate timing: 8 minutes live discussion; 5 minutes self-paced writing.
Optional extension: ask students to identify one ServiceAccount permission from earlier in ROOT_ (any Lab so far) that, in a real production system, they'd want to double-check was actually necessary.