ced4568andClaude Sonnet 5
7f6e1857c0
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]>
67 lines
2.1 KiB
Markdown
67 lines
2.1 KiB
Markdown
# Demonstration: A Secret Is Encoded, Not Encrypted
|
|
|
|
## Creating a Secret
|
|
|
|
```
|
|
$ kubectl create secret generic app-secret --from-literal=api-key=supersecret
|
|
secret/app-secret created
|
|
```
|
|
|
|
## Looking at it
|
|
|
|
```
|
|
$ kubectl get secret app-secret -o yaml
|
|
apiVersion: v1
|
|
kind: Secret
|
|
metadata:
|
|
name: app-secret
|
|
data:
|
|
api-key: c3VwZXJzZWNyZXQ=
|
|
type: Opaque
|
|
```
|
|
|
|
## Decoding it — no special permission needed beyond reading the Secret itself
|
|
|
|
```
|
|
$ echo "c3VwZXJzZWNyZXQ=" | base64 -d
|
|
supersecret
|
|
```
|
|
|
|
Anyone who can run `kubectl get secret app-secret -o yaml` (i.e. anyone RBAC allows to READ
|
|
Secrets in this Namespace) can trivially recover the real value with a standard, built-in
|
|
command — no cracking, no special tooling. This is exactly why the lesson's point matters: the
|
|
protection here is WHO can read the Secret object at all (RBAC), not the base64 encoding itself.
|
|
|
|
## Comparing to a ConfigMap
|
|
|
|
```
|
|
$ kubectl get configmap app-config -o yaml
|
|
apiVersion: v1
|
|
kind: ConfigMap
|
|
metadata:
|
|
name: app-config
|
|
data:
|
|
environment: production
|
|
log_level: info
|
|
```
|
|
|
|
A ConfigMap's values are stored in PLAIN TEXT — no encoding step at all. This is consistent with
|
|
ConfigMaps being explicitly for non-sensitive data; there's no pretense of protection to begin
|
|
with.
|
|
|
|
## Instructor Notes
|
|
|
|
**Demo script:** Run this live, actually decoding the value in front of the class — the gap
|
|
between "Secret" (a name implying protection) and what the command output shows is the entire
|
|
point, and it lands far better performed than read.
|
|
|
|
**Approximate timing:** 6-8 minutes live; 5 minutes self-paced.
|
|
|
|
**Common misconception to preempt:** this demonstration directly targets the single most common
|
|
misconception about Kubernetes Secrets — do not skip it even if time is short, since a wrong
|
|
belief here has real security consequences later.
|
|
|
|
**Optional extension:** ask what a `SealedSecret` or an external secrets manager (mentioned by
|
|
name only, not built as a hands-on topic here) is trying to solve that a plain Kubernetes Secret
|
|
does not — a good forward pointer without requiring new infrastructure in this course.
|