Docker Bench Security: CIS-Audit für Container-Hosts durchführen

1. Was Docker Bench Security prüft und warum das zählt

Docker Bench Security ist ein von Docker Inc. und der Community gepflegtes Shell-Skript, das den Host, den laufenden Daemon und alle aktiven Container gegen die CIS-Docker-Benchmark prüft. Statt einzelne Konfigurationen manuell nachzuschlagen, liefert Docker Bench Security in wenigen Minuten einen strukturierten Bericht mit PASS-, WARN- und INFO-Markierungen für jede der rund hundert Einzelprüfungen. Das Werkzeug ersetzt keine tiefgehende Image-Analyse, ist aber der schnellste Weg, um einen realistischen Überblick über den Sicherheitszustand eines Docker-Hosts zu bekommen. Der eigentliche Wert von Docker Bench Security liegt darin, dass es Konfigurationsfragen beantwortet, die in der Praxis oft unbeachtet bleiben: Läuft der Daemon mit aktiviertem Audit-Logging? Sind Container-Berechtigungen unnötig weit gefasst? Ist der Docker-Socket ungeschützt erreichbar? Diese Fragen betreffen nicht ein einzelnes Image, sondern die gesamte Betriebsumgebung, und genau dort setzt Docker Bench Security an.

In der Praxis wird Docker Bench Security häufig einmalig vor einem Audit oder einer Zertifizierung ausgeführt und danach vergessen. Das ist ein Fehler, denn Konfigurationsdrift ist in Docker-Umgebungen die Regel, nicht die Ausnahme. Ein neues Teammitglied setzt ein Feature-Flag im Daemon zurück, ein Deployment-Skript vergisst ein Sicherheits-Flag, und der Sicherheitszustand verschlechtert sich schleichend. Die folgenden Abschnitte zeigen, wie Docker Bench Security installiert, interpretiert, priorisiert und dauerhaft in den Betrieb eingebunden wird.

2. Installation und erster Lauf gegen den Host

Docker Bench Security läuft selbst als Container mit weitreichenden Zugriffsrechten auf den Host, weil es genau diese Host-Eigenschaften prüfen muss. Das Skript benötigt Zugriff auf den Docker-Socket, auf `/etc`, auf `/usr/bin/docker` und auf die systemd-Unit-Dateien des Daemons. Ohne diese Mounts kann Docker Bench Security nur einen Bruchteil der Prüfungen tatsächlich durchführen und meldet die restlichen Checks als INFO statt als echtes Ergebnis.

Der erste Lauf sollte auf einem repräsentativen Host stattfinden, nicht auf einer isolierten Testmaschine mit abweichender Konfiguration. Nur so liefert Docker Bench Security Ergebnisse, die tatsächlich den Produktionszustand widerspiegeln. Das Skript schreibt seinen Bericht standardmäßig auf die Konsole, kann aber auch als JSON exportiert werden, was für die spätere Automatisierung entscheidend ist.

#!/usr/bin/env bash
# Run Docker Bench Security against the local host
set -euo pipefail

docker run --rm --net host --pid host --userns host --cap-add audit_control \
  -e DOCKER_CONTENT_TRUST="$DOCKER_CONTENT_TRUST" \
  -v /etc:/etc:ro \
  -v /usr/bin/docker-containerd:/usr/bin/docker-containerd:ro \
  -v /usr/bin/docker-runc:/usr/bin/docker-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 > bench-report.log

# Extract only WARN lines for a quick first triage
grep '\[WARN\]' bench-report.log | sort | uniq -c | sort -rn

Ein häufiger Anfängerfehler: Docker Bench Security ohne `--net host` und `--pid host` zu starten. Ohne diese Flags sieht das Skript nur seinen eigenen isolierten Namespace statt der Host-Prozesse, und ein Großteil der Runtime-Checks fällt als INFO statt als belastbares Ergebnis aus. Wer den Bericht ernsthaft auswerten will, sollte daher immer die vollständige Mount- und Namespace-Konfiguration aus der offiziellen Dokumentation verwenden.

