You are setting a container runtime-confinement baseline for an organisation. Which restrictions do you make mandatory by default, how do you roll it out without breaking existing workloads, and how do you handle the workloads that genuinely need more privilege?

## What the baseline is trying to achieve The threat model is not "someone attacks the container from outside". It is: **an attacker already has code execution inside a container** — via an application vulnerability, a dependency, or a poisoned build step. Every control in the baseline answers one question: how much can that attacker do next, and how fast can they reach the node or the neighbouring workloads? The controls are complementary, and the layering matters: | Control | What it removes from the attacker | |---|---| | `cap-drop ALL` | privileged operations (raw sockets, mount, chown, permission bypass) | | `no-new-privileges` | escalation to container-root via setuid binaries | | default seccomp | the escape-relevant syscall surface (mount, keyctl, module loading) | | AppArmor/SELinux | reach to host objects and to other containers' files | | read-only rootfs | dropping tools and persisting a foothold | | no privileged / no host namespaces / no docker socket | the direct routes to host root | None alone is sufficient; together they turn "RCE in a container" from a node compromise into a contained incident. ## Choosing the defaults **Drop all capabilities.** The default fourteen include `NET_RAW` (spoofing against neighbours) and `DAC_OVERRIDE` (reading a mounted secret whose only protection is its file mode). Most services need none. Make zero the default and require justification for each addition. **no-new-privileges** is nearly free and closes the in-container escalation path. Combine it with images that carry no setuid binaries. **Seccomp: default, explicitly stated.** An implicit default is invisible to reviewers and silently disappears under `--privileged`. Requiring the profile to be *named* in the spec makes "unconfined" a visible, reviewable choice. Custom profiles live in version control beside the workload spec. **MAC on.** Pick one LSM per fleet — AppArmor or SELinux, not a mixture — because profile distribution, tooling and debugging skills all differ. Custom profiles ship in the node image, not by hand. **Read-only root filesystem** with explicit `tmpfs` mounts for the few writable paths. This is the control most likely to expose sloppy images, and also the one that most reduces attacker persistence. **Hard nos:** privileged, host PID/network/IPC namespaces, and the Docker socket. Each is a direct path to node root, and each has a legitimate but rare use served better by a dedicated, isolated pool. ## Rolling it out 1. **Inventory first.** You cannot set policy for a fleet you have not measured. Enumerate every workload's current capabilities, seccomp setting, privileged flag, host-namespace usage and socket mounts. The distribution is usually surprising: a small number of legacy workloads account for nearly all violations. 2. **Audit mode before enforcement.** Run the admission policy in warn/audit mode and let it report for a full release cycle. On SELinux hosts, `permissive` gives the equivalent signal at the LSM layer. The output is a per-team list of what would break — concrete, dated, and specific. 3. **Fix the classes centrally.** Failures cluster into a handful of causes: entrypoints doing `chown -R` (fix ownership at build time), `sudo`-based entrypoints (start as the right user), binding port 80 (listen high and map), scratch writes to `/tmp` (add a tmpfs), and images with setuid binaries (strip them in the base). Fixing them in shared base images resolves most of the fleet at once — far cheaper than dozens of independent migrations. 4. **Enforce for new first.** New workloads are cheap to make compliant; existing ones get a dated deadline with the audit report as the work list. 5. **Make it the default, not an option.** Ship a compliant workload template so the secure configuration is what people get by copying an existing service, and keep the policy engine as the backstop rather than the primary mechanism. ## Handling genuine exceptions Some workloads really do need more: storage and network node agents, monitoring agents that need host PID access, build farms. The discipline: - **Narrowest possible grant.** One capability, one `--device`, one host path — never `--privileged` because it is easier. Ask what specific operation failed and grant exactly that. - **Compensating controls.** Put the exception on a dedicated node pool so a compromise does not reach general workloads; restrict who can deploy to it; increase logging around it. - **Named owner and expiry.** An exception with no owner and no date becomes permanent. A dated review forces the question "is this still needed?" at least annually. - **Visibility.** Exceptions belong in a register the security team and the platform team both read, and ideally in a dashboard counting them. The metric that matters is not "is policy enabled" but "how many exceptions exist and are they trending down". ## The tradeoffs to say out loud - **Friction versus breach cost.** A strict baseline creates real work for teams whose images were written casually. The honest answer is that the cost is front-loaded into image fixes and mostly disappears afterwards, whereas the breach cost is unbounded. - **Debuggability.** Hardened containers are harder to troubleshoot — no shell, read-only, no ptrace. Provide a sanctioned path: ephemeral debug containers with elevated settings, short-lived and audited, so engineers do not weaken production specs to get a shell. - **False confidence.** A compliant baseline still shares a kernel. Workloads with genuinely hostile input — untrusted code execution, multi-tenant builds — need stronger isolation such as a sandboxed runtime or a VM boundary, not a stricter flag set. - **Drift.** Baselines decay. Enforcement must be automated in admission and reported continuously, because an unmeasured policy is an aspiration. The defensible summary: make the hardened configuration the default and the path of least resistance, roll it out by measuring before enforcing, and treat every exception as a dated, owned risk rather than a setting.