11.2.2.5 Least Privilege Runtime

Least privilege runtime is the overall practice of configuring a container with exactly the privileges its application genuinely needs and nothing more, combining non-root execution, minimal capabilities, avoidance of privileged mode, and other restrictions into a single, coherent runtime security posture.

Combining Multiple Restrictions Into a Coherent Configuration

A genuinely least-privilege runtime configuration applies several restrictions together, each addressing a different dimension of potential privilege.

docker run \
  --user 1000:1000 \
  --cap-drop=ALL \
  --cap-add=NET_BIND_SERVICE \
  --security-opt=no-new-privileges \
  --read-only \
  --tmpfs /tmp \
  myapp:1.0

This single command reflects several distinct least-privilege practices applied together: non-root execution, minimal capabilities, prevention of privilege escalation, and a read-only root filesystem.

Expressing the Same Configuration Through Compose

The same combination of restrictions can be expressed declaratively within a Compose service definition, keeping this security posture clearly documented as part of the application's configuration.

services:
  api:
    user: "1000:1000"
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE
    security_opt:
      - no-new-privileges
    read_only: true
    tmpfs:
      - /tmp

Why This Combination Matters More Than Any Single Restriction Alone

Each individual restriction closes off a different category of potential misuse — combined, they provide considerably more comprehensive protection than relying on just one or two of these practices in isolation.

docker run --user 1000:1000 myapp:1.0

This single restriction alone, while valuable, leaves several other categories of potential privilege unaddressed compared to the fuller combination shown above.

Why Establishing This as a Standard Pattern Matters

Defining a consistent, least-privilege baseline configuration that's applied across an organization's containers by default, rather than relying on individual developers to remember and apply each restriction separately, produces more reliable, comprehensive protection.

Why Least Privilege Runtime Matters

Bringing together the full range of available privilege-reduction practices into one coherent, consistently applied configuration represents the most effective overall approach to container runtime security, providing layered, comprehensive protection rather than relying on any single restriction in isolation.