3. Aufbau der CIS-Docker-Benchmark verstehen

Die CIS-Docker-Benchmark, die Docker Bench Security abbildet, gliedert sich in sieben Hauptabschnitte: Host-Konfiguration, Docker-Daemon-Konfiguration, Daemon-Konfigurationsdateien, Container-Images und Build-Dateien, Container-Runtime, Docker-Security-Operations und Docker-Swarm-Konfiguration. Jeder Abschnitt enthält nummerierte Einzelchecks, die im Bericht von Docker Bench Security mit derselben Nummerierung erscheinen, was das Nachschlagen in der offiziellen CIS-Dokumentation erleichtert.

Nicht jeder Check ist für jede Umgebung gleich relevant. Ein Check zur Docker-Swarm-Konfiguration liefert bei reinen Compose- oder Kubernetes-Setups keinen praktischen Nutzen und sollte entsprechend eingeordnet werden. Docker Bench Security unterscheidet nicht automatisch zwischen relevanten und irrelevanten Checks für die eigene Architektur, diese Bewertung bleibt Aufgabe des Teams, das den Bericht liest. Wer diesen Kontext ignoriert, verschwendet Zeit mit der Behebung von Findings, die in der eigenen Umgebung gar nicht zutreffen.

4. Host-Konfiguration prüfen und härten

Der erste Abschnitt der CIS-Benchmark, den Docker Bench Security abfragt, betrifft die Host-Konfiguration unabhängig von Docker selbst: getrennte Partition für Container-Daten, aktuelle Kernel-Version, aktiviertes Auditing für Docker-Binaries und -Verzeichnisse. Diese Checks wirken auf den ersten Blick generisch, sind aber die Grundlage, auf der jede Container-Isolation aufbaut. Ein veralteter Kernel ohne die relevanten Sicherheits-Patches macht selbst die beste Container-Konfiguration angreifbar.

Besonders wichtig ist der Check zum Auditing von `/usr/bin/docker`, `/var/lib/docker`, `/etc/docker` und den zugehörigen systemd-Unit-Dateien über `auditd`. Ohne diese Audit-Regeln bleibt eine unautorisierte Änderung an der Docker-Konfiguration unbemerkt, bis der Schaden bereits entstanden ist. Docker Bench Security markiert fehlende Audit-Regeln konsequent als WARN, weil sie forensisch entscheidend sind, sobald ein Vorfall untersucht werden muss.

#!/usr/bin/env bash
# Add auditd rules that Docker Bench Security checks for (host hardening)
set -euo pipefail

cat >> /etc/audit/rules.d/docker.rules <<'EOF'
-w /usr/bin/docker -p wa -k docker
-w /var/lib/docker -p wa -k docker
-w /etc/docker -p wa -k docker
-w /lib/systemd/system/docker.service -p wa -k docker
-w /lib/systemd/system/docker.socket -p wa -k docker
-w /etc/default/docker -p wa -k docker
-w /etc/docker/daemon.json -p wa -k docker
-w /usr/bin/containerd -p wa -k docker
-w /usr/sbin/runc -p wa -k docker
EOF

augenrules --load
systemctl restart auditd

5. Docker-Daemon-Konfiguration absichern

Der zweite große Prüfblock von Docker Bench Security betrifft die laufende Daemon-Konfiguration: Ist der TLS-verschlüsselte Zugriff auf den Docker-Socket aktiv, falls dieser über das Netzwerk erreichbar ist? Ist Live-Restore aktiviert, damit Container einen Daemon-Neustart überstehen? Ist User-Namespace-Remapping konfiguriert, um Root im Container von echtem Root auf dem Host zu entkoppeln? Jede dieser Fragen entspricht einem konkreten Eintrag in `/etc/docker/daemon.json`, den Docker Bench Security gezielt prüft.

