Set security contexts on a workload
Security contexts are the per-pod step in the workload-hardening ladder. Once you have chosen a runtime and decided whether a pod needs a user namespace, security contexts set what each container may do at the kernel level: run as non-root, drop capabilities, block privilege escalation, and keep the root filesystem read-only. The platform sets none of them, so every workload that handles real traffic or untrusted input adds its own.
The fields, a copy-paste restricted Deployment, and the reasoning behind each setting live on one page: Set security contexts . It covers non-root users, privilege escalation, Linux capabilities, read-only root filesystems, seccomp, and AppArmor, and how to enforce them across a namespace with Pod Security Standards.
Where it sits in the ladder#
- Run a workload in a user namespace remaps container root to an unprivileged host user, for an image that must run as root.
- Run in the secure runtime isolates untrusted code in a lightweight VM.
- Security contexts harden the pod itself. This is the baseline every production workload should carry, on top of whichever runtime and namespace choice you made above.
Related#
Run in the secure (Kata) runtime
Run a pod in its own lightweight VM with its own kernel, so a kernel-level escape stays trapped inside the sandbox instead of reaching the host.
Provide config with ConfigMaps and Secrets
Inject config and sensitive values into pods: env vars vs. files, live updates, and what a Secret actually protects.