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

Raw Permalink Blame History

Guided Exercise: Planning Egress Restriction

Paper-and-thinking exercise before the Labs.

The scenario

A payment-processor Pod handles sensitive transactions. It legitimately needs to reach:

an internal payments-db Service, and
one external payment gateway API.

It should NOT be able to reach anything else — including the public internet in general, other internal services, or any other namespace.

Your task

Why is restricting this Pod's OUTBOUND (egress) traffic just as important as restricting who can reach IT (ingress), given what this Pod handles?
If this Pod were compromised via a vulnerable dependency, what would UNRESTRICTED egress let an attacker do that restricted egress would prevent?
Sketch (in words) what an egress policy for this Pod needs to allow, and — just as important — what it must NOT allow by omission.
Why might a security review flag a Pod with policyTypes: ["Egress"] but an EMPTY egress list as suspicious, rather than assume it's simply "not configured yet"?

A worked answer to check yourself against

A Pod handling sensitive data that's compromised is far more dangerous if it can freely exfiltrate that data anywhere (unrestricted egress) than if its only reachable destinations are pre-approved and narrow.
Unrestricted egress would let an attacker exfiltrate transaction data to an external server, or download additional malicious tooling. Restricted egress limits it to only the pre-approved destinations, even after compromise.
Allow: egress to payments-db (internal, by label/namespace selector) and the specific external payment gateway (by IP range or, if supported, a domain-based egress rule). Must NOT allow: general internet access, other internal Services, or any other namespace by default.
An empty egress list under policyTypes: ["Egress"] means DENY ALL outbound — exactly like the ingress case from the lesson. A reviewer seeing this should confirm it's intentional (a Pod that genuinely needs zero outbound network access) rather than assume it's an oversight, since the two look identical in the YAML.

Instructor Notes

Facilitation: Question 4 reinforces the same "empty rules list means deny-all, not unconfigured" point from earlier lessons — a good moment to confirm it generalizes correctly to egress, not just ingress.

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

Optional extension: ask what additional control (beyond NetworkPolicy) a team might want for truly sensitive egress, like restricting DNS resolution itself for this Pod — a forward pointer to defense-in-depth without requiring a hands-on Lab here.

2.7 KiB Raw Permalink Blame History