Chapter 07: Security Context & Pod Hardening

Why This Chapter Exists

Container defaults are not production-safe. This chapter enforces baseline pod hardening:

• non-root execution
• read-only root filesystem where possible
• dropped Linux capabilities
• runtime-default seccomp

Incident Hook

A container compromise lands shell access inside a pod. If the pod runs with broad privileges, escalation is fast. If security context is hardened, attacker movement is constrained. This chapter teaches those constraints as default behavior.

What AI Would Propose (Brave Junior)

• “Set privileged: true just for debugging.”
• “Disable readOnlyRootFilesystem to make tools work quickly.”
• “Run as root for this one release.”

Why this sounds reasonable:

• fixes permissions fast
• removes immediate deploy friction

Why This Is Dangerous

• privilege shortcuts create direct escalation paths.
• root + writable filesystem increases persistence options after compromise.
• temporary relaxations are often never rolled back.

Guardrails That Stop It

• runAsNonRoot: true for pod and container.
• allowPrivilegeEscalation: false.
• capabilities.drop: [ALL].
• seccompProfile: RuntimeDefault.
• writable paths only via explicit volumes (/tmp, runtime/cache dirs).

Golden Baseline vs Insecure Diff

Secure baseline (minimum):

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]
  seccompProfile:
    type: RuntimeDefault

Insecure anti-pattern:

• runAsUser: 0 / root by default
• privileged: true
• writable root filesystem with broad capabilities

Repo Mapping

Platform repository references:

• Backend deployment hardening
• Frontend deployment hardening
• Namespace baseline manifests

Current Implementation (This Repo)

• Backend is non-root, read-only root FS, dropped capabilities, seccomp runtime default.
• Frontend is non-root, read-only root FS, dropped capabilities, seccomp runtime default.
• Writable paths are explicitly mounted through emptyDir volumes.

Safe Workflow (Step-by-Step)

1. Start from hardened baseline manifest and compare any requested exception as diff.
2. Validate pod/container security context before rollout.
3. If app fails from permissions, add explicit writable volume path instead of root/privileged mode.
4. Re-run workload and confirm it remains non-root with dropped caps.
5. Document why any exception exists and expiration/removal plan.

Break/Fix Drill Focus

• Intentionally trigger one permission failure with hardened settings.
• Fix it without root or privileged mode.
• Capture before/after manifest diff as evidence.

Lab Files

• lab.md
• quiz.md

Done When

• learner can prove both workloads run non-root with hardened contexts
• learner can diagnose and fix permission failures without enabling root
• learner can explain why privileged shortcuts are rejected