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.0 KiB
Knowledge Check: Security Model & SecurityContext
1. A container is hardened with capabilities: drop: ["ALL"] and then fails because it
genuinely needs to bind to a low-numbered network port, which requires NET_BIND_SERVICE.
What's the least-privilege fix?
Answer: Add back only NET_BIND_SERVICE specifically (capabilities: add: ["NET_BIND_SERVICE"] alongside the drop-all), not remove the blanket drop entirely.
Least privilege means granting exactly what's needed, not reverting to granting everything.
2. True or false: setting runAsNonRoot: true fixes a vulnerability inside the application
itself.
Answer: False. It doesn't fix anything about the application's code — it limits what a compromise of that code could DO, by ensuring the process never has root privileges to begin with. This is the defense-in-depth distinction: reducing blast radius, not eliminating bugs.
3. Why might runAsNonRoot: true cause a Pod to fail to start entirely, and is that a
problem with the setting?
Answer: If the container image was built assuming it runs as root (e.g. it tries to bind a
privileged port, or write to a root-owned directory), the Pod will fail to start under
runAsNonRoot. This is NOT a problem with the setting — it's valuable, actionable information
that the image itself makes an assumption that should probably be fixed.
4. A container has readOnlyRootFilesystem: true and needs to write temporary cache files.
What's the correct way to allow that without abandoning the read-only filesystem entirely?
Answer: Mount an explicit emptyDir volume (ROOT 08) at the specific path the application
needs to write to. This keeps the rest of the filesystem read-only while allowing the one
legitimately-needed writable location.
Instructor Notes
Facilitation: Question 1 and question 4 both reinforce the same "narrow the exception, don't remove the protection" pattern — worth calling out that they're the same principle applied twice.
Approximate timing: 5-7 minutes.