Four new modules, moving ROOT 09 off PLANNED and building the 22-scenario CKS-style bank into a coherent course instead of disconnected exam tasks — see docs/ROOT_CURRICULUM_COVERAGE_MATRIX.md for the CORE/GUIDED/INDEPENDENT/ADVANCED/ASSESSMENT-BANK classification behind every placement. root-09-m01-security-model-and-securitycontext — READY, full gold-standard pattern: defense in depth, least privilege, hardening a Pod with SecurityContext. Lesson, demonstration (a Pod before/after hardening), knowledge check, guided exercise (a hardening checklist), real Labs (CORE: non-root/drop-capabilities/read-only-fs/ pod-security-context; GUIDED: seccomp; ADVANCED: AppArmor; INDEPENDENT: the generic pod-security-context duplicate), and a reflection. root-09-m02-serviceaccounts-and-rbac — PARTIAL: workload identity and least-privilege permissions. Lesson + knowledge check + real Labs. root-09-m03-network-and-supplychain-security — PARTIAL: NetworkPolicy as a security control (default-deny), image/registry trust, TLS ingress. Lesson + knowledge check + real Labs. root-09-m04-cluster-hardening-and-runtime — PARTIAL, deliberately survey-depth: Pod Security Admission and a lighter treatment of audit-policy/runtime-sandboxing topics that don't belong in the core daily-driver path. Co-Authored-By: Claude Sonnet 5 <[email protected]>
2.0 KiB
Knowledge Check: Network & Supply Chain Security
1. A NetworkPolicy has podSelector: {} with policyTypes: ["Ingress"] and no ingress rules
defined. What's the practical effect on every Pod in that namespace?
Answer: Every Pod is selected, and since no ingress rule allows anything, all incoming traffic to every Pod is denied — this is the "default deny" starting posture, applied namespace-wide.
2. Why is restricting EGRESS (outbound) traffic from a Pod a real security control, not just a mirror-image nicety of ingress restriction?
Answer: A compromised Pod with unrestricted egress can exfiltrate data to an attacker-controlled destination or call out to download additional malicious payloads. Restricting egress to only what's legitimately needed limits what a compromise can accomplish, independent of whether inbound access was ever an issue.
3. True or false: "default deny, then explicitly allow" and "default allow, then explicitly block known-bad traffic" provide equivalent security given the same set of rules.
Answer: False. Default-deny blocks anything NOT yet explicitly allowed, including new/ unanticipated attempts. Default-allow only blocks what's already been identified as bad — an attacker doing something not yet on the block list gets through under the second model but not the first.
4. Why does minimizing a container image's footprint (fewer packages) improve supply-chain security specifically, rather than just making the image smaller/faster to pull?
Answer: Fewer installed packages means fewer potential known vulnerabilities (CVEs) present in the image at all, and a smaller attack surface if the image is ever compromised — it's a security property, not merely a performance optimization.
Instructor Notes
Facilitation: Question 3 is the core conceptual point of this module — worth confirming it's genuinely understood, not just correctly guessed.
Approximate timing: 5-7 minutes.