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 ready-to-use restricted Deployment, and the rationale for each setting are all 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 

• Set security contexts
• Run a workload in a user namespace
• Container runtimes
• Enforce Pod Security Standards