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]>
2.2 KiB
Reflection: Reachability Should Be a Decision, Not a Default
You just configured real Ingress routing and real network isolation. Take a few minutes to connect this to production thinking.
Reflection questions
- Before this module, would you have assumed a fresh Kubernetes cluster isolates Pods from each other by default? Has that changed?
- If your team runs a multi-tenant cluster (several unrelated applications sharing it), what's the risk of NEVER applying any NetworkPolicy at all?
- Ingress lets many different domains share one entry point. What's the operational benefit of that beyond just "fewer objects to manage"?
Real Ops takeaway
"No NetworkPolicy" is not neutral — it's full reachability. Exactly like an unhardened Pod's SecurityContext (ROOT 09 covers this in depth), the absence of a NetworkPolicy isn't a safe default; it's the MOST permissive configuration available. On any cluster where more than one team or application shares infrastructure, that's a real, often-overlooked exposure.
Centralizing external entry points through Ingress reduces attack surface, not just object count. Every separate LoadBalancer Service is a separate externally-reachable endpoint to secure, monitor, and patch. Routing through one (or a small number of) Ingress controllers means security controls — TLS termination, rate limiting, WAF rules — are configured and audited in one place instead of scattered across every application team's own Service definitions.
This module is complete. Continue to the next module.
Instructor Notes
Discussion questions for a live classroom: question 2 is worth pushing on with a concrete scenario — ask what a compromised low-value application (a demo app, a staging environment) could reach on a cluster with zero NetworkPolicies, versus one with sensible defaults.
Approximate timing: 8 minutes live discussion; 5 minutes self-paced writing.
Optional extension: ask students to sketch (in words) what a reasonable DEFAULT-DENY policy for an entire new namespace would look like, before any application-specific allow rules are added — previews the security-control framing ROOT 09 builds on.