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]>
41 lines
2.2 KiB
Markdown
41 lines
2.2 KiB
Markdown
# 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
|
|
|
|
1. Before this module, would you have assumed a fresh Kubernetes cluster isolates Pods from
|
|
each other by default? Has that changed?
|
|
2. If your team runs a multi-tenant cluster (several unrelated applications sharing it), what's
|
|
the risk of NEVER applying any NetworkPolicy at all?
|
|
3. 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.
|