Wie Docker-Geheimnisse funktionieren und wo Entwickler sie missbrauchen
Docker-Geheimnisse wurden eingeführt, um sensible Daten wie API-Schlüssel, Datenbankkennwörter und Token sicher zu verwalten. Sie funktionieren, indem Geheimnisse als Dateien in /run/geheimnisse innerhalb eines Containers, nur für den containerisierten Dienst zugänglich. Dieser Mechanismus hält Geheimnisse aus Umgebungsvariablen und Protokollen fern, zumindest theoretisch. Das Problem beginnt, wenn Entwickler diesen Mechanismus umgehen. Anstatt die Docker Compose-Geheimnisse zu verwenden Funktion richtig, Geheimnisse sind oft fest codiert in Dockerfile, commitan Git übermittelt oder über Umgebungsvariablen eingefügt. Diese Abkürzungen machen Geheimnisse anfällig für eine versehentliche Offenlegung durch Protokolle, Containerebenen oder den Versionsverlauf.
# Risky
ENV DB_PASSWORD=mysecretpassword
⚠️ Unsicheres Beispiel, nicht in der Produktion verwenden
Sobald diese Zeile hinzugefügt ist, wird sie in das Bild eingefügt. Jeder mit Zugriff auf das Bild (Build-Cache, Registrierung oder CI/CD Protokolle) können es extrahieren. Schlimmer noch, dieses Muster bleibt bei Überprüfungen oft unbemerkt, weil es „einfach funktioniert“.
Docker Compose-Geheimnisse und die versteckten Risiken in gemeinsam genutzten Konfigurationen
Docker Compose vereinfacht Multi-Container-Apps, aber Docker Compose-Geheimnisse bergen versteckte Risiken. Entwickler teilen oft Docker Compose.yml or .env Dateien über Teams und Umgebungen hinweg, über Git, Slack oder freigegebene Laufwerke.
services:
app:
image: myapp
secrets:
- db_password
secrets:
db_password:
file: ./secrets/db_password.txt
⚠️ Anschauliches Beispiel: Fügen Sie keine echten Geheimnisse in versionierte Dateien ein
Das Problem? Diese Docker komponieren Referenzen gehen von lokalen Dateien aus, aber in der Praxis werden diese Dateien versioniert oder unsicher verteilt. Geheimnisse schleichen sich in Git-Repos ein, tauchen auf in pull requests, oder in andere Ordner kopiert werden. Die Annahme, dass „wir alle wissen, nicht zu commit „Geheimnisse“ ist keine Sicherheitsrichtlinie.
Schlimmer noch, Umgebungen wie Staging und Produktion können dieselben docker-compose.yml, wodurch ein falsches Gefühl der Trennung entsteht. Eine falsch konfigurierte .env Datei und Produktionsgeheimnisse werden in eine Testumgebung eingefügt.
CI/CD Pipelines: Wo die Handhabung von Docker-Geheimnissen fehlschlägt
In CI/CD, Docker Geheimnisse zerfallen, wenn sie nicht isoliert werden. Geheimnisse werden oft durchsickern an drei Stellen: Protokolle, Bildebenen und gemeinsam genutzte Läufer.
Logs: CI-Schritte drucken echo $SECRET_KEY um Probleme zu debuggen. Aber diese Protokolle werden gespeichert, manchmal öffentlich. Tools wie GitHub-Aktionen or Gitlab Speichern Sie Protokolle für Tage oder Wochen.
Bildebenen: Wenn eine Docker-Datei während des Builds ein Geheimnis hinzufügt:
RUN echo "$SECRET_KEY" > /app/config.txt
⚠️ Unsicheres Beispiel, das Geheimnisse in Bildebenen preisgibt
Dass Docker-Geheimnis ist nun Teil einer Bildebene. Auch wenn Sie die Datei später löschen, bleibt die vorherige Ebene im Bildverlauf erhalten.
Gemeinsam genutzte Läufer: Viele CI/CD Plattformen verwenden gemeinsam genutzte Runner. Wenn Geheimnisse nicht richtig definiert oder bereinigt sind, können andere Builds darauf zugreifen. Schlimmer noch: Geheimnisse werden manchmal standardmäßig als Umgebungsvariablen an alle Schritte übergeben.
Docker im Code sichern, Pipelines und Register
Zum Absperren Docker Geheimnisse, Entwicklungsteams benötigen mehrschichtige Abwehrmaßnahmen:
- Verwenden Sie geheime Manager wie AWS Secrets Manager, HashiCorp Vault oder Doppler. Diese Tools rotieren und fügen Geheimnisse zur Laufzeit sicher in Ihre Container ein.
- Bereiche begrenzen: Geben Sie niemals Produktionsgeheimnisse in Entwicklungs-/Testumgebungen preis. Verwenden Sie die rollenbasierte Zugriffskontrolle (RBAC), um einzuschränken, wer Geheimnisse einfügen oder lesen kann.
- Vermeiden Sie ENV-Variablen für Geheimnisse. Benutzen Docker-Geheimnis Volumes oder Mount-Geheimnisse explizit als Dateien.
- Builds bereinigen: Stellen Sie sicher, dass Geheimnisse nicht in Bilder eingebrannt oder in Zwischendateien belassen werden.
- Scannen Sie Container und Repos: Verwenden Sie Tools, die Bilder, Git-Verlauf und CI/CD Konfigurationen für durchgesickerte Geheimnisse.
Best Practices zum Verhindern der Offenlegung von Docker-Geheimnissen
- Vergängliche Geheimnisse: Generieren Sie während CI-Läufen einmalige Geheimnisse. Diese verfallen und können bei Diebstahl nicht wiederverwendet werden.
- Versiegelte Geheimnisse: Verwenden Sie Kubernetes Sealed Secrets oder SOPS, um Geheimnisse in Git zu verschlüsseln. Dadurch wird sichergestellt, dass Geheimnisse sicher versioniert werden.
- CI/CD Politik durchzulesen: Durchsetzung von Richtlinien wie keine Geheimnisse in Dockerfile, Blockaufbauten auf geheimer Erkennung und Protokollnutzung von Docker Geheimnisse für pipeline.
- Pre-commit hooks: Block commits mit Geheimnissen mit Werkzeugen wie Git-Geheimnisse or Geheimnisse erkennen.
- Unveränderliche Infrastruktur: Ändern Sie keine Geheimnisse in Containern. Erstellen Sie sie neu und stellen Sie sie mit neuen Docker Geheimnisse stattdessen.
Fazit
Bei Missbrauch Docker Geheimnisse zu einer Belastung statt zu einem Sicherheitsmerkmal geworden. Von Docker Compose-Geheimnisse durch YAML-Dateien zu CI/CD pipelineDurch die Offenlegung von Geheimnissen in Protokollen oder Schichten sind die Risiken real und vermeidbar.
Mit Werkzeugen wie Xygenikönnen Teams exponierte frühzeitig, setzen Sie Richtlinien zur Geheimhaltung durch und suchen Sie nach Sicherheitsabweichungen in Code, Containern und pipelines. Behandeln Sie Ihr DOcker-Geheimnis Strategie als kritische Infrastruktur. Sichern Sie sie, wie Sie es meinen.
