How much you isolate a workload depends on how much you trust it. Syself Autopilot gives you several options, from the shared-kernel default up to a per-pod virtual machine, plus the per-pod controls that harden any container. This page maps those options and links to the page that configures each. ## Isolation levels | Level | Kernel | Container root on the host | Runs on | | ------------------------------------------- | ---------------- | -------------------------- | --------------- | | Standard runtime (default) | shared with host | host root (UID 0) | every node | | + user namespace (`hostUsers: false`) | shared with host | unprivileged host user | every node | | Secure runtime (`runtimeClassName: secure`) | own guest kernel | isolated in a VM | bare metal only | - **Secure (Kata) runtime** puts each pod in its own lightweight VM with its own kernel, so a container or kernel escape stays trapped in the VM. Use it for untrusted or risky code. See [Container runtimes](/docs/hetzner/apalla/workloads/runtime-classes/container-runtimes). - **User namespaces** remap container root onto an unprivileged host user, so an escape from a root container lands as an unprivileged user on the node instead of host root. Use it when an image must run as root and you cannot change it. See [Run a workload in a user namespace](/docs/hetzner/apalla/workloads/secure/run-in-a-user-namespace). ## Harden every workload Whichever isolation level you pick, a production workload should also set its own security context: run as non-root, drop Linux capabilities, block privilege escalation, and keep the root filesystem read-only. Seccomp and AppArmor are already enforced by default. See [Set security contexts](/docs/hetzner/apalla/workloads/secure/set-security-contexts). To enforce these rules across a whole namespace rather than per pod, apply [Pod Security Standards](/docs/hetzner/apalla/security/enforce-pod-security-standards).