securityContext and Pod Security Standards

## The setting Every container in a Kubernetes pod eventually becomes an ordinary Linux process on some node. `securityContext` is the block that decides the identity and privileges of that process. It exists in two places: on the **pod** (`spec.securityContext`), where it applies to all containers and to volume ownership, and on each **container** (`spec.containers[].securityContext`), where it overrides the pod-level value for that container only. - `runAsUser: 10001` — start the process with numeric UID 10001. This overrides whatever `USER` the container image declared. - `runAsGroup: 10001` — the primary GID. - `runAsNonRoot: true` — a *validation*, not an assignment. At container-creation time the kubelet resolves the effective user; if it is UID 0 it refuses to start the container and the pod reports `CreateContainerConfigError` with a message about running as root. If the image only specifies a user by *name* (e.g. `USER app`) and no `runAsUser` is given, the kubelet cannot resolve it to a number before start and also fails the check — which is why hardened images set a numeric `USER`. - `fsGroup: 10001` — a supplemental GID applied to mounted volumes; the kubelet chgrp's and setgid's the volume so a non-root process can write to it. ## Why UID 0 is the thing to avoid Containers are not virtual machines. All containers on a node share the host kernel; isolation comes from namespaces (what you can see) and cgroups (what you can consume), plus capabilities, seccomp and LSMs (what you can ask the kernel to do). Unless user namespaces are enabled to remap IDs, **UID 0 inside the container is UID 0 in the kernel's eyes**. So: - Any kernel vulnerability or misconfigured mount that lets the process reach host resources is exercised as root. - A `hostPath` volume mounted by a root process can read or rewrite host files — including kubelet config or the container runtime socket. - Root retains a large default capability set (`CHOWN`, `SETUID`, `DAC_OVERRIDE`, `NET_RAW`, …), which is the raw material for most privilege escalation chains. Running as an unprivileged UID does not by itself prevent escape, but it removes the cheap paths and makes the remaining ones need a second bug. ## Practical consequences Most breakages when you flip a workload to non-root are file permissions: - The image writes to a directory owned by root (e.g. `/var/run`, `/app/tmp`). Fix in the Dockerfile by `chown`ing to the runtime UID, or mount an `emptyDir` and use `fsGroup`. - The app binds port 80. An unprivileged process cannot bind ports below 1024 without `CAP_NET_BIND_SERVICE`; the clean fix is to listen on 8080 and let the Service map 80 → 8080. - The image expects a matching entry in `/etc/passwd` for the UID. Most software tolerates a missing entry; some (git, some JVM tooling) does not, so add a passwd entry at build time or use an image built for arbitrary UIDs. ## How it relates to the wider hardening set `runAsNonRoot` is one field among several that the Pod Security Standards' *restricted* level requires, alongside dropping all Linux capabilities, forbidding privilege escalation, and setting a seccomp profile. It is the first one to adopt because it is the easiest to reason about and catches the largest class of mistakes. Note the two-layer nature: `runAsNonRoot` is enforced by the **kubelet at start time** on a per-container basis, whereas Pod Security Admission rejects the pod earlier, at the API server, before it is ever scheduled. Both firing on the same field is normal — admission gives the fast, clear rejection, the kubelet is the backstop for anything that got past it. ## Verifying `kubectl exec <pod> -- id` shows the effective UID/GID at runtime. In a review, grep manifests for pods with no `securityContext` at all — an unspecified `runAsUser` means "whatever the image says", and a large share of public images still say root.