So schützen Sie sensible Daten mit Docker Compose Secrets

Die sichere Verwaltung von Geheimnissen ist ein wichtiger Aspekt der Containersicherheit. Wenn Sie Passwörter und API-Schlüssel als Umgebungsvariablen einfügen, riskieren Sie eine unbeabsichtigte Preisgabe von Informationen. Shell-Variablen werden oft ohne Ihr Wissen protokolliert, an untergeordnete Prozesse weitergegeben oder an Fehlerberichterstattungsdienste weitergegeben.

Das Einfügen von Werten als dedizierte Geheimnisse mindert diese Risiken. Docker verfügt über eine integrierte Unterstützung für die sichere Verwaltung von Geheimnissen, in die Sie sich mit Docker Compose einklinken können. Der Zugriff auf Geheimnisse wird pro Dienst gewährt.

Wie funktionieren Geheimnisse?

Die Docker-CLI verfügt über eine Reihe geheimer Verwaltungsbefehle, die jedoch nur mit Swarm-Clustern funktionieren. Sie können eigenständigen Containern keine Geheimnisse hinzufügen, indem Sie nur die Docker-Befehlszeilenschnittstelle verwenden.

Docker Compose fügte „gefälschte“ Geheimnisse hinzu, um diese Funktionen für Workloads ohne Cluster bereitzustellen. Die Implementierung von Compose funktioniert ähnlich wie die Docker Swarm-Funktionen und funktioniert mit jeder Compose-Datei.

Secrets werden als normale Textdateien erstellt, die in Ihre Container eingebunden werden. Ihre Anwendung greift auf den Wert des Geheimnisses zu, indem sie den Inhalt der Datei liest. Bei diesem Modell bleiben Werte im Gegensatz zu dauerhaft sichtbaren Umgebungsvariablen inaktiv, bis sie explizit in Ihrem Container verwendet werden.

Secrets in Compose-Dateien definieren

Ein Geheimnis in einen Container zu bekommen, ist ein zweistufiger Prozess. Zuerst müssen Sie das Geheimnis definieren, indem Sie die secrets der obersten Ebene verwenden Feld in Ihrer Compose-Datei. Anschließend aktualisieren Sie Ihre Dienstdefinitionen, um auf die erforderlichen Geheimnisse zu verweisen.

Hier ist ein Beispiel, das Geheimnisse verwendet, um ein Passwort sicher für einen Dienst bereitzustellen:

version: "3"
services:
  app:
    image: example-app:latest
    secrets:
      - db_password
secrets:
    db_password:
      file: ./db_password.txt

Der Wert des Geheimnisses wird aus der db_password.txt Ihres Arbeitsverzeichnisses gelesen -Datei, wenn Sie docker-compose up ausführen . Compose wird die Datei unter /run/secrets/db_password einhängen innerhalb des Behälters. Ihre App kann auf das Datenbankkennwort zugreifen, indem sie den Inhalt der geheimen Datei liest.

Vorhandene Docker-Secrets verwenden

Neben dateibasierten Geheimnissen können Sie mit Compose auch auf vorhandene Docker Swarm-Geheimnisse verweisen. Wenn Sie diesen Mechanismus verwenden, müssen Sie die Geheimnisse vorher in Docker erstellen Sie führen docker-compose up aus . Die docker secrets Command Space funktioniert nur, wenn Ihr aktiver Docker-Endpunkt ein Swarm-Manager-Knoten ist.

Erstellen Sie das Geheimnis mit der Docker-CLI:

# take value from standard input
echo P@55w0rd | docker secret create db_password -
 
OR 
 
# take value from a file
docker secret create db_password ./db_password.txt

Aktualisieren Sie jetzt Ihre Docker Compose-Datei, um auf das Geheimnis zu verweisen:

version: "3"
services:
  app:
    image: example-app:latest
    secrets:
      - db_password
secrets:
    db_password:
      external: true

Festlegen des external des Geheimnisses weist Compose an, seinen Wert aus Ihren vorhandenen Docker-Geheimnissen zu beziehen. Der Stack schlägt mit einem Fehler fehl, wenn Sie versuchen, ihn zu starten, bevor das Geheimnis existiert.

Erweiterte geheime Syntax

Compose unterstützt eine längere Secrets-Syntax, wenn Sie eine genauere Kontrolle über den Injektionsprozess benötigen. Wenn Sie zu dieser Syntax wechseln, können Sie Dateiberechtigungen anpassen und den gemounteten Namen des Geheimnisses ändern.

