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]>
43 lines
2.1 KiB
Markdown
43 lines
2.1 KiB
Markdown
# 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
|
|
|
|
1. 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?
|
|
2. None of the settings you configured fixed a bug in any application. What did they actually
|
|
change, precisely?
|
|
3. 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.
|