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]>
43 lines
2.1 KiB
Markdown
43 lines
2.1 KiB
Markdown
# 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
|
|
|
|
1. Before this module, would you have thought twice about a workload's ServiceAccount having
|
|
broad, unused permissions "just in case"? Has that changed?
|
|
2. 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?
|
|
3. 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.
|