Zavelix IT Tip: Running a Docker Server Securely – The Basics

Note: practical tip, not a news item

This is a general Zavelix IT tip and not a report on a current event. It is based on the Docker Engine documentation.

The four security areas

The Docker documentation names four areas to review: kernel security with namespaces and control groups, the attack surface of the Docker daemon, gaps in container configuration, and additional kernel hardening features.

Isolation through namespaces and control groups

Namespaces separate containers from each other and from the host: processes in one container cannot see processes in other containers or on the host. Each container also has its own network stack. Control groups limit resources such as memory, CPU and disk I/O so a single container cannot bring down the system by exhausting them. They help against some denial-of-service cases, but not against access to other containers' data.

The Docker daemon as a sensitive component

The daemon needs root privileges unless Rootless mode is used. Only trusted users should therefore control it, since a container can mount host directories, up to the entire filesystem, and modify them. If an application drives Docker through an API, parameters should be validated especially carefully.

By default, control runs through a Unix socket whose access can be restricted with ordinary file permissions. If the API is exposed over the network, the documentation says securing it with HTTPS and certificates is mandatory, and exposing it over HTTP without TLS is not permitted. A firewall alone is not enough because containers may still reach the endpoint, which can lead to privilege escalation. Access should also be limited to a trusted network or VPN. SSH is an alternative.

Capabilities: root in a container is limited

By default Docker starts containers with a restricted set of Linux capabilities, dropping all except those needed. Root inside a container therefore has far fewer privileges than root on the host. Mount operations, raw sockets or kernel module loading can be denied. This makes it harder for an intruder who escalates inside a container to do serious damage or reach the host.

Dedicated server

If Docker runs on a server, the documentation recommends running only Docker there and moving other services into containers. Typical admin tools such as an SSH server and monitoring are fine to keep.

What should companies do now?

These steps follow from the fundamentals above:

• Give access to the Docker daemon only to trusted people.
• Consider Rootless mode if the daemon should not run with root privileges.
• Do not expose the Docker API unprotected on the network; use HTTPS with certificates, a VPN or SSH where needed.
• Be very restrictive with host directories mounted into containers.
• Keep default capabilities and do not extend them without reason.
• Use the Docker server only for Docker where possible.