Besonders kritisch ist der Check auf den ungeschützten TCP-Socket. Ein Docker-Daemon, der auf `tcp://0.0.0.0:2375` ohne TLS lauscht, gewährt jedem Netzwerkteilnehmer vollständige Root-Rechte auf dem Host, weil jeder Container mit `--privileged` gestartet werden kann. Docker Bench Security stuft diesen Fund konsequent als kritisches WARN ein, und zu Recht: In der Praxis ist dies einer der häufigsten Wege, über die kompromittierte Docker-Hosts in freier Wildbahn gefunden werden.

{
  "live-restore": true,
  "userns-remap": "default",
  "no-new-privileges": true,
  "icc": false,
  "log-driver": "journald",
  "log-opts": { "max-size": "10m", "max-file": "3" },
  "userland-proxy": false,
  "tls": true,
  "tlsverify": true,
  "tlscacert": "/etc/docker/certs/ca.pem",
  "tlscert": "/etc/docker/certs/server-cert.pem",
  "tlskey": "/etc/docker/certs/server-key.pem"
}

6. Container- und Image-Checks richtig interpretieren

Der Abschnitt Container-Runtime ist bei den meisten Erstläufen von Docker Bench Security der längste WARN-Block, weil er jeden einzelnen laufenden Container gegen mehr als zwanzig Kriterien prüft: AppArmor- oder SELinux-Profil aktiv, keine Privilegien-Eskalation erlaubt, keine gemounteten sensiblen Host-Pfade, kein Zugriff auf den Docker-Socket im Container selbst, begrenzte Speicher- und CPU-Ressourcen. Ein einzelner Container kann hier leicht zehn oder mehr WARN-Einträge erzeugen.

Wichtig ist, diese Findings nicht pauschal abzuarbeiten, sondern nach Angriffsfläche zu sortieren. Ein Container ohne definiertes Speicherlimit ist ein Betriebsrisiko, aber selten ein direkter Sicherheitsvorfall. Ein Container mit gemountetem Docker-Socket (`-v /var/run/docker.sock:/var/run/docker.sock`) hingegen ist ein direkter Weg zur vollständigen Host-Kompromittierung, weil dieser Container jeden beliebigen anderen Container mit beliebigen Rechten starten kann. Docker Bench Security meldet beide Fälle als WARN, aber sie sind priorisierungstechnisch nicht vergleichbar.

# Typical Docker Bench Security output for the container runtime section
[WARN] 5.1  - Ensure AppArmor Profile is Enabled
[WARN] 5.4  - Ensure privileged containers are not used
[WARN] 5.6  - Ensure ssh is not run within containers
[WARN] 5.9  - Ensure the host's network namespace is not shared
[WARN] 5.10 - Ensure memory usage for container is limited
[WARN] 5.31 - Ensure the Docker socket is not mounted inside any containers

# Prioritize by real attack surface, not just WARN count
for cid in $(docker ps -q); do
  docker inspect "$cid" | jq -r '.[0].Mounts[].Source' | grep -q docker.sock \
    && echo "[CRITICAL] Container $cid has the Docker socket mounted"
done

7. False Positives erkennen und eine Baseline definieren

Nicht jedes WARN von Docker Bench Security ist in jeder Umgebung ein echtes Risiko. Manche Checks setzen Docker-Swarm-Betrieb voraus und sind bei reinen Compose-Deployments irrelevant, andere betreffen Legacy-Optionen wie den ungeschützten Userland-Proxy, der in modernen Setups ohnehin deaktiviert ist. Wer jeden Check gleich gewichtet, verliert schnell den Überblick und beginnt, Berichte zu ignorieren, statt sie zu nutzen.

Der pragmatische Weg ist, eine dokumentierte Baseline zu definieren: Welche Checks sind bewusst als "akzeptiertes Risiko" markiert, mit Begründung und Verantwortlichem, und welche müssen bei jedem Lauf von Docker Bench Security auf PASS stehen. Diese Baseline gehört ins Repository, nicht in den Kopf einer einzelnen Person, damit neue Teammitglieder nachvollziehen können, warum bestimmte WARN-Meldungen bewusst in Kauf genommen werden.

