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]>
48 lines
2.0 KiB
Markdown
48 lines
2.0 KiB
Markdown
# 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.
|