⬡

Compose-Prüfer

Container-Risiken finden

Eingabe

services:
  api:
    image: example/api:latest
    ports:
      - "8080:8080"
    environment:
      - DB_PASSWORD=change-me
    privileged: true

Ergebnis5 Befunde

!privileged: true gewährt nahezu Host-Zugriff.
!Ein Passwort steht im Klartext. Secrets oder externen Secret-Store verwenden.
△Image auf eine unveränderliche Version oder einen Digest pinnen statt :latest.
△Veröffentlichter Port scheint auf allen Schnittstellen offen; möglichst an 127.0.0.1 binden.
△read_only: true erwägen, wenn das Root-Dateisystem nicht beschreibbar sein muss.

Einführung

Der Docker-Compose-Prüfer prüft eine eingefügte compose.yaml auf fünf Container-Sicherheitsrisiken, die in Produktionsvorfällen auftauchen: privilegierter Modus, Geheimnisse im Klartext, ungepinnte Images, an allen Schnittstellen gebundene Ports und ein beschreibbares Root-Dateisystem.

Compose-Dateien lesen sich wie Konfiguration, werden aber zur Sicherheitsgrenze Ihrer Container. Kleine Fehler hier führen direkt zu Risiken auf Host-Ebene.

Ziel

privileged: true kennzeichnen, das nahezu Host-Zugriff bedeutet.
Passwörter und Zugangsdaten inline in der Datei erkennen.
Vor :latest-Image-Tags warnen, die nicht reproduzierbar sind.
Vor veröffentlichten Ports warnen, die an allen Schnittstellen offen sind, und vor fehlendem read_only: true.

Eingaben

Eine Einfügung von compose.yaml (oder des services-Abschnitts).
Die YAML-Struktur wird nicht tief geparst; die Prüfungen sind musterbasiert auf dem sichtbaren Text.

So funktioniert es

Die Datei wird mit fünf Musterprüfungen gescannt. privileged: true ist ein hoher Befund, weil es fast jede Capability gewährt und die meiste Isolation deaktiviert.

Jede Zeile mit einer Passwort-Zuweisung (password: oder PASSWORD=) ist ein hoher Befund: Geheimnisse gehören in Docker-Secrets oder einen externen Secret-Store.

image: ...:latest erzeugt eine Warnung, weil dieselbe Datei mit der Zeit unterschiedlichen Inhalt ziehen kann; ein unveränderlicher Digest oder eine gepinnte Version ist reproduzierbar.

Ein veröffentlichter Port (Host:Container), der nicht an 127.0.0.1 gebunden ist, ist eine Warnung, ebenso wie ein Dienst ohne read_only: true auf seinem Root-Dateisystem.

Testbares Beispiel

Ausprobieren — die Analyse läuft lokal in Ihrem Browser.

Beispiel

services:
  api:
    image: example/api:latest
    ports:
      - "8080:8080"
    environment:
      - DB_PASSWORD=change-me
    privileged: true

Erwartete Ausgabe

Hoch: privileged: true gewährt nahezu Host-Zugriff.
Hoch: Ein Passwort steht im Klartext. Secrets oder externen Secret-Store verwenden.
Warnung: Image auf eine unveränderliche Version oder einen Digest pinnen statt :latest.
Warnung: Veröffentlichter Port scheint auf allen Schnittstellen offen.
Warnung: read_only: true erwägen, wenn das Root-Dateisystem nicht beschreibbar sein muss.

Ausgabe verstehen

Privilegierten Modus wann immer möglich entfernen; die meisten Arbeitslasten brauchen nur bestimmte Capabilities.
Inline-Geheimnisse in Docker-Secrets oder einen externen Tresor verschieben und alles rotieren, was committet wurde.
Gepinnte Tags oder Digests machen Bereitstellungen reproduzierbar und Rollbacks vorhersagbar.
Ports an 127.0.0.1 zu binden hält Dienste privat, es sei denn, ein Proxy setzt sie absichtlich aus.

Risiken

privileged: true auf einem kompromittierten Container ist praktisch Host-Kompromittierung.
Inline-Passwörter leaken in Images, Registries und Protokolle und werden nie sauber rotiert.
:latest bricht Rollbacks: das gestrige funktionierende Image kann durch den heutigen kaputten Build überschrieben sein.

Grenzen

Musterprüfungen können Risiken übersehen, die über YAML-Anker, Environment-Dateien oder Dockerfile-Anweisungen ausgedrückt sind.
Es führt den Compose-Parser nicht aus, daher werden YAML-Syntaxfehler hier nicht gemeldet.
Es kann keine Schwachstellen in den Images selbst erkennen.

Offizielle Referenzen

FAQ

Wann ist privileged: true gerechtfertigt?

Fast nie in Produktion. Einige Legacy-Treiber und bestimmte Gerätezugriffe brauchen es; der sichere Weg ist, exakt die benötigten Capabilities zu gewähren und für Hardwarezugriff devices: zu verwenden.

Was statt Inline-Passwörtern verwenden?

Docker-Secrets für Swarm, Environment-Dateien mit eingeschränkten Rechten und externe Referenzen für Tresor-Secrets. Entscheidend ist, dass Geheimnisse nie in der Compose-Datei oder im Image stehen.

Bricht read_only: true Apps, die Dateien schreiben?

Nur wenn sie in das Root-Dateisystem schreiben. Beschreibbare Pfade (Uploads, Caches) können als Volumes gemountet oder mit tmpfs deklariert werden, der Rest bleibt schreibgeschützt.