Files

T

ced4568andClaude Sonnet 5 7f6e1857c0 feat(curriculum): Phase 6C module upgrades, security assessment bank, ROOT 11 orientation

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]>

2026-08-26 11:20:17 -05:00

2.4 KiB

Raw Blame History

Guided Exercise: Planning Network Isolation

Paper-and-thinking exercise before the Lab.

The scenario

A database Pod (label app=database) in the netpol namespace should only ever be reachable by Pods labeled role=backend — not the frontend, not anything else in the cluster.

Your task

Before writing any YAML: right now, with NO NetworkPolicy in place, can the frontend reach the database? Why?
What would a NetworkPolicy that ONLY specifies podSelector: { matchLabels: { app: database } } and no ingress rules at all do to traffic reaching the database — including from role=backend Pods?
Sketch (in words, not full YAML) what the ingress rule needs to say to allow ONLY role=backend traffic in.
If a new Pod is later created with role=backend in a DIFFERENT namespace, would your policy as sketched in #3 allow it? What would need to change if cross-namespace access should be allowed?

A worked answer to check yourself against

Yes — by default, every Pod can reach every other Pod regardless of labels or namespace (ROOT 07's Ingress & NetworkPolicy lesson). Nothing restricts this until a policy exists.
It would block ALL incoming traffic to the database, including from role=backend — an empty ingress list under a policy that selects the Pod means "no traffic is allowed in," not "no policy applies."
An ingress rule with from: [{ podSelector: { matchLabels: { role: backend } } }] — this allows traffic specifically from Pods carrying that label, and nothing else.
Not automatically — a bare podSelector in the from clause matches Pods in the SAME namespace as the policy by default. Allowing a different namespace requires adding a namespaceSelector alongside the podSelector in the same from entry.

Instructor Notes

Facilitation: Question 2 is the one most likely to trip students up — it directly reinforces the "empty ingress rules means deny-all, not no-op" point from the lesson, which is worth confirming actually landed before the Lab.

Approximate timing: 10-12 minutes live with discussion; 10 minutes self-paced.

Optional extension: ask what a security-minded team would ALSO want to restrict about this database Pod's OWN outbound (egress) traffic, beyond who can reach it — a light forward pointer to ROOT 09's security-control framing of NetworkPolicy, without requiring students to build an egress rule here.

2.4 KiB Raw Blame History