Wie verwalten Sie geheime Werte mit Docker-Compose v3.1?


72

Version 3.1 der Docker-compose.yml-Spezifikation bietet Unterstützung für Geheimnisse .

Ich habe es versucht:

version: '3.1'

services:
  a: 
    image: tutum/hello-world
  secret: 
    password: the_password
  b:
    image: tutum/hello-world

$ docker-compose up kehrt zurück:

Unsupported config option for services.secret: 'password'

Wie können wir die Geheimhaltungsfunktion in der Praxis nutzen?


Sind Sie sicher, docker-composedass Sie bereits Geheimnisse unterstützen? Welche docker-composeVersion laufen Sie?
Fzgregor

$ docker-compose --versionRückgabe: docker-compose version 1.11.0, build 6de1806Also, ja, es sollte Geheimnisse gemäß den Versionshinweisen unterstützen .
Eric

spät zur Party, aber soll es nicht Geheimnisse sein: und nicht geheim :?
Wellspring

Antworten:


124

Den entsprechenden Abschnitt können Sie der offiziellen Dokumentation entnehmen .

Um Geheimnisse zu nutzen, müssen Sie Ihrer docker-compose.ymlDatei zwei Dinge hinzufügen . Zunächst ein secrets:Block der obersten Ebene , der alle Geheimnisse definiert. Dann ein weiterer secrets:Block unter jedem Dienst, der angibt, welche Geheimnisse der Dienst erhalten soll.

Als Beispiel die beiden Arten von Geheimnissen zu schaffen , dass Docker verstehen: externe Geheimnisse und Datei Geheimnisse.

1. Erstellen Sie ein 'externes' Geheimnis mit docker secret create

Das erste: Um Geheimnisse mit Docker zu nutzen, muss der Knoten, auf dem Sie sich befinden, Teil eines Schwarms sein.

$ docker swarm init

Erstellen Sie als Nächstes ein "externes" Geheimnis:

$ echo "This is an external secret" | docker secret create my_external_secret -

(Stellen Sie sicher, dass Sie den letzten Strich einfügen -. Es ist leicht zu übersehen.)

2. Schreiben Sie ein weiteres Geheimnis in eine Datei

$ echo "This is a file secret." > my_file_secret.txt

3. Erstellen Sie eine docker-compose.ymlDatei, die beide Geheimnisse verwendet

Nachdem beide Arten von Geheimnissen erstellt wurden, finden Sie hier die docker-compose.ymlDatei, in der beide gelesen und in den webDienst geschrieben werden:

version: '3.1'

services:
  web:
    image: nginxdemos/hello
    secrets:                    # secrets block only for 'web' service
     - my_external_secret
     - my_file_secret

secrets:                        # top level secrets block
  my_external_secret:
    external: true
  my_file_secret:
    file: my_file_secret.txt

Docker kann Geheimnisse entweder aus seiner eigenen Datenbank (z. B. mit erstellte Geheimnisse docker secret create) oder aus einer Datei lesen . Das Obige zeigt beide Beispiele.

4. Stellen Sie Ihren Teststapel bereit

Stellen Sie den Stapel bereit mit:

$ docker stack deploy --compose-file=docker-compose.yml secret_test

Dadurch wird eine Instanz des webDienstes mit dem Namen erstellt secret_test_web.

5. Stellen Sie sicher, dass der vom Dienst erstellte Container beide Geheimnisse enthält

Verwenden Sie docker exec -ti [container] /bin/shdiese Option, um zu überprüfen, ob die Geheimnisse vorhanden sind.

(Hinweis: Im folgenden docker execBefehl unterscheidet sich der m2jgac...Teil auf Ihrem Computer. Führen Sie ihn aus docker ps, um Ihren Containernamen zu ermitteln.)

$ docker exec -ti secret_test_web.1.m2jgacogzsiaqhgq1z0yrwekd /bin/sh

# Now inside secret_test_web; secrets are contained in /run/secrets/
root@secret_test_web:~$ cd /run/secrets/

