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](/docs/hetzner/apalla/security/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](/docs/hetzner/apalla/workloads/secure/run-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](/docs/hetzner/apalla/workloads/secure/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](/docs/hetzner/apalla/security/set-security-contexts)
- [Run a workload in a user namespace](/docs/hetzner/apalla/workloads/secure/run-in-a-user-namespace)
- [Run in the secure runtime](/docs/hetzner/apalla/workloads/secure/run-in-the-secure-runtime)
- [Enforce Pod Security Standards](/docs/hetzner/apalla/security/enforce-pod-security-standards)