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]>
45 lines
1.8 KiB
Markdown
45 lines
1.8 KiB
Markdown
# 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.
|