11.2 Container Runtime Security
A focused guide to Container Runtime Security, connecting core concepts with practical Docker and container operations.
Container runtime security covers the practices that limit what a running container can actually do — restricting privileges, capabilities, and resource access — reducing the potential impact if a containerized application were ever compromised, complementing image-level security practices that focus on the content before a container even starts.
Running as a Non-Root User
Specifying a non-root user for the running container limits what a compromised process could do, even within the container's own namespace.
USER appuser
Dropping Unnecessary Linux Capabilities
A container's default capability set includes more than most applications actually need — explicitly dropping unneeded capabilities reduces what a compromised process could accomplish.
docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE myapp:1.0
This drops every capability by default, then adds back only the one specifically needed, rather than running with the broader default set.
Avoiding Privileged Mode
Privileged mode grants a container nearly unrestricted access to the host, appropriate only for very specific, deliberate use cases, and something to avoid for an ordinary application container.
docker run --privileged myapp:1.0
This should be a clear exception, not a default, given how significantly it expands what the container can affect.
Limiting Resource Consumption
Setting explicit resource limits prevents a single container from being able to exhaust host resources, whether through a bug or malicious behavior.
docker run --memory=512m --cpus=1 myapp:1.0
Using Read-Only Root Filesystems Where Possible
Mounting a container's root filesystem as read-only, with explicit writable mounts only where genuinely needed, limits what a compromised process could actually modify.
docker run --read-only --tmpfs /tmp myapp:1.0
Why Container Runtime Security Matters
These runtime restrictions provide essential defense-in-depth, limiting the potential consequences of a security issue that does occur, complementing image-level security practices that aim to prevent vulnerabilities from being present in the first place.