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]>
1.8 KiB
Knowledge Check: ServiceAccounts & RBAC
1. A Pod is created with no ServiceAccount specified. What identity does it actually run as, and what can that identity do by default?
Answer: The default ServiceAccount in its Namespace, which by default has essentially no
permissions — it can authenticate to the API but is granted nothing until an RBAC binding says
otherwise.
2. You create a Role granting get/list on Pods, but a workload still can't read Pods.
What's the most likely missing piece?
Answer: A RoleBinding (or ClusterRoleBinding) connecting that Role to the workload's actual ServiceAccount. A Role by itself grants nothing to anyone — it has to be bound to an identity.
3. True or false: a ClusterRole can only ever be applied cluster-wide.
Answer: False. A ClusterRole can be bound via a RoleBinding to apply within just ONE Namespace (reusing a cluster-wide-DEFINED permission set in a namespace-SCOPED way), or via a ClusterRoleBinding to apply cluster-wide. The Role-type and Binding-type are independent choices.
4. Why would a security review flag a Role granting verbs: ["*"] on resources: ["*"]
even if the workload "seems to work fine"?
Answer: That grant is root-equivalent API access — it violates least privilege regardless of whether the workload happens to only use a small subset of it today. "Works fine" doesn't mean "correctly scoped" — an over-broad grant is a real risk the moment that workload (or its credentials) is compromised, whether or not it's ever exploited in practice.
Instructor Notes
Facilitation: Question 4 is worth discussing even if everyone answers correctly — the "it works, so what's the problem" instinct is exactly what least-privilege review exists to counter.
Approximate timing: 5 minutes.