Docker’s convenient, but it can be a security risk, too. It’s important to protect Docker Engine against possible threats, especially if you’re running a Docker host in production.

Docker Bench for Security is an automated script that can help you find issues with your configuration. The Bench script scans your host to find weaknesses in your Docker Engine setup. It’s provided by Docker itself as an open-source, security-auditing tool.

Running the Script

The easiest way to use Docker Bench is to download the script and run it directly. You can inspect it on GitHub if you’re concerned about its contents. Use Git to clone the Bench repository. Execute the script using your shell. Docker Bench should be run with sudo, as it includes checks that require root access.

You’ll see the audit results displayed in your terminal. Scanning will take several seconds. It might be a minute or more if you have a lot of running containers.

Understanding the Report

The report’s color-coded, so you can quickly identify issues. Blue INFO lines log entry into different scanning sections. A green PASS line shows that your system met the check. Red WARN lines are indicative of a potential vulnerability. Docker Bench runs over 200 individual checks in total. The exhaustive list is available in the project’s GitHub repository. Here’s how tests are categorized.

Host Configuration

This group of tests focuses on weaknesses in your host’s security auditing. Checks are made for proper auditing of Docker directories, use of a dedicated partition for containers, and installation of an updated Docker version.

Daemon Configuration

The daemon-oriented tests check for the Docker’s socket not being exposed over an unsecured connection. Network traffic between containers on the default bridge network should be restricted and insecure registries removed.

This section also looks for inappropriate privilege grants to containers. Containers shouldn’t be able to acquire new privileges. This could allow an attacker to outgrow the container.

The next section, Docker daemon configuration files, has a similar focus. It ensures that the Docker installation directory and Unix socket have appropriate permissions and ownership. Docker’s filesystem should be owned by root:root with restrictive permissions of 644.

Container Images

Docker Bench performs a basic check of the Dockerfiles for your known images. It will look for dedicated container users, the presence of HEALTHCHECK instructions, and the use of Content Trust to verify data integrity.

This test section will also emit warnings that remind you of basic image-hardening steps. Use trusted base images, apply new security patches, and avoid the installation of unnecessary packages. These measures help to eliminate vulnerabilities within containers.

Container Runtime

The Container Runtime tests inspect your running containers. This section contains over 30 tests, ranging from SELinux and AppArmor availability to the use of appropriate filesystem mounts and networking options.

You’ll drop points if you use privileged containers or mount the Docker socket into a container. Containers must not be able to gain additional privileges or interfere with the host system.

Bench also looks for SSH servers running inside containers. This is inadvisable, as direct container access should be avoided. It’s preferable to use docker exec from the host to interact with containers.

Additional tests look at the use of CPU and memory limits. An unlimited container could consume excessive resources and eventually cause an out-of-memory condition on the host. Networking checks flag unused ports as well as requests to map privileged ports into containers.

Docker Swarm

Docker Bench includes an additional section for Docker Swarm users. It focuses on flagging unsecured secrets and certificates that aren’t being rotated correctly. It also requires correct networking configuration, including the use of encrypted overlay networks.

The Swarm section will raise a warning if Swarm mode is enabled but not actually used. If you don’t plan on using Swarm, turn it off by running docker swarm leave –force.

Addressing Common Issues

Most Docker hosts will present several warnings if you haven’t taken active steps to harden them. Here are some measures that you can take to address some of the most common Docker Bench reports.

Enabling Auditing for Docker Files

Docker advises the use of system-level auditing on key Docker directories. Auditing logs any operations that affect monitored files and directories. This lets you track potentially destructive changes.

Make sure that you have auditd installed. Edit /etc/audit/audit.rules and add the following lines to the bottom of the file:

The -p wa instruction means that auditd will log writes and attribute changes that affect the files. If your Docker Bench output suggests that you use auditing for additional directories, add them to the list, too. Docker’s directories might change over time.

You’ll need to restart auditd to apply your changes:

Strengthening the Daemon

Docker Bench will usually find issues with your daemon configuration. Adding the following to /etc/docker/daemon.json will quiet several daemon warnings.

icc: This prevents containers from communicating with each other over the default bridge network. Containers will only reach each other if they’re explicitly linked together using a –link. live-restore: Setting this allows containers to keep running even if the daemon stops. This is advisable in production environments where you want to minimize downtime. no-new-privileges: This prevents containers from elevating their privileges using commands such as setuid and setgid. userland-proxy: Disabling this means that iptables is used to route host port traffic into containers. Without it, Docker’s userland proxy process is used, which increases the attack surface of your daemon. userns-remap: This enables the use of user namespaces, so root in a container maps to a less privileged host user. This reduces the risk of a compromised container being able to run root commands on your host. Using default will instruct Docker to set up a dedicated user account for this purpose.

RELATED: How to Use Cron With Your Docker Containers

Customizing Report Output

Docker Bench supports several flags that you can use to adjust its output:

-b: Disable colors. Useful if you’re running the script in a CI environment that doesn’t support full ANSI output. -p: Do not include suggested remediation measures. Helpful when you want to focus on the warnings and reduce the noise in the output. -l report. txt: Write output to report. txt instead of the terminal. -c check_5. 1,check_5. 2: Run checks 5. 1 and 5. 2 only. The test list is available on GitHub. -e check_5. 1,check_5. 2: Exclude checks 5. 1 and 5. 2.

You can combine flags together to produce the report that you need. If a whole section of checks doesn’t apply to you, consider creating a shell alias so that you can quickly run Docker Bench with a sequence of flags applied.

Conclusion

Using the Docker Bench for Security script helps you find and resolve weaknesses in your Docker host’s security. Addressing any warnings that it emits will help to harden your host and improve your security posture.

Remember that Docker Bench isn’t an exhaustive test. There are other aspects to maintaining Docker security that shouldn’t be overlooked either.

A compromised container could give attackers a foothold into your systems, even if you have strong host-level security. You can reduce this risk by using Docker Bench, alongside active container vulnerability scanners like Trivy and Clair. These will help you identify problems within your containers, such as outdated dependencies that could be exploited.

While a good score is always the target, you should also note that Docker Bench is aimed at production workloads. Not all of the checks are relevant to a developer’s local Docker installation. Run the script, read the warnings, and assess which ones apply to your environment.