Docker Secrets mit Compose verwalten
Was dieser Artikel über Docker Secrets mit Compose behandelt
- Was Docker Secrets sind und warum sie sicherer sind als Umgebungsvariablen.
- Welche Methoden es gibt, Secrets in Docker Compose zu verwalten.
- Wie Du externe Secrets mit Docker Swarm und Compose nutzt.
- Wie Du .env-Dateien richtig einsetzt und was Du vermeiden solltest.
- Welche typischen Stolpersteine bei Secrets in Docker auftreten und wie Du sie löst.
Einleitung: Docker Secrets verständlich erklärt
Secrets sind vertrauliche Daten wie Passwörter, API-Schlüssel, Tokens und Zertifikate. In Docker Compose müssen diese Secrets an die Container gelangen, ohne dass sie im Klartext in der docker-compose.yml stehen oder in der Kommandozeile auftauchen. Docker Secrets sind ein Mechanismus, der genau das sicher löst.
Dieser Artikel richtet sich an Entwicklerinnen und Entwickler, die Docker Compose einsetzen und Secrets sicher verwalten wollen. Du solltest verstehen, wie Docker Compose funktioniert und was Secret-Management bedeutet. Wer sich für die Sicherheitsthemen rund um Docker interessiert, findet auf IRC-Security.de weiterführende Informationen.
Warum brauche ich Docker Secrets?
Stell Dir vor, Du betreust einen Docker-Stack mit Nextcloud, PostgreSQL und Ollama. Jeder Dienst braucht Passwörter: die Datenbank für den Admin, Nextcloud für die DB-Verbindung, Ollama für die API. Wenn Du diese Passwörter als Umgebungsvariablen in die docker-compose.yml schreibst, stehen sie für jeden lesbar, der die Datei sieht.
Schlimmer noch: Umgebungsvariablen sind im Container sichtbar. Jeder, der in den Container kommt, kann mit env alle Passwörter auslesen. Sie landen in Logs, in Crash-Dumps und in Prozesslisten, die jeder Nutzer des Systems sehen kann.
Docker Secrets lösen das Problem, weil sie die Secrets in Dateien mounten, die nur für den jeweiligen Container sichtbar sind. Sie stehen nicht in den Umgebungsvariablen, nicht in der Prozessliste und nicht in den Logs.
Docker Secrets kurz erklärt
Docker Secrets sind vertrauliche Daten, die Docker verwaltet und den Containern als Datei zur Verfügung stellt. Der Container liest das Secret aus einer Datei unter /run/secrets/, statt es als Umgebungsvariable zu erhalten. Die Datei existiert nur im Speicher des Containers und wird nicht auf die Festplatte geschrieben.
Der Kerngedanke lautet: Secrets gehören in Dateien, nicht in Umgebungsvariablen. Dateien können geschützt, rotiert und auditiert werden, Umgebungsvariablen nicht.
Für wen ist Docker Secrets gedacht?
- Entwicklerinnen und Entwickler, die Docker Compose-Stacks mit sensiblen Daten betreiben.
- Systemadministratoren, die Secrets in Docker-Umgebungen verwalten.
- Sicherheitsverantwortliche, die sicherstellen wollen, dass Secrets nicht im Klartext exponiert sind.
- Self-Hoster, die ihre Dienste sicher betreiben wollen.
Vorkenntnisse in Docker Compose und grundlegendem Secret-Management sind hilfreich. Wer noch nie mit Docker Compose gearbeitet hat, sollte zuerst die Grundlagen lesen.
Wichtige Begriffe rund um Docker Secrets
- Secret - Vertrauliche Daten wie Passwörter, API-Schlüssel, Tokens. Wann nützlich: bei jedem Dienst, der sich authentifizieren muss.
- Docker Compose - Tool zum Definieren von Multi-Container-Stacks. Wann nützlich: für jeden Docker-Stack.
- Docker Swarm - Container-Orchestrierung mit eingebautem Secret-Management. Wann nützlich: wenn Du Secrets nativ verwalten willst.
- .env-Datei - Datei mit Umgebungsvariablen, die Docker Compose automatisch lädt. Wann nützlich: für Werte, die nicht hochsensibel sind.
- HashiCorp Vault - Zentrales Secret-Management-System. Wann nützlich: bei vielen Secrets und Rotation.
- Infisical - Open-Source-Secret-Manager. Wann nützlich: als Alternative zu Vault.
- Mozilla SOPS - Tool zum Verschlüsseln von Secrets in Dateien. Wann nützlich: wenn Du Secrets in Git versionieren willst.
Methoden für Secrets in Docker Compose
Es gibt mehrere Methoden, Secrets in Docker Compose zu verwalten. Jede hat ihre Vor- und Nachteile.
Methode 1: Umgebungsvariablen (nicht empfohlen)
Die einfachste, aber unsicherste Methode. Passwörter stehen als Umgebungsvariablen im Container und sind für jeden sichtbar, der in den Container kommt.
services:
postgres:
image: postgres:16
environment:
POSTGRES_PASSWORD: "mein-geheimes-passwort"
Diese Methode solltest Du nur für nicht-sensible Daten nutzen. Passwörter und API-Schlüssel gehören nicht hier rein.
Methode 2: .env-Datei
Die .env-Datei ist eine Datei im selben Verzeichnis wie die docker-compose.yml, die Docker Compose automatisch lädt. Die Variablen werden in der Compose-Datei referenziert.
.env:
POSTGRES_PASSWORD=mein-geheimes-passwort
docker-compose.yml:
services:
postgres:
image: postgres:16
environment:
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
Die .env-Datei sollte nicht ins Git-Repository kommen. Füge sie zur .gitignore hinzu. Diese Methode ist besser als Klartext in der Compose-Datei, aber die Passwörter landen trotzdem als Umgebungsvariablen im Container.
Methode 3: Docker Compose Secrets (empfohlen)
Docker Compose unterstützt Secrets seit Version 1.27. Du definierst Secrets im secrets-Abschnitt und bindest sie in die Container ein. Die Secrets werden als Datei unter /run/secrets/ im Container verfügbar.
services:
postgres:
image: postgres:16
environment:
POSTGRES_PASSWORD_FILE: /run/secrets/postgres_password
secrets:
- postgres_password
secrets:
postgres_password:
file: ./secrets/postgres_password.txt
Die Datei ./secrets/postgres_password.txt enthält das Passwort im Klartext. Docker liest die Datei und stellt den Inhalt dem Container als Datei unter /run/secrets/postgres_password zur Verfügung. Das Passwort steht nicht in den Umgebungsvariablen, sondern wird von der Anwendung aus der Datei gelesen.
Wichtig: Viele offizielle Images unterstützen die *_FILE-Konvention. Statt POSTGRES_PASSWORD nutzt Du POSTGRES_PASSWORD_FILE und gibst den Pfad zur Secret-Datei an. Das gilt für PostgreSQL, MySQL, Redis, Nextcloud und viele andere.
Methode 4: Externe Secrets mit Docker Swarm
Wenn Du Docker Swarm nutzt, kannst Du Secrets zentral verwalten und den Containern zur Verfügung stellen. Die Secrets werden verschlüsselt im Swarm gespeichert und nur den Containern zugänglich gemacht, die sie brauchen.
# Secret erstellen
echo "mein-geheimes-passwort" | docker secret create postgres_password -
# Secret in Compose nutzen
services:
postgres:
image: postgres:16
environment:
POSTGRES_PASSWORD_FILE: /run/secrets/postgres_password
secrets:
- postgres_password
secrets:
postgres_password:
external: true
Diese Methode ist die sicherste, weil die Secrets nicht in Dateien auf der Festplatte liegen, sondern im Swarm gespeichert werden. Voraussetzung ist aber ein laufender Swarm.
Methode 5: Secret-Management-Tools
Für größere Setups lohnt sich ein zentrales Secret-Management-System wie HashiCorp Vault oder Infisical. Diese Systeme verwalten Secrets zentral, rotieren sie automatisch und protokollieren jeden Zugriff.
Die Integration in Docker Compose erfolgt meist über Init-Container oder Sidecar-Container, die die Secrets abrufen und als Datei zur Verfügung stellen.
Praxisbeispiel: Ein Stack mit Docker Secrets
Stell Dir vor, Du willst einen Stack mit PostgreSQL, Nextcloud und Ollama aufsetzen. Alle drei brauchen Passwörter. Der Aufbau mit Docker Secrets sieht so aus:
- Secrets-Verzeichnis anlegen:
mkdir -p secrets - Secrets generieren:
openssl rand -base64 32 > secrets/postgres_password.txt openssl rand -base64 32 > secrets/nextcloud_password.txt openssl rand -base64 32 > secrets/ollama_api_key.txt chmod 600 secrets/*.txt - docker-compose.yml mit Secrets:
services: postgres: image: postgres:16 environment: POSTGRES_PASSWORD_FILE: /run/secrets/postgres_password secrets: - postgres_password volumes: - postgres-data:/var/lib/postgresql/data nextcloud: image: nextcloud:latest environment: POSTGRES_PASSWORD_FILE: /run/secrets/postgres_password NEXTCLOUD_ADMIN_PASSWORD_FILE: /run/secrets/nextcloud_password secrets: - postgres_password - nextcloud_password depends_on: - postgres ollama: image: ollama/ollama:latest environment: OLLAMA_API_KEY_FILE: /run/secrets/ollama_api_key secrets: - ollama_api_key volumes: - ollama-data:/root/.ollama secrets: postgres_password: file: ./secrets/postgres_password.txt nextcloud_password: file: ./secrets/nextcloud_password.txt ollama_api_key: file: ./secrets/ollama_api_key.txt volumes: postgres-data: ollama-data: - .gitignore anpassen: Füge
secrets/hinzu, damit die Secrets nicht ins Git kommen. - Stack starten:
docker compose up -d
Die Passwörter stehen nicht in der docker-compose.yml, nicht in den Umgebungsvariablen und nicht in den Logs. Jeder Container liest nur das Secret, das er braucht.
Secrets rotieren
Secrets sollten regelmäßig rotiert werden, besonders bei langfristig genutzten Diensten. Die Rotation mit Docker Compose Secrets sieht so aus:
- Neues Secret generieren:
openssl rand -base64 32 > secrets/postgres_password.txt.new - Altes Secret sichern:
cp secrets/postgres_password.txt secrets/postgres_password.txt.bak - Neues Secret aktivieren:
mv secrets/postgres_password.txt.new secrets/postgres_password.txt - Dienst neu starten:
docker compose up -d postgres
Wichtig: Bei Datenbanken muss das Passwort auch in der Datenbank selbst geändert werden. Das Secret in der Datei reicht nicht, das Passwort muss auch in der DB gesetzt werden. Bei PostgreSQL geht das mit ALTER USER postgres PASSWORD 'neues-passwort';.
Für automatisierte Rotation lohnt sich ein Tool wie HashiCorp Vault oder Infisical, das die Rotation automatisch übernimmt. Der Artikel Secret Rotation automatisieren geht darauf detailliert ein.
Typische Stolpersteine bei Docker Secrets
- Secrets im Git: Die .env-Datei und das secrets-Verzeichnis dürfen nicht ins Git. Prüfe Deine
.gitignore. - Falsche Dateiberechtigungen: Secret-Dateien sollten
chmod 600haben, damit nur der Besitzer sie lesen kann. *_FILE-Konvention nicht unterstützt: Nicht jedes Image unterstützt das Lesen von Passwörtern aus Dateien. Prüfe die Dokumentation des Images.- Secrets in Logs: Manche Anwendungen loggen Passwörter, wenn sie aus Dateien lesen. Prüfe die Logs nach dem Start.
- Keine Rotation: Wer jahrelang dasselbe Passwort nutzt, riskiert, dass es kompromittiert ist. Regelmäßige Rotation ist Pflicht.
- Secrets in Umgebungsvariablen als Fallback: Wenn ein Image
*_FILEnicht unterstützt, landen Passwörter oft doch in Umgebungsvariablen. Lieber ein anderes Image suchen oder selbst bauen. - Kein Backup der Secrets: Wenn die Secret-Dateien verloren gehen, sind die Dienste nicht mehr zugänglich. Secrets an sicherem Ort sichern.
- Secrets im Image: Manche Dockerfiles enthalten Passwörter als Umgebungsvariablen. Das ist ein massives Sicherheitsrisiko, weil jeder das Image inspizieren kann.
Weiterführende Links und Infos zu Docker Secrets
- Docker Compose optimieren - Best Practices für Compose-Dateien.
- Docker Swarm - Orchestrierung mit nativem Secret-Management.
- Docker Sicherheit - Container absichern.
- Secret-Management - Übersicht zu Secret-Management-Tools.
- HashiCorp Vault - Zentrales Secret-Management.
- Secret Rotation automatisieren - Passwörter automatisch rotieren.
- Umgebungsvariablen - Vor- und Nachteile von .env.
Key Takeaways:
- Docker Secrets sind sicherer als Umgebungsvariablen, weil sie als Datei im Container verfügbar sind.
- Die
*_FILE-Konvention erlaubt es vielen Images, Passwörter aus Dateien zu lesen. - .env-Dateien sind besser als Klartext in der Compose-Datei, aber nicht ideal.
- Externe Secrets mit Docker Swarm sind die sicherste Methode.
- Rotation, Backup und .gitignore sind Pflicht, keine Optionalitäten.
FAQ: Docker Secrets mit Compose - Typische Fragen
Was sind Docker Secrets?
Was ist der Unterschied zwischen .env und Docker Secrets?
Was ist die *_FILE-Konvention?
Brauche ich Docker Swarm für Secrets?
Wie rotiere ich Docker Secrets?
Wie verhindere ich, dass Secrets ins Git kommen?
Was mache ich, wenn ein Image *_FILE nicht unterstützt?
Wie sichere ich Docker Secrets?
Kann ich HashiCorp Vault mit Docker Compose nutzen?
Kann ich Secrets verschlüsselt im Git versionieren?
Quellen und weiterführende Literatur
- Docker Secrets Dokumentation - Offizielle Docker-Secrets-Docs.
- Docker Compose Secrets - Secrets in Compose.
- HashiCorp Vault - Zentrales Secret-Management.
- Mozilla SOPS - Verschlüsselte Secrets in Git.
- Infisical - Open-Source-Secret-Manager.


