Die sichere Geheimverwaltung ist ein wichtiger Aspekt der Containersicherheit. Wenn Sie Passwörter und API-Schlüssel als Umgebungsvariablen einfügen, riskieren Sie eine unbeabsichtigte Offenlegung von Informationen. Shell-Variablen werden oft ohne Ihr Wissen protokolliert, an untergeordnete Prozesse weitergegeben oder an Fehlerberichtsdienste weitergegeben.
Das Einfügen von Werten als dedizierte Geheimnisse verringert diese Risiken. Docker verfügt über eine integrierte Unterstützung für die sichere Geheimverwaltung, an die Sie sich mit Docker Compose anschließen können. Der Zugriff auf Geheimnisse wird pro Dienst gewährt.
Wie funktionieren Geheimnisse?
Die Docker-CLI verfügt über eine Reihe von Geheimnissen Verwaltungsbefehle, die jedoch nur mit Swarm-Clustern funktionieren. Sie können mit der Docker-CLI allein keine Geheimnisse zu eigenständigen Containern hinzufügen.
Docker Compose fügte “Fake” Geheimnisse, 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.
Geheimnisse werden als normale Textdateien erstellt, die in Ihre Container gebunden werden. Ihre Anwendung greift auf den Wert des Geheimnisses zu, indem sie den Inhalt der Datei liest. Bei diesem Modell bleiben Werte inaktiv, bis sie explizit in Ihrem Container verwendet werden, im Gegensatz zu permanent sichtbaren Umgebungsvariablen.
Definieren von Geheimnissen in Compose-Dateien
Ein Geheimnis in einen Container zu übertragen ist ein zweistufiger Prozess. Zuerst müssen Sie das Geheimnis definieren, indem Sie das geheime Feld der obersten Ebene in Ihrer Compose-Datei verwenden. Anschließend aktualisieren Sie Ihre Dienstdefinitionen, um auf die erforderlichen Geheimnisse zu verweisen.
Werbung
Hier ein Beispiel, in dem Geheimnisse verwendet werden, um einem Dienst ein Passwort sicher bereitzustellen:
version: “3” services: app: image: example-app:latest secrets: – db_password secrets: db_password: file: ./db_password.txt
Der Wert des Secrets wird aus Ihrem Arbeitsverzeichnis gelesen’ ;s db_password.txt-Datei, wenn Sie docker-compose up ausführen. Compose mountet die Datei nach /run/secrets/db_password innerhalb des Containers. Ihre App kann auf das Datenbankpasswort zugreifen, indem sie den Inhalt der geheimen Datei liest.
Bestehende Docker-Geheimnisse 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 in Docker erstellen, bevor Sie docker-compose up ausführen. Der Befehlsbereich docker secrets funktioniert nur, wenn Ihr aktiver Docker-Endpunkt ein Swarm-Manager-Knoten ist.
Erstellen Sie das Geheimnis mit der Docker-CLI:
# Wert vom Standardeingabeecho P@55w0rd | Docker-Geheimnis db_password erstellen – ODER # Wert aus einer Datei nehmen docker secret create db_password ./db_password.txt
Aktualisieren Sie nun 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
Setting the Secret’ ;s externes Feld 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 Secret-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 die Dateiberechtigungen anpassen und den bereitgestellten Namen des Geheimnisses ändern.
Fünf optionale Felder sind verfügbar:
- Quelle – Der Name des Secrets, auf das verwiesen werden soll – Dies muss einer der Werte sein, die im geheimen Abschnitt Ihrer Compose-Datei definiert sind.
- Ziel – 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, die für die bereitgestellte geheime Datei festgelegt werden soll. Standardmäßig 0.
- Modus – Dateisystemberechtigungen zur Anwendung auf die gemountete geheime Datei, ausgedrückt in oktaler Schreibweise. Der Standardwert ist 0444. Beachten Sie, dass geheime Dateien niemals beschreibbar sind, da sie immer in das temporäre Dateisystem eines Containers eingehängt werden.
Werbung
Hier 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 normalerweise 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 Bildautorenschaft
Viele beliebte Docker-Images der Community unterstützen jetzt Geheimnisse anstelle von Umgebungsvariablen. Als Bildautor ist das Anbieten von Geheimnissen ein bewährter Ansatz zum Schutz Ihrer Nutzer’ Daten.
Sie können beide Mechanismen unterstützen, indem Sie zulassen, dass Umgebungsvariablen auf einen Dateipfad gesetzt werden. Wenn Ihr Image eine Datenbankverbindung benötigt, lassen Sie die Benutzer die Umgebungsvariable DB_PASSWORD entweder auf P@55w0rd oder /run/secrets/db_password setzen. 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.
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, in dem ein Container seine Umgebungsvariablen an einen kompromittierten Drittanbieter-Protokollierungsdienst sendet. Angreifer haben jetzt Ihr Datenbankpasswort und Ihre API-Schlüssel.
Werbung
Indem Sie geheime Daten auf den Dateisystemzugriff beschränken, können Werte nicht versehentlich gelesen werden, da sie keine dauerhafte Funktion von Ihnen sind Umgebung. Denken Sie jedoch daran, dass geheime Dateien ihre eigenen Risiken bergen. Sie könnten versucht sein, sie in die Quellcodeverwaltung zu übernehmen, was bedeutet, dass jeder mit Zugriff auf Ihr Repository ihre Werte lesen könnte.
Geheimnisse sollten “geheim” während des gesamten Lebenszyklus Ihres Containers. 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 schreiben Sie sie dann mit Ihrem Build-Skript in Dateien, auf die Compose zugreifen kann. Dadurch wird sichergestellt, dass nur Sie über die Schnittstelle Ihres CI-Tools Zugriff auf die aktuellen Werte haben.