Docker Bench for Security: Scan Your Docker Host for CIS Compliance in 5 Minutes – ITFROMZERO

Table of Contents

Real-world Issue: Docker Isn’t as Secure as You Think

Six months ago, I managed a cluster of 20 microservices running on Docker for a financial project. Everything ran smoothly: CI/CD pushed images continuously, containers scaled automatically, and logs flowed into Grafana steadily. I used to assume Docker isolated applications well enough. If hackers broke in, they’d just be stuck inside that container “box”.

Everything changed when the Security team sent a 15-page audit report with over 40 critical security flaws. The Docker daemon was running as root, the socket was exposed, and containers had no resource limits. Worse, many images used an old version of Node.js from 3 years ago, riddled with Critical vulnerabilities. It was a costly lesson: Knowing how to run Docker doesn’t mean you know how to operate it securely.

If you’re only used to running docker run while ignoring Host or Daemon configurations, your system is highly susceptible to privilege escalation attacks. Don’t wait until your server is turned into a crypto miner to start worrying about security.

Why Are Default Docker Configurations Dangerous?

Docker prioritizes convenience so users can “run it immediately.” However, this convenience often comes with hidden risks:

Excessive Privileges: The Docker daemon runs as root by default. If you accidentally mount /var/run/docker.sock into a compromised container, the hacker gains control over the entire host machine.
Massive CIS Standards: The CIS Docker Benchmark consists of over 100 check items. No one has the patience to manually cross-reference hundreds of PDF pages every time they deploy a new server.
Runtime Vulnerabilities: We often only check if a container is “Up”. Few notice if it’s running with dangerous flags like --privileged.

Common Security Auditing Solutions

Before finding the right fit, I tried several traditional methods:

Manual Hardening: Manually checking config files, re-permissioning /etc/docker, and configuring auditd. This is extremely time-consuming and prone to error. It’s only suitable if you’re studying for a security certification.
Custom Bash Scripts: Some write scripts to quickly check a few parameters. However, these scripts often become outdated as Docker updates.
Expensive SaaS Tools: Solutions like Prisma Cloud or Snyk are powerful. But for startups or personal projects, a cost of thousands of dollars per month is a huge barrier.

Docker Bench for Security: The “Best Bang for Your Buck” Tool

After many trials, I’ve settled on Docker Bench for Security as the optimal solution. It’s an open-source script packaged into a container that automatically scans the system based on all CIS Benchmarks.

On the production systems I manage, this tool is scheduled to run weekly. It helps me immediately catch silly mistakes like forgetting RAM limits, which can cause a faulty container to crash the entire server.

1. Quick Deployment in 10 Seconds

The biggest advantage is that you don’t need to install anything on the host machine. Just execute the following command to pull the image and start scanning:

docker run --rm -it --network host --pid host --userns host --cap-add audit_control \
    -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/systemd:ro \
    -v /var/lib:/var/lib:ro \
    -v /var/run/docker.sock:/var/run/docker.sock:ro \
    --label docker_bench_security \
    docker/docker-bench-security

Key parameters explained:

--pid host: Allows the tool to observe processes running on the host to check the integrity of the Daemon.
-v /var/run/docker.sock:/var/run/docker.sock: Allows the tool to communicate directly with the Docker API.
--rm: Automatically removes the container after the scan to keep the server clean.

2. Analyzing Scan Results

Results are categorized by color for easy reading:

[PASS]: Configuration is secure according to standards.
[WARN]: Security risk warning that needs review.
[INFO]: Reference information.
[NOTE]: Critical issues requiring immediate action.

Reports typically focus on 5 main groups: Host configuration, Daemon setup, system file permissions, Image security, and container Runtime status.

3. Real-world Bug Fixing: Stopping Internal Attacks

After the first run, my server hit a [WARN] 2.1 - Ensure network traffic is circumscribed... error. This means containers in the default bridge network can freely “talk” to each other. If one container is infected with malware, it can easily attack the others.

I resolved this thoroughly by configuring the /etc/docker/daemon.json file as follows:

{
  "icc": false,
  "userns-remap": "default",
  "no-new-privileges": true
}

Then just restart the service:

sudo systemctl restart docker

With just three lines of configuration, I blocked Inter-Container Communication (ICC), significantly increasing system isolation.

4. Automating the Monitoring Process

Don’t let security be a passing interest. I set up a Cronjob to run Docker Bench weekly and push the results directly to Slack. If someone accidentally enables the --privileged flag during deployment, I’ll receive an alert within 5 minutes.

# Script to save logs automatically every week
docker run --rm --network host --pid host docker/docker-bench-security > /var/log/docker-bench-$(date +%F).log

Results After 6 Months of Practical Application

Integrating Docker Bench into the operational workflow has brought noticeable changes:

Better Image Building Skills: The dev team has abandoned the habit of using root privileges, opting for the USER command in the Dockerfile instead.
Stable Resources: Enforcing CPU/RAM limits ensures the server never hangs unexpectedly due to memory leaks.
Customer Trust: During periodic audits, I simply export logs from Docker Bench to prove the system complies with international standards.

Don’t be complacent with default settings. Spend 5 minutes trying out Docker Bench for Security today. The results might make you “break a sweat”, but it’s better to fix flaws now than to deal with an incident later. If you have trouble fixing [WARN] errors, leave a comment below!