Übergabe von Geheimnissen an einen Docker-Container


26

Ich habe ein Basis-Docker-Image, mit dem eine Bildanalysesoftware ausgeführt wird. Für jeden aus dem Image erstellten Container gibt es eine Reihe von Konfigurationseinstellungen, von denen einige Geheimnisse (Verschlüsselungsschlüssel, Kundeninformationen usw.) sind, die von der Software zum Analysieren und Verteilen der verarbeiteten Images verwendet werden. Wie kann ich diese Geheimnisse sicher an einen Container weitergeben?


Hashicorp Gewölbe
030

Antworten:


23

Sie haben 3 Methoden, um Geheimnisse für eine App in einem Docker-Container zu erlangen. Bei den ersten beiden handelt es sich um eine Docker-Konfiguration. Die letzte Möglichkeit besteht darin, dass Ihre Apps Geheimnisse direkt aus einem geheimen Speicher abrufen.

1 - Umgebungsvariablen

Laut "The 12 Factor App" -Anleitung handelt es sich bei den Geheimnissen lediglich um Konfigurationsdaten, die immer in der Umgebung festgelegt werden sollten. Sie können Ihre Geheimnisse während der Docker-Ausführung als Umgebungsvariablen festlegen, und Ihre App greift von dort auf sie zu.

2 - Bereitgestellte Volumes

Sie könnten alle Ihre Geheimnisse in einer bestimmten Konfigurations- / Geheimnisdatei haben und diese dann als bereitgestelltes Volume in Ihre Instanz einbinden .

3 - Aus dem Geheimladen holen

Wie @ 030 bereits erwähnt, können Sie Hashicorp Vault (oder "Amazon Secrets Manager" oder einen ähnlichen Dienst) verwenden.
Ihre App oder eine Beiwagen-App kann die Geheimnisse, die sie benötigt, direkt abrufen, ohne sich um eine Konfiguration des Docker-Containers kümmern zu müssen. Mit dieser Methode können Sie dynamisch erstellte Geheimnisse verwenden (eine sehr ansprechende Funktion solcher Systeme), ohne sich Gedanken darüber machen zu müssen, dass die Geheimnisse im Dateisystem angezeigt werden können oder die Umgebungsvariablen des Docker-Containers überprüft werden müssen.

Persönliche Meinung

Ich glaube, env-Variablen sind der richtige Weg. Es ist einfacher zu verwalten, und Sie können immer noch aus einem geheimen Speicher wie Hashicorp Vault abrufen, wenn Sie das CI-Build-System veranlassen, die Geheimnisse während des Builds abzurufen und sie bei der Bereitstellung festzulegen. Sie erhalten das Beste aus beiden Welten und den zusätzlichen Vorteil, dass Ihre Entwickler keinen Anwendungscode schreiben müssen, um Geheimnisse abzurufen. Entwickler sollten sich auf ihre Codefunktionalität konzentrieren und sich nicht mit Administratoraufgaben wie dem Abrufen von Kennwörtern befassen.

Der Code Ihrer Anwendung sollte sich auf die eigene App-Funktionalität konzentrieren und nicht auf Backend-Aufgaben wie das Abrufen von Kennwörtern. Genau wie in der 12-Faktor-App.

Bearbeiten: Der letzte Satz wurde geändert, um die Auswirkungen der Silierung zwischen Entwickler und SysAdmin zu beseitigen. Die Aufgaben selbst sollten aus der Sicht des Codes getrennt sein, aber DevOps handelt von denselben Personen, die beides im Auge behalten und nicht darauf beschränkt sind.

Persönliche Meinung (Update)

Laut @ Dirks ausgezeichnetem Kommentar ( Übergabe von Geheimnissen an einen Docker-Container ) gibt es ein sehr starkes Argument, einen geheimen Speicher vor ENV-Vars zu priorisieren, da diese nicht durchgesickert werden sollen.


2
Dies fördert Silos. DevOps macht Dinge zusammen, anstatt Dinge über die Mauer zu werfen.
030

2
Der Code sollte von den Infrastrukturkomponenten getrennt werden. Die tatsächlichen Personen könnten sowohl die Infrastrukturautomatisierung als auch die App-Codebasis codieren, die Aufgaben selbst sollten jedoch getrennt sein. Ich sehe, dass der letzte Satz meiner ursprünglichen Antwort die Entwickler, die Leute, davon abhält. Das ist ein fehler Ich werde das bearbeiten, um es klarer zu machen.
BoomShadow

7
Das Einfügen von Geheimnissen in Umgebungsvariablen bietet verschiedene Möglichkeiten für die Weitergabe von Geheimnissen. Einige Beispiele: Jeder, der Zugriff auf den Docker-Dämon auf dem Computer hat, auf dem der Container ausgeführt wird, kann sie mit den Befehlen inspectoder execanzeigen. Umgebungsvariablen werden häufig in stdoutoder in Protokolldateien abgelegt, wenn sie in einem Debug-Modus ausgeführt werden. Alle untergeordneten Prozesse können sie lesen und anzeigen, die möglicherweise außerhalb Ihrer Kontrolle liegen. Weitere Informationen zB hier: diogomonica.com/2017/03/27/…
Dirk

1
Ich setze mich auch mit dieser Frage auseinander. Das, was ich nicht verstehe, ist, dass Sie sich immer noch authentifizieren müssen, um Zugriff auf diesen Tresor zu erhalten, auch wenn Sie einen Tresor für Anmeldeinformationen verwenden, der vermutlich ein Geheimnis erfordert. Dasselbe gilt für die Verwendung einer kennwortgeschützten KeyStore-Datei. Haben wir es immer noch nicht geschafft, mindestens den "Meta-Berechtigungsnachweis" in der Umgebung zu übergeben?
Wheezil

1
@Wheezil Ein Meta-Berechtigungsnachweis ist einfacher zu sichern als viele bestimmte Berechtigungsnachweise. Sie können den Meta-Berechtigungsnachweis häufig und automatisch drehen. Der Meta-Berechtigungsnachweis kann zu einem Tresor gehen, der sich auf einem gesicherten Host befindet, und IP-Whitelists enthalten, sodass nur Verbindungen von Ihren Produktions-Subnetzen akzeptiert werden. Sie können auch sicherstellen, dass der Tresor die Verschlüsselung im Ruhezustand und die Verschlüsselung im Flug sowie das gegenseitige Festhalten von SSL und Zertifikaten und alle anderen Best Practices verwendet, die die Sicherheit erhöhen.
simbo1905

1

Es gibt eine andere Option nur mit Pipe:

docker run -d -i --name $n alpine sh -c 'read A; echo "[$A]"; exec some-server'
docker exec -i $n sh -c 'cat > /proc/1/fd/0' <<< _a_secret_

Erstellen Sie zunächst den Docker-Daemon mit -i. Der Befehl read Ableibt hängen und wartet auf die Eingabe von /proc/1/fd/0. Führen Sie dann den zweiten Docker-Befehl aus, lesen Sie das Geheimnis von stdin und leiten Sie zum letzten Hängeprozess weiter.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.