One of the key points of cloud-native security is addressing container security risks as soon as possible. Doing it later in the development life cycle slows down the pace of cloud adoption and raises security and compliance risks. Using Docker to containerize your applications and services can give you some security benefits out of the box. However, a default Docker installation still has room for some security-related configuration improvements.
Docker Bench for Security is a script that checks for dozens of common best practices around deploying Docker containers in production. All tests are automated and based on the CIS Docker Benchmark v1.3.1.
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 harden your host and improve your security posture.
While a good score is always the target, you should also note that Docker Bench is for production workloads. Not all checks are relevant to a developer’s local Docker installation. Run the script, read the warnings, and assess which ones apply to your environment.
Docker Bench for Security scans the Docker host for common configuration issues, like loose settings in configuration files and system rights and questionable defaults. The tool relies on a Common Vulnerabilities and Exposures (CVE) database to audit the libraries and executables on the system in question. For an example output checks result, see image one in the download accompanying these FAQs.
You can download and run the tool from here.
You can run this script from your base host by running:
git clone https://github.com/docker/docker/docker-bench-security.git
sudo sh docker-bench-security.sh
The easiest way to run your hosts against the Docker Bench for Security is by running this pre-built container:
Don’t forget to adjust the shared volumes according to your operating system.
docker run --rm --net host --pid host --userns host --cap-add
-e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \
-v /etc:/etc:ro \
-v /usr/bin/containerd:/usr/bin/containerd:ro \
-v /usr/bin/runc:/usr/bin/runc:ro \
-v /usr/lib/systemd:/usr/lib/system:ro \
-v /var/lib:/var/lib:ro \
-v /var/run/docker.sock:/var/run/docker.sock:ro \
--label docker_bench_security \
By default the Docker Bench for Security script will run all available CIS tests and produce logs in the log folder from current directory, named docker-bench-security.log.json and docker-bench-security.log.
If the docker container is used then the log files will be created inside the container in location /usr/local/bin/log/. If you wish to access them from the host after the container has been run you will need to mount a volume for storing them in. The below are the options for Docker Bench for Security:
-b optional Do not print colors
-h optional print this help message
-l FILE optional Log output in FILE, inside container if run
-u USERS optional Comma delimited list of trusted docker
-c CHECK optional Comma delimited list of specific check (s) id
-e CHECK optional Comma delimited list of specific check (s) id
-i INCLUDE optional Comma delimited list of patterns within a
container or image name to check
-x EXCLUDE optional Comma delimited list of patterns within a
container or image name to exclude from check
-n LIMIT optional In JSON output, when reporting list of items
(containers, images, etc.) , limit the number of reported items to
LIMIT, Default 0 (no limit) .
-p PRINT optional Disable the printing of remediation measures,
Default : print remediation measures.
From the docker-bench-security directory, issue the command:
./docker-bench-security.sh -i hello-world
Please see image two in the download accompanying these FAQs for the output. At the end of each scan, it provides a score. Admins can track a host configuration’s Docker Bench for security scores to mark improvements over time. The higher the scan score, the better.
Docker advises the use of system-level auditing on key Docker directories. Auditing logs any operations that affect monitored files and directories and lets you track potentially destructive changes. Ensure you have Auditd installed.
Enter: Edit /etc/audit/audit.rules , add the lines (shown on image three in the download for these FAQs) 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. Docker’s directories might change over time. You’ll need to restart Auditd to apply your changes:
sudo systemctl restart auditd
Vulnerability scanning using ‚docker scan‘ for Docker local images allows developers and development teams to review the security state of the container images and take actions to fix issues identified during the scan, resulting in more secure deployments. Docker Scan runs on the Snyk engine, providing users with visibility into the security posture of their local Docker files and local images. For example output of a vulnerability scan, see image four.
You get the following free scans per month:
For more information, visit:
You can use Grype, a vulnerability scanner for container images and filesystems. Easily install the binary to try it out. Grype works with Syft, the powerful SBOM (software bill of materials) tool for container images and file systems.
Currently, Grype is built only for macOS and Linux. On the download accompanying these FAQs, see images five and six for installation instructions (recommended and Homebrew) and image seven for an example output from a vulnerability scan.
Hardening a Docker image involves scanning it for vulnerabilities, building a new image with additional mitigating protections, then using that version as the base for your application. You need to regularly scan and rebuild your images to ensure they include the latest packages and patches. It’s best practice to incorporate hardening into your image build pipeline.
Remember that container security best practices don’t just include the delivered applications and container images themselves. You also need to have the full component stack used for building, distributing, and specifically executing the container.
Remember that Docker Bench isn’t an exhaustive test. There are other aspects to maintaining Docker security that shouldn’t be overlooked.
Madhu Kumar Yeluri
Remember that Docker Bench isn’t an exhaustive test. There are other aspects to maintaining Docker security that shouldn’t be overlooked. A compromised container could give attackers a foothold into your systems, even if you have strong host-level security. Using Docker Bench alongside active container vulnerability scanners like Docker scan (snyk), Grype, Trivy, and Clair, you can reduce this risk. These will help you identify problems within your containers, such as outdated dependencies that could be exploited.