ced4568andClaude Sonnet 5
960a638ec9
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]>
46 lines
2.0 KiB
Markdown
46 lines
2.0 KiB
Markdown
# 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.
|