Docker Security Features: Capabilities, Image Signing, AppArmor, Seccomp, User Namespaces and More

Background – Docker is one of the most security‑focused container runtimes and ships with a set of default hardening options such as Linux kernel capability restrictions, Seccomp system‑call filtering, AppArmor MAC policies, ulimit and PID limits, image signing, and SELinux support.

Although Docker isolates containers with six namespace mechanisms, some resources (e.g., /proc , /sys , device nodes) are not fully isolated, so Docker adds extra security layers that are described below.

1. Linux kernel Capability restrictions – Docker can drop all capabilities from a container and only add the ones required. This limits the root user inside the container. The --privileged flag grants the container full host capabilities, while --cap-add and --cap-drop allow fine‑grained control.

lynzabo@ubuntu:~$ docker run --rm --name def-cap-con1 -d alpine /bin/sh -c "while true;do echo hello; sleep 1;done"
... (container ID) ...
lynzabo@ubuntu:~$ docker inspect def-cap-con1 -f '{{.State.Pid}}'
43482
lynzabo@ubuntu:~$ cat /proc/43482/status | grep Cap
CapInh:    00000000a80425fb
CapPrm:    00000000a80425fb
CapEff:    00000000a80425fb
CapBnd:    00000000a80425fb
CapAmb:    0000000000000000

When the container is started with --privileged , the capability bitmap matches that of a full host root user and all host device nodes become visible inside the container.

lynzabo@ubuntu:~$ docker run --privileged --rm --name pri-cap-con1 -d alpine /bin/sh -c "while true;do echo hello; sleep 1;done"
... (container ID) ...
lynzabo@ubuntu:~$ docker inspect pri-cap-con1 -f '{{.State.Pid}}'
44312
lynzabo@ubuntu:~$ cat /proc/44312/status | grep Cap
CapInh:    0000003fffffffff
CapPrm:    0000003fffffffff
CapEff:    0000003fffffffff
CapBnd:    0000003fffffffff
CapAmb:    0000000000000000

Because --privileged grants excessive rights, it should be used sparingly. Specific devices can be exposed with --device , e.g., docker run --device=/dev/snd:/dev/snd … , and individual capabilities can be added or removed with --cap-add / --cap-drop .

2. Image signing (Docker Content Trust) – Since Docker 1.8, images can be signed with Notary. Enabling content trust (e.g., export DOCKER_CONTENT_TRUST=1 ) forces docker pull to verify signatures; unsigned or tampered images are rejected unless --disable-content-trust is used.

3. AppArmor MAC – Docker automatically loads a default profile named docker-default . Users can create custom profiles (e.g., /etc/apparmor.d/containers/docker-nginx ) and run containers with --security-opt "apparmor=docker-nginx" . The profile can deny network raw sockets, file writes, and execution of privileged binaries.

#include <tunables/global>
profile docker-nginx flags=(attach_disconnected,mediate_deleted) {
  #include <abstractions/base>
  deny network raw,
  deny /bin/** wl,
  deny /root/** wl,
  deny /bin/sh mrwklx,
  deny /bin/dash mrwklx,
  deny /usr/bin/top mrwklx,
}

Running a container with this profile demonstrates the restrictions (ping fails, top cannot be executed, file creation is denied, etc.).

4. Seccomp syscall filtering – Seccomp, available since Linux 2.6.23, lets Docker provide a whitelist of allowed syscalls. The default profile disables about 44 of the 300+ syscalls. Users can supply a custom JSON profile via --security-opt seccomp=/path/to/profile.json . Example of checking kernel support:

$ cat /boot/config-$(uname -r) | grep CONFIG_SECCOMP=
CONFIG_SECCOMP=y

The default Seccomp JSON contains an action field, architecture map, and a list of syscall rules, e.g., allowing reboot only when the process has CAP_SYS_BOOT .

5. User Namespace isolation – By mapping container root to an unprivileged UID range on the host (0‑65536), containers can run as non‑root users while still appearing as root inside the namespace, reducing the impact of privilege‑escalation attacks.

6. SELinux – SELinux provides mandatory access control (MAC) that adds a second layer of protection after a container breakout. Docker can run with SELinux enabled, applying the docker-default policy.

7. PID limits – Docker supports --pids-limit (available since 1.10) to cap the number of processes a container may create, mitigating fork‑bomb attacks. The limit is enforced per‑user UID.

8. Additional kernel hardening tools – Tools such as docker‑bench‑security , Sysdig Falco, GRSEC, and PaX can be used to audit and further harden the Docker host.

The article covers the first four mechanisms in detail and promises a follow‑up for the remaining items.