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]>
52 lines
2.8 KiB
Markdown
52 lines
2.8 KiB
Markdown
# Guided Exercise: Planning a Pod Hardening Checklist
|
|
|
|
Paper-and-thinking exercise before the Labs.
|
|
|
|
## The scenario
|
|
|
|
You're handed a Pod spec for a small internal API with NO `securityContext` set at all — the
|
|
fully-default, unhardened case from the demonstration. Your team lead asks you to harden it
|
|
before it ships.
|
|
|
|
## Your task
|
|
|
|
Without writing the actual YAML yet, answer these:
|
|
|
|
1. List the settings you'd add, in the order you'd verify them (hint: there are at least three
|
|
distinct concerns from the lesson — user/root, filesystem, capabilities).
|
|
2. For each setting, name ONE way you'd notice if you'd broken the application by adding it
|
|
(what would the failure actually look like?).
|
|
3. If the application genuinely needs to write a cache file to disk, does that mean you should
|
|
skip `readOnlyRootFilesystem` entirely? What's the more precise fix?
|
|
4. Suppose after hardening, the container still runs fine but a security scan flags that it
|
|
still has the `NET_RAW` capability. What's the most likely reason, and what's the fix?
|
|
|
|
## A worked answer to check yourself against
|
|
|
|
1. In a reasonable order: (a) `runAsNonRoot`/`runAsUser` — a fundamental identity change,
|
|
surfaces image assumptions fastest; (b) `capabilities: drop: ["ALL"]` — narrow, usually safe
|
|
for a typical web API; (c) `readOnlyRootFilesystem: true` — most likely to need an
|
|
accompanying volume, so verify last once the others are confirmed working.
|
|
2. (a) Pod fails to start entirely (`CrashLoopBackOff` or an immediate error) if the image
|
|
assumed root. (b) The application errors on a specific operation that needed a capability
|
|
you dropped (e.g. failing to bind a privileged port). (c) A write operation fails at runtime
|
|
(a log line, an exception) the first time the app tries to write to disk.
|
|
3. No — the fix is mounting an explicit `emptyDir` volume at the specific path the cache needs,
|
|
keeping the rest of the filesystem read-only rather than abandoning the protection entirely.
|
|
4. Most likely: `capabilities: drop: ["ALL"]` was never actually applied (a YAML indentation
|
|
mistake, or it was added to the Pod's securityContext instead of the container's — capability
|
|
drops are container-level, not Pod-level). The fix is verifying the drop is actually present
|
|
on the CONTAINER's securityContext specifically.
|
|
|
|
## Instructor Notes
|
|
|
|
**Facilitation:** Question 4 is deliberately tricky — Pod-level vs. container-level
|
|
`securityContext` fields is a real, common source of "I set this and it didn't work" confusion
|
|
worth surfacing here before students hit it in a Lab.
|
|
|
|
**Approximate timing:** 15 minutes live with discussion; 12-15 minutes self-paced.
|
|
|
|
**Optional extension:** ask students to identify which of the settings in this exercise would
|
|
be MOST valuable to apply first if they could only add one to a large, existing fleet of
|
|
unhardened Pods under time pressure, and why.
|