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.