Pod Security & SecurityContext

In one line

By default, a container can run as root with broad Linux capabilities — a SecurityContext is how you lock that down per-pod or per-container, and Pod Security Standards enforce a baseline across an entire namespace.

0/4 · 0%

Think of it like this

Giving a new employee a master key to every room in the building on their first day, versus giving them access to only the specific rooms their job actually requires — a container's DEFAULT permissions are much closer to the master key than most people realize until they explicitly lock it down.

Key ideas

01
By default, a container can run AS ROOT inside its own container (Docker's own course already covered why this is genuinely risky, Phase 1.3, if that root user ever escapes the container boundary) and, depending on the runtime, may retain broad LINUX CAPABILITIES (specific root-level privileges like binding to low-numbered ports, changing file ownership, and others) it almost never actually needs.
02
A SECURITYCONTEXT (settable at the pod level, applying to every container, or overridden per-container) is how you actually restrict this: runAsNonRoot: true (refuses to even start the container if its image would run as root), runAsUser: 1000 (forces a specific non-root user ID), readOnlyRootFilesystem: true (the container's own filesystem can't be written to at all, forcing any genuinely needed writable storage through an explicit volume instead), and capabilities: drop: ["ALL"] (strips every Linux capability, adding back only the few genuinely required, if any).
03
This directly extends Docker's own course on non-root containers (Phase 1.3) — the exact same principle, just enforced by Kubernetes at the pod-scheduling level rather than only inside the Dockerfile itself, meaning even an image that WASN'T built with a non-root USER instruction can still be forced to run as non-root at the Kubernetes layer via runAsUser.
04
POD SECURITY STANDARDS define three built-in enforcement levels Kubernetes can apply per NAMESPACE: privileged (no restrictions at all), baseline (blocks the most obviously dangerous configurations, like privileged containers), and restricted (enforces genuinely strong hardening — non-root, no privilege escalation, dropped capabilities, and more) — applied via a simple namespace LABEL, requiring zero per-pod configuration once set.
05
A NAMESPACE labeled with the restricted Pod Security Standard will automatically REJECT any pod that doesn't meet its requirements at creation time — this is a genuinely powerful way to enforce a real security baseline across an entire team or environment's workloads consistently, rather than relying on every single pod manifest remembering to set the right SecurityContext fields individually.

Code & diagrams

securitycontext.yamlmarkdown

A genuinely hardened pod — non-root, no writable root filesystem, no unnecessary Linux capabilities.

apiVersion: v1
kind: Pod
metadata:
  name: hardened-app
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 1000
  containers:
    - name: app
      image: my-registry/my-app:1.5.0
      securityContext:
        readOnlyRootFilesystem: true
        allowPrivilegeEscalation: false
        capabilities:
          drop: ["ALL"]
      volumeMounts:
        - name: tmp
          mountPath: /tmp     # explicit writable space, since the root fs is read-only
  volumes:
    - name: tmp
      emptyDir: {}

pod-security-standard.yamlmarkdown

One label enforces a whole namespace's baseline — no per-pod configuration required.

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

pod-security.shmarkdown

Confirm both a per-pod SecurityContext and a namespace-wide standard actually reject what they should.

kubectl apply -f securitycontext.yaml
kubectl get pod hardened-app -o jsonpath='{.spec.securityContext}'

# Confirm the namespace-level standard actually enforces itself —
# try creating a pod that violates "restricted" in that namespace
kubectl apply -f pod-security-standard.yaml
kubectl run bad-pod --image=nginx -n production --overrides='
{
  "spec": { "securityContext": { "runAsUser": 0 } }
}'
# Error: violates PodSecurity "restricted" — rejected automatically, before scheduling

Explain it without notes

Why does explicitly setting runAsNonRoot: true at the Kubernetes level matter, even for an image that was already built with a non-root USER instruction in its Dockerfile?

What's the practical benefit of enforcing a Pod Security Standard at the namespace level, compared to relying on every individual pod's manifest to set the correct SecurityContext fields?

Practice

Create the example hardened pod and confirm with kubectl get pod ... -o jsonpath its SecurityContext fields are exactly as configured.

Label a test namespace with the restricted Pod Security Standard and confirm a deliberately non-compliant pod (like one requesting runAsUser: 0) is correctly rejected at creation time.

Trade-offs

↔
A restricted Pod Security Standard genuinely closes off a large class of real security risks, but it can break existing images or workloads that were never built with these restrictions in mind (an image that genuinely needs to write to its own root filesystem, for instance) — rolling this out on an established cluster benefits from testing against baseline first, or auditing real workloads before flipping an entire namespace to restricted and potentially blocking legitimate, already-running applications.

Done when you can

I can configure a pod's SecurityContext to run as non-root with a read-only root filesystem and dropped capabilities.
I understand the three Pod Security Standard levels (privileged, baseline, restricted).
I know a namespace-level Pod Security Standard enforces automatically, without relying on individual pod manifests.