feat(root): add Kubernetes security curriculum

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]>

content/root/root-09-kubernetes-security/m04-cluster-hardening-and-runtime/01-lesson-cluster-hardening.md

@@ -0,0 +1,64 @@
+# Pod Security Admission & a Survey of Runtime Hardening
+
+This module is deliberately a survey, not a deep dive — the topics here are real and important,
+but lean toward cluster-operator/platform-team concerns rather than the daily-driver skills most
+ROOT_ learners will use constantly. Treat the labs in this module as good-to-know, not required
+mastery, before moving on.
+
+## Pod Security Admission: enforcing a baseline across a Namespace
+
+Everything you configured by hand in earlier modules (non-root, dropped capabilities, read-only
+filesystem) can also be ENFORCED automatically at the Namespace level via **Pod Security
+Admission (PSA)** — a label on the Namespace itself that rejects any Pod violating a chosen
+security standard (`privileged`, `baseline`, or `restricted`, from least to most strict):
+
+```yaml
+apiVersion: v1
+kind: Namespace
+metadata:
+  name: production
+  labels:
+    pod-security.kubernetes.io/enforce: restricted
+```
+
+This replaces the older PodSecurityPolicy (PSP) mechanism, which was removed from Kubernetes —
+if you encounter PSP in older documentation or an older cluster, know that PSA is its current
+replacement.
+
+## Immutable Secrets: preventing a class of accidental change
+
+A Secret can be marked `immutable: true`, which prevents its data from being changed after
+creation (a new Secret with a new name has to be created instead, and workloads updated to
+reference it). This trades a small amount of operational flexibility for a real safety
+property: an accidental or malicious edit to a live Secret can't silently happen.
+
+## A survey of further topics (labs available, treat as optional depth)
+
+- **Audit policy** — configuring what the Kubernetes API server logs about requests made against
+  it (who did what, when) — genuinely important for incident investigation, but a cluster-admin
+  concern, not something most workload teams configure themselves.
+- **RuntimeClass** — lets specific Pods run under a different container runtime configuration
+  (e.g. an extra-sandboxed runtime like gVisor or Kata Containers) for workloads that need
+  stronger isolation than the default runtime provides — relevant mainly for genuinely
+  untrusted or high-risk workloads, not typical applications.
+
+## Instructor Notes
+
+**Approximate timing:** 15 minutes read (shorter than other lessons — deliberately survey-depth).
+
+**Framing for instructors:** Be explicit with students that this module is intentionally
+lighter than the earlier ones in this course — the goal is awareness ("this exists, here's
+roughly what it's for") rather than hands-on fluency, consistent with not every CKS-style topic
+belonging in the core learning path.
+
+**Discussion question:** "Why would a platform team prefer enforcing security standards via
+Pod Security Admission at the Namespace level, instead of trusting every team to configure
+SecurityContext correctly on every Pod by hand?" (Answer: PSA provides a hard backstop —
+correctly-configured SecurityContext relies on every individual Pod author doing it right every
+time; PSA rejects violations automatically regardless of whether any individual author
+remembered to.)
+
+**Optional extension:** ask which of `privileged`/`baseline`/`restricted` a team should start a
+brand-new, security-conscious project with, and why not jump straight to the strictest option
+on a cluster already running older, unaudited workloads (a good practical judgment question
+about migration risk, not just definitions).