root@secret_test_web:/run/secrets$ ls
my_external_secret  my_file_secret

root@secret_test_web:/run/secrets$ cat my_external_secret
This is an external secret

root@secret_test_web:/run/secrets$ cat my_file_secret
This is a file secret.

Wenn alles in Ordnung ist, sollten sich die beiden Geheimnisse, die wir in den Schritten 1 und 2 erstellt haben, in dem webContainer befinden, der bei der Bereitstellung unseres Stapels erstellt wurde.


1
Ich erhalte dieses Ergebnis, wenn ich den ersten von Ihnen angegebenen Befehl ausführe: Error response from daemon: This node is not a swarm manager. Use "docker swarm init" or "docker swarm join" to connect this node to swarm and try again.Ich bin verwirrt! Muss ich einen Schwarm starten, um Docker-Compose mit Geheimnissen verwenden zu können?
Eric

2
Ups, ja, das tust du. Der docker stack deployBefehl ist Teil der Swarm-Engine. Ich werde in Schritt 1 eine Zeile hinzufügen, um dies anzuzeigen.
Mike Hearn

4
Ich verstehe die Gründe dafür nicht. Meine und viele andere Anwendungsfälle erfordern keinen Schwarm, aber Geheimnisse. Warum sollten wir einen Schwarm benutzen, wenn wir nur Geheimnisse wollen?
Eric

2
@ Vanuan, weil ich Geheimnisse brauche, um Container auf meinem Remote-Computer zu starten, nicht nur auf meinem lokalen Computer. Zum Beispiel hat das offizielle owncloud-Image eine docker-compose.yml, die Sie auffordert, das MySQL-Passwort als Umgebungsvariable aufzuschreiben, was eine schlechte Praxis ist. Ich dachte, Docker-Geheimnisse würden das lösen?
Eric

4
Geheimnisse können in Docker-Compose ohne Schwarm ab 1.11 verwendet werden, wenn Sie Dateien verwenden, die nicht extern sind. Beachten Sie jedoch, dass sie nicht sicher sind, da Compose kein Produktionswerkzeug ist und es, wie hier erwähnt, keinen Ort gibt, an dem sie verschlüsselt gespeichert werden können Schwarmfloß db. Wenn Sie dateibasierte Geheimnisse in der Compose-Datei richtig definieren, bindet Docker-Compose die Datei in / run / Secrets, um zu emulieren, was Swarm für einen einfacheren Entwickler-Workflow bei lokaler Arbeit tut. Wenn Sie einen sicheren Speicher auf einem Einzelknotenserver benötigen, können Sie einen Einzelknotenschwarm initiieren, der einwandfrei funktioniert.
Bret Fisher

16

Vorausgesetzt, Sie haben einen Dienst myappund eine Geheimdatei secrets.yml:

Erstellen Sie eine Erstellungsdatei:

version: '3.1'

services:
  myapp:
    build: .
    secrets:
      secrets_yaml

Stellen Sie mit diesem Befehl ein Geheimnis bereit:

docker secret create secrets_yaml secrets.yml

Stellen Sie Ihren Dienst mit diesem Befehl bereit:

docker deploy --compose-file docker-compose.yml myappstack

Jetzt kann Ihre App unter auf die geheime Datei zugreifen /run/secrets/secrets_yaml. Sie können diesen Pfad entweder in Ihrer Anwendung fest codieren oder einen symbolischen Link erstellen.


Die andere Frage

Diese Antwort bezieht sich wahrscheinlich auf die Frage "Wie stellen Sie Ihre Geheimnisse Ihrem Docker-Schwarm-Cluster zur Verfügung?".

Die ursprüngliche Frage "Wie verwalten Sie geheime Werte mit Docker Compose?" Impliziert, dass die Docker-Compose-Datei geheime Werte enthält. Das tut es nicht.

