What does dropping a container's default privilege set add when the workload already runs under an unprivileged account?

## Two axes, not one Hardening a workload at start has two independent questions, and they get collapsed constantly: - **Which account does the process run under?** That decides what the filesystem and ordinary permission checks allow. - **Which powers does the process hold beyond that account?** That decides which privileged operations the kernel will let it perform regardless of the account, and it is a property of the process itself. A workload can run under an unprivileged id and still hold a slice of superuser powers, because those powers were granted by the runtime when it started the container and nothing about the account emptied them. That is the gap this declaration closes. ## What the default set is for Container runtimes ship a middle setting: a subset of the superuser's powers, granted to every container by default. It exists so that the enormous back catalogue of images that were written assuming a privileged environment still starts. The set typically allows things like binding to a low-numbered network port, changing the ownership of files, altering process identity, and a handful of other classically privileged operations - deliberately excluding the ones that would let a process reconfigure the machine outright. The design goal was compatibility, not your threat model. The set is the same for a workload that needs one of those powers and for the ninety-nine that need none. Note also that platforms differ in what their default set contains and in whether the spec can add powers back at all, so 'the default' is not one fixed list. ## Deny by default, then add back The hardened form is the same shape as every other allowlist: 1. **Drop the entire default set** in the workload spec. 2. **Start the workload and find what breaks.** In most cases nothing does. 3. **Add back exactly one power** if something genuinely needs it, and write down why next to the declaration. 4. **Prefer removing the need** over granting the power: bind a high-numbered port and let the publishing hop present the low one; set file ownership in the build instead of at start-up. Step four is where most of the value is. Almost every reason to keep a power turns out to be a habit inherited from running the same software directly on a host, and the containerised form has a different answer available. ## What breaks first, and what it means | symptom after dropping the set | what it points at | the usual answer | |---|---|---| | the listener fails to bind at start-up | a port below the privileged threshold | bind a high port; publish the low one at the hop in front | | a start-up step cannot change file ownership | ownership being fixed at runtime | fix ownership in the build instead | | a helper cannot change its process identity | a supervisor dropping privilege itself | start as the target id directly; drop the supervisor | | a diagnostic tool reports refusals | tooling that expects a privileged host | keep it out of the workload image | Each row is a design signal as much as a breakage: the workload was relying on a privileged environment, and that reliance is now visible in a spec rather than invisible in an image. ## What the declaration is worth Be precise about the benefit, because overselling it is a common interview stumble: - It **removes a step from an escalation chain**. A process with no powers has fewer paths from code execution to anything that touches the host. - It **makes the intent checkable**. An empty set in the spec is something a reviewer reads in a second and a gate can enforce before start. - It **does not stop the workload doing what it was authorized to do** - reading its data, calling its dependencies, using its credentials - because none of that requires elevated powers. - It **is not the boundary**, and it is not the filter over which kernel calls the process may make. Those are separate controls with separate failure modes. ## The trap The trap is treating the unprivileged account as the whole answer, shipping it, and calling the workload hardened. An unprivileged id with the default powers intact is better than the superuser and materially weaker than the same id with an empty set, and the difference is one line in the spec. The second trap is the mirror image: dropping everything, hitting a bind failure at three in the morning, and restoring the entire set instead of the one power - or better, changing the port so no power is needed at all.