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]>
65 lines
3.4 KiB
Markdown
65 lines
3.4 KiB
Markdown
# 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).
|