Files

T

ced4568andClaude Sonnet 5 960a638ec9 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]>

2026-08-26 09:07:07 -05:00

3.4 KiB

Raw Blame History

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):

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).

3.4 KiB Raw Blame History