8. Docker Bench Security in CI/CD automatisieren

Ein einmaliger Audit verliert seinen Wert, sobald sich die Infrastruktur ändert. Der nachhaltige Ansatz ist, Docker Bench Security regelmäßig gegen produktionsnahe Hosts laufen zu lassen und die Ergebnisse gegen die definierte Baseline zu vergleichen. Weicht ein neuer Lauf von der Baseline ab, weil ein zuvor als PASS markierter Check plötzlich WARN meldet, ist das ein klares Signal für Konfigurationsdrift, das ein Alert auslösen sollte.

Die JSON-Ausgabe von Docker Bench Security lässt sich mit `jq` gezielt auf neue oder veränderte Findings filtern, statt bei jedem Lauf den kompletten Bericht manuell zu lesen. In einer geplanten Pipeline, etwa über einen wöchentlichen Cron-Job auf den produktiven Hosts, wird so aus einem einmaligen Compliance-Nachweis ein kontinuierlicher Kontrollmechanismus.

#!/usr/bin/env bash
# Compare Docker Bench Security JSON output against an accepted baseline
set -euo pipefail

docker run --rm --net host --pid host --userns host --cap-add audit_control \
  -v /etc:/etc:ro -v /var/lib:/var/lib:ro -v /var/run/docker.sock:/var/run/docker.sock:ro \
  docker/docker-bench-security -l /tmp/bench.json -j > /dev/null

# Fail the pipeline if a new WARN appears that is not in the accepted baseline
new_warns=$(jq -r '.tests[].results[] | select(.result=="WARN") | .id' /tmp/bench.json \
  | grep -vFf accepted-baseline.txt || true)

if [[ -n "$new_warns" ]]; then
  echo "[ALERT] New Docker Bench Security findings outside baseline:" >&2
  echo "$new_warns" >&2
  exit 1
fi

echo "[OK] No new findings outside the accepted Docker Bench Security baseline"

9. Docker Bench Security im Vergleich zu anderen Tools

Docker Bench Security deckt Host- und Daemon-Konfiguration hervorragend ab, ersetzt aber keine Image-Schwachstellenanalyse und keine Laufzeit-Anomalieerkennung. Die folgende Tabelle ordnet das Werkzeug gegenüber anderen gängigen Ansätzen ein, damit klar wird, welche Lücken zusätzliche Werkzeuge schließen müssen.

Docker Bench Security ist damit kein Ersatz, sondern die Grundlage: Ohne einen sauber gehärteten Host und Daemon läuft jedes noch so gescannte Image auf unsicherem Fundament. Die Kombination aus Docker Bench Security für Host und Daemon, Trivy oder Grype für Images und Falco für die Laufzeit deckt die drei relevanten Ebenen der Container-Sicherheit vollständig ab.

10. Zusammenfassung

Docker Bench Security ist der schnellste Einstieg in einen strukturierten CIS-Audit für Docker-Hosts. Das Werkzeug prüft Host-Konfiguration, Daemon-Einstellungen, Konfigurationsdateien und Container-Runtime gegen rund hundert dokumentierte Checks und liefert einen priorisierbaren Bericht statt vager Vermutungen. Wichtig ist, den Bericht nicht als einmalige Übung zu behandeln, sondern eine dokumentierte Baseline zu definieren und Abweichungen automatisiert zu erkennen.

Docker Bench Security ersetzt weder Image-Scanning noch Laufzeit-Bedrohungserkennung, bildet aber das Fundament, auf dem beide aufbauen. Ein gehärteter Host mit korrekt konfiguriertem Daemon reduziert die Angriffsfläche, bevor überhaupt ein einzelnes Image geprüft wird. In Kombination mit regelmäßigen CI-Läufen wird aus dem Skript ein kontinuierlicher Kontrollmechanismus statt eines einmaligen Compliance-Nachweises.

11. FAQ: Docker Bench Security