Fünf optionale Felder sind verfügbar:

• source – Der Name des zu referenzierenden Secrets – dies muss einer der Werte sein, die in den secrets Ihrer Compose-Datei definiert sind Abschnitt.
• target – Dateiname, der verwendet werden soll, wenn das Geheimnis in den Container gemountet wird.
• uid – UID, die für die bereitgestellte geheime Datei festgelegt werden soll. Der Standardwert ist 0.
• gid – GID zum Festlegen der gemounteten geheimen Datei. Der Standardwert ist 0.
• mode – Dateisystemberechtigungen, die auf die gemountete geheime Datei angewendet werden sollen, ausgedrückt in Oktalschreibweise. Dies ist standardmäßig 0444. Beachten Sie, dass geheime Dateien niemals beschreibbar sind, da sie immer in das temporäre Dateisystem eines Containers eingebunden werden.

Hier ist ein modifiziertes Beispiel, das die gemountete geheime Datei umbenennt und ihre Berechtigungen ändert:

version: "3"
services:
  app:
    image: example-app:latest
    secrets:
      - source: db_password
        target: database_password_secret
        mode: 0440
secrets:
    db_password:
      external: true

Die einfache Syntax ist in der Regel für die meisten Bereitstellungen ausreichend. Wenn Sie spezifischere Anforderungen haben, sollte Ihnen die erweiterte Version die Kontrolle geben, die Sie benötigen. Einzelne geheime Referenzen können die beiden Syntaxen innerhalb derselben Compose-Datei mischen und abgleichen.

Geheimnisse und Bildautorschaft

Viele beliebte Community-Docker-Images unterstützen jetzt Geheimnisse anstelle von Umgebungsvariablen. Als Bildautor ist das Anbieten von Geheimnissen ein bewährter Ansatz zum Schutz der Daten Ihrer Benutzer.

Sie können beide Mechanismen unterstützen, indem Sie zulassen, dass Umgebungsvariablen auf einen Dateipfad gesetzt werden. Wenn Ihr Bild eine Datenbankverbindung benötigt, lassen Sie Benutzer das DB_PASSWORD festlegen Umgebungsvariable entweder auf P@55w0rd oder /run/secrets/db_password . Ihr Container sollte prüfen, ob der Wert der Variablen auf eine gültige Datei verweist; Wenn dies der Fall ist, verwerfen Sie es und lesen Sie den endgültigen Wert aus der Datei aus.

Dieses Modell gibt Benutzern die Flexibilität, den am besten geeigneten Mechanismus für ihre Bereitstellung auszuwählen. Denken Sie daran, dass nicht alle Benutzer Geheimnisse annehmen können – wenn Swarm und Compose beide nicht verfügbar sind, haben sie keine Möglichkeit, ihre Werte bereitzustellen.

Schlussfolgerung

Die Verwendung von Geheimnissen anstelle von regulären Umgebungsvariablen verringert das Risiko einer unbeabsichtigten Offenlegung von Informationen. Stellen Sie sich ein Worst-Case-Szenario vor, bei dem ein Container seine Umgebungsvariablen an einen kompromittierten Protokollierungsdienst eines Drittanbieters sendet. Angreifer haben jetzt Ihr Datenbankpasswort und Ihre API-Schlüssel.

Durch die Beschränkung geheimer Daten auf den Zugriff auf das Dateisystem können Werte nicht versehentlich gelesen werden, da sie kein dauerhaftes Merkmal Ihrer Umgebung sind. Denken Sie jedoch daran, dass geheime Dateien ihre eigenen Risiken bergen. Sie könnten versucht sein, sie in die Quellcodeverwaltung zu übernehmen, was bedeuten würde, dass jeder mit Zugriff auf Ihr Repository ihre Werte lesen könnte.

Geheimnisse sollten während des gesamten Lebenszyklus Ihres Containers „geheim“ sein. Für Produktionsbereitstellungen ist es normalerweise am besten, Builds mit einem CI-System zu automatisieren. Legen Sie Ihre Geheimnisse in den Pipeline-Einstellungen Ihres CI-Anbieters fest und verwenden Sie dann Ihr Build-Skript, um sie in Dateien zu schreiben, auf die Compose zugreifen kann. Dadurch wird sichergestellt, dass nur Sie über die Schnittstelle Ihres CI-Tools Zugriff auf die tatsächlichen Werte haben.