# Pod Security Admission & a Survey of Runtime Hardening

This module is deliberately a survey, not a deep dive — the topics here are real and important,
but lean toward cluster-operator/platform-team concerns rather than the daily-driver skills most
ROOT_ learners will use constantly. Treat the labs in this module as good-to-know, not required
mastery, before moving on.

## Pod Security Admission: enforcing a baseline across a Namespace

Everything you configured by hand in earlier modules (non-root, dropped capabilities, read-only
filesystem) can also be ENFORCED automatically at the Namespace level via **Pod Security
Admission (PSA)** — a label on the Namespace itself that rejects any Pod violating a chosen
security standard (`privileged`, `baseline`, or `restricted`, from least to most strict):

```yaml
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
```

This replaces the older PodSecurityPolicy (PSP) mechanism, which was removed from Kubernetes —
if you encounter PSP in older documentation or an older cluster, know that PSA is its current
replacement.

## Immutable Secrets: preventing a class of accidental change

A Secret can be marked `immutable: true`, which prevents its data from being changed after
creation (a new Secret with a new name has to be created instead, and workloads updated to
reference it). This trades a small amount of operational flexibility for a real safety
property: an accidental or malicious edit to a live Secret can't silently happen.

## A survey of further topics (labs available, treat as optional depth)

- **Audit policy** — configuring what the Kubernetes API server logs about requests made against
  it (who did what, when) — genuinely important for incident investigation, but a cluster-admin
  concern, not something most workload teams configure themselves.
- **RuntimeClass** — lets specific Pods run under a different container runtime configuration
  (e.g. an extra-sandboxed runtime like gVisor or Kata Containers) for workloads that need
  stronger isolation than the default runtime provides — relevant mainly for genuinely
  untrusted or high-risk workloads, not typical applications.

## Instructor Notes

**Approximate timing:** 15 minutes read (shorter than other lessons — deliberately survey-depth).

**Framing for instructors:** Be explicit with students that this module is intentionally
lighter than the earlier ones in this course — the goal is awareness ("this exists, here's
roughly what it's for") rather than hands-on fluency, consistent with not every CKS-style topic
belonging in the core learning path.

**Discussion question:** "Why would a platform team prefer enforcing security standards via
Pod Security Admission at the Namespace level, instead of trusting every team to configure
SecurityContext correctly on every Pod by hand?" (Answer: PSA provides a hard backstop —
correctly-configured SecurityContext relies on every individual Pod author doing it right every
time; PSA rejects violations automatically regardless of whether any individual author
remembered to.)

**Optional extension:** ask which of `privileged`/`baseline`/`restricted` a team should start a
brand-new, security-conscious project with, and why not jump straight to the strictest option
on a cluster already running older, unaudited workloads (a good practical judgment question
about migration risk, not just definitions).