Automatisierung ist der beste Freund des Sysadmins. Tools wie Watchtower sind in der Docker-Welt ein absoluter Segen: Sobald ein neues Image-Release auf dem Docker Hub landet, zieht Watchtower es herunter und startet den Container neu. Zero-Touch, Zero-Downtime. Doch im Jahr 2026 birgt dieses blinde Vertrauen ein massives Risiko: Supply Chain Attacks.
Das Problem mit dem blinden Vertrauen
Was passiert, wenn der offizielle Maintainer eines Images gehackt wird? Oder wenn eine harmlose npm-Bibliothek tief im Build-Prozess durch ein böswilliges Update kompromittiert wird (wie beim berüchtigten xz-utils-Hack)?
Wenn du Watchtower ohne Sicherheitsnetz betreibst, rollt dein Server die Schadsoftware vollautomatisch und hochgradig effizient nachts um 3 Uhr in deine produktive Infrastruktur aus. Du automatisierst quasi deine eigene Kompromittierung.
Trust, but Verify: Die Zero-Bloat Lösung
Wir brauchen einen Türsteher, der jedes Update scannt, bevor es ausgeführt wird. Hier kommt Trivy von Aqua Security ins Spiel – ein extrem schneller Vulnerability-Scanner für Container-Images. Bei Tessmann Digital drehen wir den Prozess um: Watchtower wird vom automatischen Updater zum reinen Informanten degradiert, und Trivy übernimmt die Qualitätskontrolle.
Schritt 1: Watchtower als reinen Informanten aufsetzen (Monitor-Only)
Wir verbieten Watchtower das eigenmächtige Updaten. Über die Umgebungsvariable WATCHTOWER_MONITOR_ONLY=true prüft das Tool nur noch, ob neue Images verfügbar sind, und schickt uns eine Benachrichtigung (z. B. via Telegram oder Gotify).
Hier ist die passende docker-compose.yml für deinen Management-Stack:
version: "3.8"
services:
watchtower:
image: containrrr/watchtower
container_name: watchtower
volumes:
- /var/run/docker.sock:/var/run/docker.sock
environment:
- WATCHTOWER_MONITOR_ONLY=true
- WATCHTOWER_POLL_INTERVAL=86400 # Check einmal alle 24 Stunden
- WATCHTOWER_CLEANUP=true
# Optional: Benachrichtigungen aktivieren (Beispiel Telegram)
# - WATCHTOWER_NOTIFICATIONS=shoutrrr
# - WATCHTOWER_NOTIFICATION_URL=telegram://token@telegram?channels=chat_id
restart: unless-stoppedSchritt 2: Das sichere Update-Skript mit ephemerem Trivy
Anstatt Trivy fest auf dem Debian-Host zu installieren (was dem Zero-Bloat-Ansatz widerspricht), nutzen wir Trivy einfach selbst als temporären Docker-Container. Wenn Watchtower ein Update meldet, führen wir dieses simple Bash-Skript aus.
Das Skript zieht das neue Image, startet Trivy als Wegwerf-Container (--rm), scannt das Image und bricht den Vorgang hart ab, falls kritische Lücken gefunden werden.
#!/bin/bash
# update_secure.sh - Der sichere Docker-Updater
IMAGE="nginx:latest"
COMPOSE_DIR="/opt/docker/webserver"
echo "[1] Ziehe neuestes Image für $IMAGE..."
docker pull $IMAGE
echo "[2] Scanne Image mit Trivy auf kritische CVEs..."
# Trivy läuft als temporärer Container und greift auf den Docker-Socket zu
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
aquasec/trivy image \
--severity CRITICAL \
--no-progress \
--exit-code 1 \
$IMAGE
# Prüfen, ob Trivy angeschlagen hat (Exit-Code 1)
if [ $? -eq 0 ]; then
echo "[3] Scan bestanden! Keine kritischen Lücken. Container wird aktualisiert..."
cd $COMPOSE_DIR && docker-compose up -d
else
echo "[!] ALARM: Trivy hat kritische Lücken gefunden!"
echo "[!] Update abgebrochen. Der laufende Container bleibt auf der alten (sicheren) Version."
exit 1
fi
Das Ergebnis: Härtung durch Design
Mit diesem simplen Setup hast du deine Supply Chain massiv abgesichert. Versucht ein Angreifer, ein verseuchtes Update über ein kompromittiertes Repository zu verteilen, schlägt die CVE-Datenbank von Trivy an. Dein Skript blockt das Update, dein laufender Container bleibt unangetastet, und du kannst entspannt analysieren, anstatt einen brennenden Server löschen zu müssen.
Echte Sicherheit in der IT bedeutet nicht, keine Automatisierung zu nutzen. Es bedeutet, Kontrollmechanismen in die Automatisierung einzubauen.
💬 Kommentare (0)