Pod Security and Admission Control

Why this matters

02/09 taught you to build a non-root, minimal image. But building an image that could run non-root doesn't stop someone from deploying it with root privileges, or with a hostPath mount that reaches the node's filesystem, or with privileged: true that effectively hands over the host. The image is one control; the runtime security context the cluster allows is another — and until now nothing in this curriculum enforced the second. This module closes that gap two ways: the per-Pod securityContext (what a Pod declares about itself) and Pod Security Admission (what the cluster refuses to admit in the first place). This is your first admission-control layer, and it sets up the policy-as-code depth of module 04.

Concepts

securityContext: what a Pod declares about how it runs

03/11 scoped API permissions with RBAC. securityContext is different — it constrains the Linux process the container runs as, at the kernel level. Set at the Pod or container level, the fields that matter most for hardening:

• runAsNonRoot: true — refuse to start if the image would run as UID 0, enforcing 02/09's non-root lesson at runtime even if someone forgot the USER line in the Dockerfile.
• runAsUser: <uid> / runAsGroup: <gid> — pin the exact UID/GID.
• allowPrivilegeEscalation: false — block a process from gaining more privileges than its parent (e.g. via setuid binaries) — closes a common escalation path (STRIDE's E, module 00).
• readOnlyRootFilesystem: true — mount the container's root filesystem read-only, so an attacker who lands code execution can't write a tool, a web-shell, or a cron job into it. Anything the app legitimately writes must go to an explicitly-mounted emptyDir/volume.
• capabilities.drop: ["ALL"] — drop all Linux capabilities and add back only the few (if any) the app truly needs. (More on capabilities next.)
• seccompProfile.type: RuntimeDefault — apply a syscall filter (more below).

The key mental shift: a hardened image and a hardened securityContext are two independent layers (defense in depth, module 00). You want both.

Linux capabilities: root's powers, split into pieces

Traditional Linux is all-or-nothing: root (UID 0) can do everything, everyone else is restricted. Capabilities break root's power into ~40 distinct units (CAP_NET_BIND_SERVICE to bind ports below 1024, CAP_SYS_ADMIN the famously-broad "almost-root", CAP_CHOWN, etc.). By default Docker/Kubernetes grant a container a subset of these — more than most apps need. Best practice is drop: ["ALL"] and then add back only the specific capability the app requires (very often none). A web server that binds port 8080 needs zero capabilities; one binding port 80 needs only NET_BIND_SERVICE — never the full default set. Fewer capabilities = smaller elevation-of-privilege surface.

seccomp: filtering which syscalls a container may make

Every interaction between a program and the kernel is a syscall. seccomp (secure computing mode) installs a filter that restricts which syscalls a container can make, blocking the exotic ones that exploits rely on while allowing the normal ones apps use. seccompProfile.type: RuntimeDefault applies the container runtime's curated default profile — a large risk reduction for almost no effort, yet it's off unless you ask for it. This is kernel-level attack-surface reduction, the same philosophy as minimal images (02/09) applied to the syscall interface instead of installed packages.

The dangerous knobs: privileged, host namespaces, hostPath

Some Pod settings effectively dissolve the container boundary and should be treated as near-equivalent to giving away the node:

• privileged: true — disables most isolation; the container gets nearly full access to the host kernel and devices. A privileged container escape is a node compromise.
• hostNetwork: true / hostPID: true / hostIPC: true — share the node's network/process/IPC namespaces, so the container can see and interfere with the host and other Pods.
• hostPath volumes — mount a path from the node's filesystem into the Pod; mounting / or /var/run/docker.sock is a classic escape-to-node path.

These exist for legitimate infra Pods (CNI, monitoring — recall your module-00 surface inventory found them). The point of admission control is to ensure only those blessed workloads get them, never a random app Deployment.

Pod Security Admission (PSA) and the three Standards

Enforcing all of the above by hand on every Pod doesn't scale. Pod Security Admission is a built-in Kubernetes admission controller (GA since 1.25) that enforces the Pod Security Standards — three predefined profiles — at the namespace level:

• privileged — no restrictions (for trusted infra workloads).
• baseline — blocks the most dangerous, obviously-bad settings (privileged, host namespaces, most hostPath) while staying broadly compatible with common apps.
• restricted — the hardened profile: requires runAsNonRoot, allowPrivilegeEscalation: false, capabilities.drop: ["ALL"], a seccomp profile, and more — essentially the full securityContext hardening above.

You opt a namespace into a Standard with labels, and PSA acts in one of three modes per Standard:

• enforce — reject Pods that violate the Standard (hard block).
• audit — allow them but record a violation in the audit log.
• warn — allow them but return a Warning to the user who applied them.

You can set different Standards for different modes on the same namespace — a common rollout pattern is warn/audit at restricted first (to see what would break) while still enforceing baseline, then tightening enforce to restricted once you've fixed the violations. This graduated approach is the same audit-then-enforce idea you'll see again in Gatekeeper (module 04) and Azure Policy (module 05).

PSA vs. the old PodSecurityPolicy, and where Gatekeeper fits

If you read older material: PodSecurityPolicy (PSP) was the previous mechanism and is removed (gone in 1.25+). PSA replaced it. PSA is simple and built-in but rigid — you get exactly the three Standards, no custom rules. When you need a rule PSA doesn't express ("images must come from our ACR", "every Pod must have a team label"), you reach for a general policy engine — OPA/Gatekeeper (module 04) or Azure Policy's Gatekeeper-based AKS add-on (module 05). PSA handles the common Pod-hardening baseline cheaply; Gatekeeper handles everything custom. Use PSA for what it covers and Gatekeeper for the rest — they layer.

Command reference

Flag breakdown for kubectl label ns prod pod-security.kubernetes.io/enforce=restricted pod-security.kubernetes.io/warn=restricted:

• label ns prod — applies labels to the prod namespace (PSA is configured entirely through namespace labels).
• pod-security.kubernetes.io/enforce=restricted — any Pod created in prod that violates the restricted Standard is rejected at admission.
• pod-security.kubernetes.io/warn=restricted — additionally return a warning to whoever applies a violating Pod; harmless to set alongside enforce and useful because the warning explains which rule failed.

Flag breakdown for the hardened container securityContext:

• runAsNonRoot: true — kubelet refuses to start the container if its effective user is UID 0.
• allowPrivilegeEscalation: false — sets no_new_privs, so no child process can gain privileges beyond the container's (blocks setuid escalation).
• capabilities: { drop: ["ALL"] } — start from zero Linux capabilities; add back only specific ones the app proves it needs.
• seccompProfile: { type: RuntimeDefault } — enable syscall filtering using the runtime's default allowlist.
• readOnlyRootFilesystem: true — the container can't write to its own root FS; pair with an emptyDir mounted at any path the app must write to.

Hands-on exercises

All run on your local kind cluster from track 03 — PSA is built in, no add-on needed. No Azure cost here.

1. (WSL2) Create test namespaces at two Standards.

   kubectl create namespace psa-baseline
   kubectl create namespace psa-restricted
   kubectl label ns psa-baseline pod-security.kubernetes.io/enforce=baseline
   kubectl label ns psa-restricted pod-security.kubernetes.io/enforce=restricted pod-security.kubernetes.io/warn=restricted
   kubectl get ns --show-labels | grep psa-
   

   Expect both namespaces labeled with their enforce Standard.

2. (WSL2) Watch baseline block a privileged Pod.

   kubectl apply -n psa-baseline -f - <<'EOF'
   apiVersion: v1
   kind: Pod
   metadata: {name: bad-privileged}
   spec:
     containers:
       - name: c
         image: busybox:1.36
         command: ["sleep","3600"]
         securityContext: {privileged: true}
   EOF
   

   Expect the API server to reject it with a Pod Security violation naming privileged. The dangerous knob from Concepts is blocked at admission, not at runtime — it never gets scheduled.

3. (WSL2) Watch restricted block an ordinary-looking Pod. A plain Pod that's fine under baseline fails restricted:

   kubectl apply -n psa-restricted -f - <<'EOF'
   apiVersion: v1
   kind: Pod
   metadata: {name: plain-pod}
   spec:
     containers:
       - name: c
         image: busybox:1.36
         command: ["sleep","3600"]
   EOF
   

   Expect rejection listing multiple violations: missing runAsNonRoot, missing allowPrivilegeEscalation: false, capabilities not dropped, no seccomp profile. restricted demands the full hardening — a bare Pod doesn't qualify.

4. (WSL2) Make it pass restricted with a proper securityContext.

   kubectl apply -n psa-restricted -f - <<'EOF'
   apiVersion: v1
   kind: Pod
   metadata: {name: hardened-pod}
   spec:
     securityContext:
       runAsNonRoot: true
       runAsUser: 1000
       seccompProfile: {type: RuntimeDefault}
     containers:
       - name: c
         image: busybox:1.36
         command: ["sleep","3600"]
         securityContext:
           allowPrivilegeEscalation: false
           capabilities: {drop: ["ALL"]}
           readOnlyRootFilesystem: true
   EOF
   kubectl get pod hardened-pod -n psa-restricted
   

   Expect it to be admitted and reach Running. This is the exact securityContext shape the restricted Standard requires — memorize its shape; you'll write it constantly.

5. Diagnose and fix: read-only root filesystem breaks a legitimate app. Deploy an app that writes to disk under readOnlyRootFilesystem: true:

   kubectl apply -n psa-restricted -f - <<'EOF'
   apiVersion: v1
   kind: Pod
   metadata: {name: writer}
   spec:
     securityContext: {runAsNonRoot: true, runAsUser: 1000, seccompProfile: {type: RuntimeDefault}}
     containers:
       - name: c
         image: busybox:1.36
         command: ["sh","-c","echo data > /var/cache/out.txt && sleep 3600"]
         securityContext:
           allowPrivilegeEscalation: false
           capabilities: {drop: ["ALL"]}
           readOnlyRootFilesystem: true
   EOF
   kubectl logs writer -n psa-restricted
   

   Expect a Read-only file system error — the app legitimately needs to write, but the root FS is locked. Diagnose: the fix is not to remove the hardening but to give the app a writable volume where it needs one:

   kubectl delete pod writer -n psa-restricted
   kubectl apply -n psa-restricted -f - <<'EOF'
   apiVersion: v1
   kind: Pod
   metadata: {name: writer}
   spec:
     securityContext: {runAsNonRoot: true, runAsUser: 1000, seccompProfile: {type: RuntimeDefault}}
     containers:
       - name: c
         image: busybox:1.36
         command: ["sh","-c","echo data > /var/cache/out.txt && sleep 3600"]
         securityContext:
           allowPrivilegeEscalation: false
           capabilities: {drop: ["ALL"]}
           readOnlyRootFilesystem: true
         volumeMounts: [{name: cache, mountPath: /var/cache}]
     volumes: [{name: cache, emptyDir: {}}]
   EOF
   kubectl logs writer -n psa-restricted; kubectl get pod writer -n psa-restricted
   

   Expect no error and Running. The lesson: read-only root FS plus explicit writable mounts is the pattern — you keep the hardening and let the app write where it must.

6. (WSL2) Prove capability dropping actually restricts the container. Compare a default Pod against one with NET_RAW dropped by trying to ping (ping needs CAP_NET_RAW):

   kubectl run cap-test --image=busybox:1.36 --restart=Never -n psa-baseline -- sh -c "ping -c1 127.0.0.1; sleep 3600"
   kubectl logs cap-test -n psa-baseline
   

   Then a version with capabilities dropped:

   kubectl apply -n psa-baseline -f - <<'EOF'
   apiVersion: v1
   kind: Pod
   metadata: {name: cap-test-dropped}
   spec:
     containers:
       - name: c
         image: busybox:1.36
         command: ["sh","-c","ping -c1 127.0.0.1; sleep 3600"]
         securityContext: {capabilities: {drop: ["ALL"]}}
   EOF
   kubectl logs cap-test-dropped -n psa-baseline
   

   Expect the first to ping successfully and the second to fail with an operation-not-permitted error — visible proof that dropping capabilities removed a real kernel power.

7. (WSL2) Preview impact before enforcing — the safe rollout. Before flipping an existing namespace to restricted, see what would break using warn/dry-run:

   kubectl label --dry-run=server --overwrite ns psa-baseline pod-security.kubernetes.io/enforce=restricted
   

   Expect warnings listing existing Pods in psa-baseline that would be rejected under restricted — without actually enforcing it. This is the audit-then-enforce discipline: measure blast radius before you tighten.

8. (WSL2) Clean up.

   kubectl delete namespace psa-baseline psa-restricted
   

Independent challenge

No YAML given — build it yourself using this module plus 02/09 (non-root images) and module 00 (defense in depth). Take a small web app image and deploy it into a namespace enforcing the restricted Pod Security Standard, such that the Pod is admitted and runs correctly while satisfying every restricted requirement — non-root, no privilege escalation, all capabilities dropped (add back only what it genuinely needs, if anything), seccomp RuntimeDefault, and a read-only root filesystem with writable volumes only where the app actually writes. Then deliberately introduce a violation (e.g. flip on privileged or remove runAsNonRoot), observe the exact admission error, and explain which STRIDE category (module 00) that blocked setting would have exposed. Finally, describe in two sentences why enforcing this at the namespace admission layer is stronger than merely building a non-root image — i.e., what admission control catches that image hardening alone cannot.

Common mistakes & troubleshooting

• Assuming a non-root image can't be run privileged. The image says how it would run by default; a Pod spec can still request privileged: true, root, or host namespaces. Only admission control (securityContext + PSA/enforce) actually prevents that at deploy time.
• Flipping a live namespace straight to enforce=restricted. You'll reject existing workloads that don't yet meet it, causing an outage. Use warn/audit/--dry-run=server first to measure the blast radius, fix the workloads, then enforce.
• Removing hardening to fix a write error. A readOnlyRootFilesystem failure means add a writable emptyDir/volume at the path the app needs — not turn the root FS writable again. Keep the control; carve out the exception narrowly.
• drop: ["ALL"] then wondering why the app broke. Some apps need one specific capability (e.g. NET_BIND_SERVICE for port 80). Drop all, then add back the minimum — don't restore the whole default set.
• Forgetting seccomp is off by default. RuntimeDefault is a large, near- free win, but you must set it explicitly; a Pod with no seccompProfile runs Unconfined and fails restricted.
• Expecting PSA to enforce custom rules. PSA only knows the three fixed Standards. "Images must come from our ACR" or "every Pod needs a team label" require Gatekeeper (module 04) or Azure Policy (module 05) — PSA can't express them.
• Labeling the wrong namespace / typo in the label key. PSA is silent if the label key is misspelled — pod-security.kubernetes.io/enforce must be exact, or the Standard simply isn't applied and nothing is blocked.

Checkpoint quiz

Write down your answer to each question before expanding it — checking without attempting first is the single easiest way to fool yourself into thinking you've learned this.

Next

Continue to 04-policy-as-code-opa-gatekeeper — PSA gave you three fixed profiles; now write your own admission rules to block the misconfigurations PSA can't express.