ced4568andClaude Sonnet 5
7f6e1857c0
Upgrades six PARTIAL modules to the gold-module standard (lesson/demonstration/ knowledge-check/guided-exercise/lab(s)/reflection), preserving every existing lab activity_id and scenario_id: root-06-m03 (jobs/cronjobs/daemonsets), root-07-m04 (ingress/networkpolicy), root-07-m02 (configuration/secrets, converted in place from a bare 5-lab bank), root-09-m02 (serviceaccounts/rbac), root-09-m03 (network/supply-chain security), root-10-m03 (troubleshooting framework). root-05-m01 (20-task kubectl-fluency bank) gets a minimal bookending lesson + reflection rather than a full redesign, since each task already carries its own explanation. root-12-m01, root-capstone-m01, and root-09-m04 are promoted to READY via documented exceptions (no new activities) where adding one would misrepresent their intentional design. Wires a new rootnode-security-assessment (exam, 60min, hint_policy disabled) using the existing Phase 3B assessment engine: 3 required hands-on CORE scenarios + 4 random-draw pools covering SecurityContext, RBAC, network policy, and the 7 previously-unwired CKS MCQs. Wires the previously-unwired readiness-probe-task scenario as an OPTIONAL practice lab in root-10-m01, using the existing is_required model. Adds root-11-m01-devops-platform-thinking — an honest, lesson-only ROOT 11 orientation module naming DevOps/platform engineering practices already exercised in ROOT 05-10/12, explicit that GitOps/CI-CD/IaC/observability need lab infrastructure this platform doesn't yet provide. No fake labs. Adds infra/scripts/validate-course-content.js: cross-checks the DB against scenario/content files for duplicate ids, orphans, invalid references, cycles, sequence collisions, instructor-notes leakage, and (new) self-paced content deferring explanation to a live instructor. 0 errors against the resulting 22 courses/modules, 163 activities, 98 scenario files. No application code changed — every gap was satisfiable with existing tables (course_modules, module_activities, assessment_definitions) and the existing content-delivery pipeline. Co-Authored-By: Claude Sonnet 5 <[email protected]>
42 lines
2.2 KiB
Markdown
42 lines
2.2 KiB
Markdown
# Reflection: Reachability and Trust Are Decisions You Make on Purpose
|
|
|
|
You just applied default-deny NetworkPolicy, egress restriction, TLS ingress, and image-pull
|
|
authentication for real. Take a few minutes to connect these to a single underlying principle.
|
|
|
|
## Reflection questions
|
|
|
|
1. Four different mechanisms in this module (NetworkPolicy ingress, NetworkPolicy egress, TLS,
|
|
image-pull secrets) all express the same underlying idea in a different layer. What is that
|
|
idea, stated in one sentence?
|
|
2. If you had to prioritize implementing ONLY ONE of this module's controls on a brand-new,
|
|
unsecured cluster, which would you pick first, and why?
|
|
3. How would you explain, to someone who thinks "our cluster is internal, so it doesn't need
|
|
this," why internal-only still benefits from all four controls?
|
|
|
|
## Real Ops takeaway
|
|
|
|
**Trust should be explicit, narrow, and verifiable — never assumed from proximity.** A Pod on
|
|
the same cluster, a request from inside the corporate network, an image from "a registry we
|
|
usually use" — none of these are actually trustworthy by default. Every control in this module
|
|
replaces an assumption ("it's internal, it's probably fine") with an explicit, checkable
|
|
decision (this specific Pod can reach this specific destination; this specific registry is
|
|
authenticated; this specific connection is encrypted).
|
|
|
|
**Supply-chain and network security compound.** A compromised image with unrestricted egress on
|
|
an open network is a far worse incident than the same compromised image on a hardened one — the
|
|
controls in this module don't individually prevent every incident, but together they
|
|
dramatically shrink what any single failure can turn into.
|
|
|
|
This module is complete. Continue to the next module.
|
|
|
|
## Instructor Notes
|
|
|
|
**Discussion questions for a live classroom:** question 1 is the module's thesis — make sure
|
|
students can actually articulate it in their own words, not just recognize it when stated.
|
|
|
|
**Approximate timing:** 8-10 minutes live discussion; 5 minutes self-paced writing.
|
|
|
|
**Optional extension:** ask students to rank this module's four controls by how much
|
|
IMPLEMENTATION EFFORT each typically requires on a real team, separately from security value —
|
|
a good exercise in real-world prioritization tradeoffs.
|