Es gibt eine andere Frage: "Wo speichern Sie die kanonische Quelle der secrets.ymlDatei?" Es liegt an dir. Sie können es in Ihrem Kopf speichern, auf ein Blatt Papier drucken, einen Passwort-Manager verwenden und eine spezielle Geheimdienstanwendung / Datenbank verwenden. Sie können sogar ein Git-Repository verwenden, wenn es selbst sicher gesichert ist. Speichern Sie es natürlich niemals in dem System, das Sie damit sichern :)

Ich würde Tresor empfehlen . So speichern Sie ein Geheimnis:

# create a temporary secret file
cat secrets.yml | vault write secret/myappsecrets -

So holen Sie ein Geheimnis ab und legen es in Ihren Hafenschwarm:

vault read -field=value secret/myappsecrets | docker secret create secrets_yaml -

Natürlich können Sie Docker-Cluster selbst als eine einzige Quelle der Wahrheit für Ihre Geheimnisse verwenden, aber wenn Ihr Docker-Cluster kaputt geht, haben Sie Ihre Geheimnisse verloren. Stellen Sie also sicher, dass Sie an anderer Stelle ein Backup haben.


Die Frage, die niemand gestellt hat

Die dritte Frage (die niemand gestellt hat) ist, wie Geheimnisse für die Maschinen der Entwickler bereitgestellt werden können. Dies kann erforderlich sein, wenn es einen externen Dienst gibt, der lokal nicht verspottet werden kann, oder eine große Datenbank, die nicht kopiert werden kann.

Auch hier hat Docker (noch) nichts damit zu tun. Es gibt keine Zugriffssteuerungslisten, die angeben, welche Entwickler auf welche Geheimnisse zugreifen können. Es gibt auch keinen Authentifizierungsmechanismus.

Die ideale Lösung scheint folgende zu sein:

  • Ein Entwickler öffnet eine Webanwendung.
  • Authentifiziert sich mithilfe eines Single Sign-On-Mechanismus.
  • Kopiert eine lange Liste von docker secret createBefehlen und führt sie im Terminal aus.

Wir müssen noch sehen, ob eine solche Anwendung auftaucht.


docker secret create scheint zu erfordern, dass es einen bereits vorhandenen Schwarm gibt? muss ich eine erstellen?
Eric

@Eric Also machst du das als Entwickler? Ich fürchte, Docker hat noch keine Unterstützung für diesen Anwendungsfall. Aber ja, Sie könnten einen Docker-Schwarm erstellen, der nur aus Ihrer Entwicklermaschine besteht. Das liegt außerhalb des Rahmens dieser Frage.
Vanuan

Ab dem 8. Februar unterstützt Docker-Compose 1.11 dateibasierte Geheimnisse in Compose-Dateien für lokale Entwickler. Siehe meinen Kommentar oben auf der gewählten Antwort für Details :)
Bret Fisher

@BretFisher, aber was bringt es, wenn es im Wesentlichen mit der Angabe von Volumes identisch ist ./file_based_secret:/run/secrets/my_secret?
Vanuan

@ Vanuan Richtig, es gibt keinen funktionalen Unterschied im Container. Es geht um einen nahtlosen Workflow und die Begrenzung des Bedarfs an mehreren Compopse-Dateien.
Bret Fisher

10

Sie können auch angeben , secretslokal in einer Datei mit gespeichert file:in secretsSchlüsselobjekt. Dann musst du sie nicht docker secret createselbst machen, komponiere / docker stack deploywerde es für dich tun.

version: '3.1'

secrets:
  password:
    file: ./password

services:
  password_consumer:
    image: alpine
    secrets:
      - password

Referenz: Verfassen der Datei Version 3 Referenz: Geheimnisse


Wie definiere ich mehrere Variablen in der passwordDatei?
Jinna Balu

1

Ist das der genaue Einzug Ihrer docker-compose.ymlDatei? Ich denke, sollte unter (dh einem der Dienste) verschachtelt sein , nicht direkt unter Abschnitt.secret secretsaservices


Ja, das war die genaue Einrückung. Ich habe versucht, das secretWörterbuch unter a(und auch auf der gleichen Ebene wie services) zu verschachteln und habe das gleiche Ergebnis erzielt.
Eric

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.