ced4568andClaude Sonnet 5
960a638ec9
Four new modules, moving ROOT 09 off PLANNED and building the 22-scenario CKS-style bank into a coherent course instead of disconnected exam tasks — see docs/ROOT_CURRICULUM_COVERAGE_MATRIX.md for the CORE/GUIDED/INDEPENDENT/ADVANCED/ASSESSMENT-BANK classification behind every placement. root-09-m01-security-model-and-securitycontext — READY, full gold-standard pattern: defense in depth, least privilege, hardening a Pod with SecurityContext. Lesson, demonstration (a Pod before/after hardening), knowledge check, guided exercise (a hardening checklist), real Labs (CORE: non-root/drop-capabilities/read-only-fs/ pod-security-context; GUIDED: seccomp; ADVANCED: AppArmor; INDEPENDENT: the generic pod-security-context duplicate), and a reflection. root-09-m02-serviceaccounts-and-rbac — PARTIAL: workload identity and least-privilege permissions. Lesson + knowledge check + real Labs. root-09-m03-network-and-supplychain-security — PARTIAL: NetworkPolicy as a security control (default-deny), image/registry trust, TLS ingress. Lesson + knowledge check + real Labs. root-09-m04-cluster-hardening-and-runtime — PARTIAL, deliberately survey-depth: Pod Security Admission and a lighter treatment of audit-policy/runtime-sandboxing topics that don't belong in the core daily-driver path. Co-Authored-By: Claude Sonnet 5 <[email protected]>
2.1 KiB
Reflection: Least Privilege Is a Default, Not an Afterthought
You just hardened real Pods across several Labs — non-root, dropped capabilities, a read-only filesystem, and a full SecurityContext review. Take a few minutes to connect this to real practice.
Reflection questions
- Before this module, would you have described "runs as root with a fully writable filesystem" as insecure, or just as "the default, unremarkable configuration"? Has that changed?
- None of the settings you configured fixed a bug in any application. What did they actually change, precisely?
- If your team had to choose between hardening every new Pod by default (as a policy) versus hardening Pods only after an incident reveals a gap, which produces less total risk over time, and why?
Real Ops takeaway
Unhardened is not neutral — it's the maximum-privilege default. A container with no SecurityContext configured isn't "unopinionated"; it's root, every capability, fully writable — the MOST privileged configuration possible, not a safe middle ground. Teams that treat hardening as optional are choosing maximum blast radius by default, usually without realizing they're choosing anything at all.
Defense in depth means no single mistake should be catastrophic. The value of stacking non-root + dropped capabilities + read-only filesystem isn't that any ONE of them is perfect — it's that a real compromise would have to defeat several independent restrictions simultaneously instead of exploiting one gap that grants everything. This is exactly why security-minded teams apply all of these by default rather than picking "the one that matters most."
This module is complete. Continue to the next module.
Instructor Notes
Discussion questions for a live classroom: question 3 is worth pushing on directly — it's the actual business case for security-by-default, not just a technical preference.
Approximate timing: 8-10 minutes live discussion; 5 minutes self-paced writing.
Optional extension: ask students to draft a one-paragraph "default Pod hardening policy" their hypothetical team would adopt, based on what they've learned in this module.