ping @ewindisch @diogomonica @NathanMcCauley Dies ist nur eine kurze Beschreibung . Fühlen Sie sich frei, die Beschreibung zu ändern / zu aktualisieren, wenn Sie der Meinung sind, dass dies erforderlich ist :)

Dies sind nützliche Informationen:

https://github.com/hashicorp/vault/issues/165

Wie ist das:

https://github.com/hashicorp/vault/issues/164

@dreamcat4 Es gibt einige Pläne, eine generische "Geheimnis-API" zu implementieren, die es Ihnen ermöglicht, entweder Vault oder Keywiz oder Sie-name-it mit Docker zu verwenden, aber alle auf die gleiche Weise. Es ist nur ein früher Gedanke, daher wird zusätzliche Forschung erforderlich sein.

@thaJeztah Yep Entschuldigung, ich möchte diese Bemühungen / Diskussion in keiner Weise beeinträchtigen. Ich denke eher, dass es vielleicht auch eine nützliche Übung ist (als Teil dieses längeren Prozesses und während wir warten), um zu sehen, wie weit wir jetzt kommen können. Dann zeigt es anderen deutlicher die Grenzen und Mängel des aktuellen Prozesses. Was zugrunde liegt, fehlt und musste am meisten hinzugefügt werden, um die Geheimnisse zu verbessern.

Es lohnt sich auch, über die verschiedenen Situationen von Laufzeitgeheimnissen im Vergleich zu Buildzeitgeheimnissen nachzudenken. Für die es auch einen Bereichsüberlappungsbereich gibt.

Und vielleicht (für Docker) lohnt es sich auch, Einschränkungen (Vor- und Nachteile) zwischen Lösungen in Betracht zu ziehen, die einen Mechanismus zur Verfügung stellen, um die Geheimnisse "im Speicher" zu handhaben. Im Gegensatz zu stärker dateibasierten Secrets-Methoden oder netzwerkbasierten, zB lokalen Secrets-Servern. Welches sind die aktuellen Hacks auf dem Tisch (bis zur richtigen Secrets-API). Dies kann uns helfen, einige der einzigartigen Vorteile (z. B. stärkere Sicherheit) zu verstehen, die durch eine Docker-Secrets-API hinzugefügt werden, die sonst nicht durch die Verwendung von Hacks zusätzlich zu den aktuellen Docker-Features erreicht werden könnten. Allerdings bin ich kein Sicherheitsexperte. Daher kann ich diese Dinge mit so großer Sicherheit nicht wirklich kommentieren.

@dreamcat4 ja, du hast recht; Kurzfristig sind diese Links in der Tat nützlich.

Es lohnt sich auch, über die verschiedenen Situationen von Laufzeitgeheimnissen im Vergleich zu Buildzeitgeheimnissen nachzudenken. Für die es auch einen Bereichsüberlappungsbereich gibt.

Vielen Dank! Ich glaube, das hatte ich in meiner ursprünglichen Beschreibung, muss dabei verloren gegangen sein. Ich werde einen Aufzählungspunkt hinzufügen

Allerdings bin ich kein Sicherheitsexperte.

Ich auch nicht, deshalb habe ich die Sicherheitsbetreuer "angepingt"; IMO, das sollte etwas von ihnen geschrieben sein 😇

@thaJeztah tolle Zusammenfassung. Ich werde versuchen, mich daran zu erinnern, wann immer ich Zeit finde.

@diogomonica, obwohl nicht _direkt_ bezogen, gibt es eine lange offene Funktionsanforderung für die Weiterleitung des SSH-Schlüsselagenten während des Builds; https://github.com/docker/docker/issues/6396 Angesichts der Anzahl der Kommentare wäre es gut, auch darüber nachzudenken. (Sollte überhaupt eine Entscheidung darüber getroffen werden, ob es umgesetzt werden kann/sollte)

Angenommen, Sie könnten Volumes als andere Benutzer als root mounten (ich weiß, dass es unmöglich ist, aber seien Sie witzig), wäre dies ein günstiger Ansatz, um Geheimnisse in Container zu bringen?

Wenn ja, würde ich für eine Alternative zu -v host_dir:image_dir plädieren, die die Verwendung eines Nur-Daten-Containers erwartet und wie -vc host_dir:image_dir (dh Volume-Kopie) aussehen könnte, wobei der Inhalt von host_dir in das Volume image_dir des Nur-Daten-Containers kopiert.

Wir könnten dann ein secure-data-only containers Paradigma hervorheben und zulassen, dass diese Volumes verschlüsselt werden

Ich habe kürzlich einen guten Artikel darüber von @jrslv gelesen, in dem er vorschlägt, ein spezielles Docker-Image mit Geheimnissen zu erstellen, nur um Ihre App zu erstellen, und dann ein weiteres Image zur Verteilung mit den Ergebnissen aus dem Ausführen des Build-Image zu erstellen.

Sie haben also zwei Dockerfiles:

• Dockerfile.build (hier kopieren Sie einfach alle Ihre Geheimnisse)
• Dockerfile.dist (diese werden Sie in die Registrierung verschieben)

Jetzt können wir unsere Distribution so aufbauen:

# !/bin/sh
docker build -t hello-world-build -f Dockerfile.build .
docker run hello-world-build >build.tar.gz 
docker build -t hello-world -f Dockerfile.dist ^

Ihre Geheimnisse sind sicher, da Sie niemals das hello-world-build Image pushen.

Ich empfehle, den @jrslv- Artikel für weitere Details zu lesen http://resources.codeship.com/ebooks/continuous-integration-continuous-delivery-with-docker

Danke fürs Teilen von @kepkin !
Habe gerade den Artikel zu Ende gelesen. Wirklich prägnant!

Ich mag die Idee, die Dateien zu exportieren und über ein separates Dockerfile zu laden. Es fühlt sich an, als würde man zerquetschen, ohne das Problem "Zwischenschichten im Build-Cache".

Ich bin jedoch nervös, dass dies die Entwicklung erschweren wird und der Einfachheit halber möglicherweise ein drittes Dockerfile erforderlich ist.

@kepkin nichts für ungut, aber das macht keinen Sinn. Geheimnisse sind definitiv nicht sicher, da sie sich im Tarball befinden und der Tarball ADD auf das Produktionsimage übertragen wird -- selbst wenn Sie den Tarball entfernen, ohne ihn zu zerquetschen, wird er in irgendeiner Schicht durchsickern.

@TomasTomecek Wenn ich das Beispiel richtig verstehe, ist der Tarball _nicht_ die Bildebenen, sondern nur die Binärdatei, die im Build-Container erstellt wurde. Siehe zum Beispiel; https://github.com/docker-library/hello-world/blob/master/update.sh (hier keine Geheimnisse, sondern nur ein einfaches Beispiel für einen Build-Container)

@TomasTomecek Ich spreche von Geheimnissen zum

@kepkin richtig, jetzt lese ich deinen Beitrag nochmal und kann ihn sehen. Das tut mir leid. Leider löst es das Problem nicht, wenn Sie während der Bereitstellung/Erstellung des Verteilungsimages Geheimnisse benötigen (zB beim Abrufen von Artefakten und Authentifizierung mit dem Artefaktdienst). Aber es ist definitiv eine gute Lösung für die Trennung zwischen Build-Prozess und Release-Prozess.

@TomasTomecek genau so hole ich eigentlich Artefakte.

Im Docker.build-Image lade ich einige binäre Abhängigkeiten vom Amazon S3-Image herunter, die AWS-Schlüssel und -Geheimnis erfordern. Nach dem Abrufen und Erstellen erstelle ich einen Tarball mit allem, was ich brauche.

Gibt es einen kanonischen "Best Practices"-Artikel - die "Do"s, die den "Don'ts" mitgeteilt werden -, die Sie alle empfehlen würden?

Es ist erwähnenswert (für alle anderen wie mich, die darüber stolpern), dass Docker Compose die Option env_file .

https://docs.docker.com/compose/compose-file/#env -file

@afeld docker selbst hat diese Funktion auch, siehe http://docs.docker.com/engine/reference/commandline/run/#set -environment-variables-e-env-env-file aber diese env-vars werden es trotzdem tun tauchen an den gleichen Stellen auf, also mach keinen Unterschied bezüglich "undicht"

Ich bin über diesen Spickzettel gestolpert: http://container-solutions.com/content/uploads/2015/06/15.06.15_DockerCheatSheet_A2.pdf

@kepkin So übergebe ich einen ssh-Schlüssel an docker build :

# serve the ssh private key once over http on a private port.
which ncat
if [ "$?" = "0" ]; then
  ncat -lp 8000 < $HOME/.ssh/id_rsa &
else
  nc -lp 8000 < $HOME/.ssh/id_rsa &
fi
nc_pid=$!
docker build --no-cache -t bob/app .
kill $nc_pid || true

und in der Dockerfile, wobei 172.17.0.1 die Docker-Gateway-IP ist:

RUN \
  mkdir -p /root/.ssh && \
  curl -s http://172.17.0.1:8000 > /root/.ssh/id_rsa && \
  chmod 600 /root/.ssh/id_rsa && chmod 700 /root/.ssh && \
  ssh-keyscan -t rsa,dsa github.com > ~/.ssh/known_hosts && \
  git clone --depth 1 --single-branch --branch prod [email protected]/app.git . && \
  npm i --production && \
  ... && \
  rm -rf /root/.npm /root/.node-gyp /root/.ssh

Wenn jemand etwas einfacheres hat, lassen Sie es uns wissen.

Wie ist also der aktuelle Stand dazu?

Den ganzen Sommer über gab es lange Gesprächsketten, die zeigten, wie weit verbreitet diese Sorge ist. Dies wurde im Mai eingereicht und ist noch offen. Wie würde ich beispielsweise das Passwort für Postgres festlegen?

@thaJeztah Was kann getan werden, um dies https://github.com/rancher/rancher/issues/1269

Ich schätze, was hier gemacht wird, wird _geheim_ gehalten :D

Dies ist für uns der größte Schwachpunkt bei der Integration von Docker in unseren Produktionsstack. Gibt es irgendwo eine Roadmap oder ein anderes Dokument, das auf Fortschritte in dieser Richtung hinweist?

Einige relevante Inhalte zu diesem Thema von k8s .

Was halten Sie davon, um Laufzeitgeheimnisse zu adressieren?
https://github.com/docker/docker/issues/19508

Ich denke, dieses Problem lässt sich am besten lösen, indem man sich auf einige Szenarien konzentriert, die unterstützt werden müssen, und sicherzustellen, dass es für jedes einzelne eine Reihe von Anweisungen gibt. Wie sie implementiert werden, ist weniger wichtig, als ob am Ende des Prozesses ein kohärenter Satz von Funktionen steht, die kombiniert werden können, um den Bedarf zu decken.

Einige, auf die ich Bezug genommen habe und die ziemlich legitime Bedenken zu sein scheinen, sind:

Laufzeit-Anmeldeinformationen

• Benutzer-/Passwortinformationen, die zwischen zwei Containern koordiniert werden, die sich ein link teilen
• Informationen sind leicht aus Ihrem Git-Repository herauszuhalten
• Informationen lassen sich leicht aus Ihren gepushten Bildern heraushalten (was ist mit lokalen Containern?)
• Informationen sind leicht aus .bash_history herauszuhalten (möglicherweise eine Brücke zu weit?)
• Einige Anwendungen erwarten Geheimnisse als Teil einer Konfigurationsdatei, die andere Informationen enthält
• Einige Anwendungen erwarten Geheimnisse als Umgebungsvariable
• Einige Anwendungen erlauben beides

Wenn ich „einfach“ sage, meine ich, dass es einen ergonomisch vernünftigen Ansatz für den Umgang mit diesen Variablen gibt, der den Benutzer davor schützt, versehentlich etwas Falsches zu tun und ein Sicherheitsbulletin auszulösen. Der Stress der Erfahrung wird oft mit den Werkzeugen in Verbindung gebracht, die an dem Fehler beteiligt sind.

Build-Time-Anmeldeinformationen

• Das Projekt wird aus einem oder mehreren privaten Repositorys erstellt (z. B.: package.json erlaubt Git-URLs)
• Der Builder befindet sich möglicherweise hinter einem passwortgeschützten Proxy
• Builder verwendet möglicherweise einen passwortgeschützten Cache
• Der Endbenutzer kümmert sich nur um ein funktionierendes Image (dh er verwendet Pull oder FROM, niemals docker build )
• Informationen lassen sich leicht aus Ihren gepushten Bildern heraushalten

1. Bearbeiten:

Dokumentation dessen, was in ein typisches Image, Container 'durchgesickert' ist und was nicht

• Welche Dateien landen im Bild (Nur das KOPIEREN und HINZUFÜGEN? noch etwas?)
• Welche Docker-Maschine behält, nachdem ein Image erstellt wurde (insbesondere boot2docker, aber was ist mit anderen?)
• Wie Umgebungs- und Befehlszeilenvariablen im Image erfasst werden und wo sie erfasst werden
• Erwartungen an PR-Emittenten bezüglich der Änderung dieser Verhaltensweisen

Ich habe das Gefühl, dass ich hier ein paar große vermisse. Hat jemand etwas, das ich vergessen habe?

API-Schlüssel für beliebige Json-Dienste.

Zum Beispiel (und dies ist mein echter Anwendungsfall) kompiliert Docker Build ein Programm, der API-Schlüssel ist erforderlich, um mich zu authentifizieren und die Build-Produkte auf Bintray.com hochzuladen.

@dreamcat4 Ich könnte weit von dem abweichen, was du sagst, aber so geht es:

Sprechen Sie davon, Docker-Images für Continuous Deployment-Builds zu verwenden und die Build-Artefakte am Ende eines erfolgreichen Builds in ein Archiv zu verschieben? Persönlich bevorzuge ich es, dies weiter stromaufwärts zu tun (zB ein Post-Build-Skript in Jenkins), aber wenn Sie Cross-Compiling durchführen, könnte dies etwas schwieriger sein.

In meiner Welt erstellt der Build-Agent nur Binärdateien/Archive und behält sie als 'Artefakte' des Build-Prozesses, und etwas anderes schiebt diese in die Infrastruktur, markiert das Git-Repository usw. Das gibt mir ein Notfall-Backup der Artefakte, wenn ich habe ein Produktionsproblem und mein npm-, Docker- oder Artifactory-Repository ist für Upgrades nicht verfügbar, oder das Netzwerk hat bei mir einen Fehler.

Der Punkt, den ich ansprechen wollte, war die Verwendung von API-Schlüsseln im Allgemeinen. Es gibt viele verschiedene und unterschiedliche Online-JSON-/Rest-Dienste, mit denen ein Container möglicherweise interagieren muss (entweder zur Build- oder zur Laufzeit) ... was API-Schlüssel erfordert. Muss nicht speziell auf den Build bezogen sein.

@dreamcat oh, also

Ja, ich denke, diese beiden Typen sollten in Bezug auf die Bewertung ihres grundlegenden Mindestsicherheitsniveaus unterschiedlich betrachtet werden.

API-Authentifizierungstoken sind in der Regel:

• Sind keine Passwörter
• Kann widerrufen werden
• Einige (eine viel weniger Teilmenge) sind Einwegartikel – wegwerfen. Und entkräften sich im Wesentlichen selbst.
• Häufig sind API-Dienste in ihrem Umfang auf nur eine Teilmenge der Funktionalität beschränkt. (dh schreibgeschützt oder kann nur eine bestimmte Aktion auslösen).

Passwörter sind/sind oft:

• Für einen umfassenderen Kontozugriff/-kontrolle.
• Einmal kompromittiert, kann der Angreifer auf etwas anderes umstellen (Aussperren). Oder eine andere Hintertür eingefügt (wie z. B. die DB-Änderung anderer Konten in der Datenbank im Fall von SQL).
• Ein Passwort zu sein birgt ein sehr hohes Risiko der „Wiederverwendung desselben Passworts“ bei anderen Konten. API-Schlüssel sind in der Regel immer eindeutig und können für nichts anderes verwendet werden.

Das bedeutet also nicht unbedingt, dass die Secrets-Lösung für diese beiden Typen _anders sein muss_. Nur, dass die akzeptable minimale Grundsicherheit für API-Schlüssel etwas niedriger sein kann.

Dieses Mindestniveau ist wichtig, wenn die Einrichtung einer starken Sicherheit komplexer / problematischer ist. (was hier im Fall von Docker-Geheimnissen zutreffen kann, oder auch nicht, je nachdem wie machbar/elegant die Lösung ist).

Und gelegentlich können API-Schlüssel von Passwörtern eine stärkere / schwächere Sicherheit haben. Nur wenn eine Einheitsgröße nicht möglich ist.

Zum Beispiel - mein Bintray-API-Schlüssel: Er befindet sich im selben .git-Repository wie mein Dockerfile. Um es sicher zu halten, wird es im PRIVATE git repo aufbewahrt (Zugriff über SSH). Der Zugriff auf den API-Schlüssel ist dort also relativ gut geschützt. Ohne jedoch, dass Docker über eigene eingebaute Secrets-Funktionalität / Schutz verfügt, enthält das erstellte Docker-Image immer den API-Schlüssel im Klartext. Daher muss das resultierende Docker-Build-Image privat gehalten werden, wie das Git-Repository ... was einen Knock-On (unerwünschte Wirkung) hat, dass niemand sonst die Build-Logs / den Build-Status dort öffentlich einsehen / sehen kann.

Das ist in vielerlei Hinsicht nicht optimal. Aber die Gesamtlösung ist einfach genug und funktioniert tatsächlich (wie in: gestern). Wenn es in Zukunft einen besseren Mechanismus geben würde, würde ich in Betracht ziehen, darauf umzusteigen. Aber nicht, wenn dieser Mechanismus wesentlich kostspieliger / komplexer zu installieren wäre als die aktuelle Lösung, die ich bereits gemacht habe. Daher kann extra starke Sicherheit (obwohl willkommen) im Fall von nur 1 API-Schlüssel übertrieben sein. Was nur mit einer Art neuer NOCAHCE-Option / Dockerfile-Befehl aus dem Cache für Bildebenen von Docker ferngehalten werden muss.

Wobei ein Passwort so etwas wie Vault oder Ansible-Vault benötigt und mit einem weiteren Passwort oder einem anderen stark sicheren Authentifizierungsmechanismus verschlüsselt werden muss. (Was wir nicht hoffen würden, aber möglicherweise eine komplexe Sache zu konfigurieren).

Ich denke, ein Client/Server-Modell (wie in Vault ) für die Verwaltung und Rationalisierung (sprich: Auditing, Break-Glass) aller geheimnisbezogenen Dinge wäre eine gute Praxis und würde die meisten Anwendungsfälle abdecken, wenn die Implementierung sorgfältig durchgeführt würde. Ich persönlich bin kein Fan eines nicht-ganzheitlichen Ansatzes, denn dies ist eine Gelegenheit, die Messlatte für Best Practices höher zu legen.

Dies impliziert einen Client mit langer Laufzeit (Verantwortung der Person, die ein Image bereitstellt) und/oder einen Build-Time-Client (Verantwortung des Builders). Vielleicht könnte ersteres irgendwie auf den Docker-Daemon übertragen werden, der zur Laufzeit autorisierte Geheimnisse bereitstellt.

In der Tat - ich stimme dem vorherigen Kommentar voll und ganz zu. Nicht, dass ich die kreative Art und Weise bewundere, mit der Leute das Problem lösen, aber ich denke nicht, dass es so sein muss - versuchen wir uns eine Lösung auszudenken, die sowohl während CI/D als auch zur Laufzeit verwendet werden könnte , sowie zu berücksichtigen, dass Container möglicherweise von Mesos/Kubernetes usw. orchestriert werden.

Nun, ich denke, ein bisschen Dokumentation wäre hier noch nützlich, da Docker ein paar zusätzliche Knicke im Problembereich bietet.

Es sieht so aus, als würden die Vault-Leute das vielleicht auch von ihrem Ende aus betrachten. Ich denke, dieses Ticket sollte man sich ansehen:

https://github.com/hashicorp/vault/issues/165

Vielleicht ist das etwas, woran man zusammenarbeiten könnte.

@jdmarshall

Vielleicht ist das etwas, woran man zusammenarbeiten könnte.

+1

+1 Docker + Hashi Corp Vault

Tut mir leid, aber ich mag nicht, wie die Lösungen komplexer werden, wenn mehr Leute mitmachen. Hashi Corp Vault zum Beispiel ist eine vollständige Client-Server-Lösung mit verschlüsseltem Back-End-Speicher. Das fügt erheblich mehr bewegliche Teile hinzu. Ich bin sicher, dass einige Anwendungsfälle dieses Maß an Komplexität erfordern, aber ich bezweifle, dass die meisten dies tun würden. Wenn die konkurrierende Lösung darin besteht, Hostumgebungsvariablen zu verwenden, bin ich mir ziemlich sicher, welche am Ende von der Mehrheit der Entwickler verwendet werden.

Ich suche nach einer Lösung, die Entwicklung (zB: Github-Schlüssel) und Bereitstellung (zB: Nginx-Zertifikatschlüssel, DB-Anmeldeinformationen) abdeckt. Ich möchte den Host nicht mit env vars oder Build-Tools beschmutzen und natürlich sollten keine Geheimnisse in github (unverschlüsselt) oder einem Docker-Image-Verzeichnis, auch nicht einem privaten, landen.

@gittycat Ich stimme Ihnen in dem Sinne zu, dass es wahrscheinlich mehrere verschiedene Anwendungsfälle gibt. Wobei einige der Lösungen einfacher sein sollten als andere.

Wir sollten jedoch auf jeden Fall vermeiden, auf ENV-Variablen zurückzugreifen.

Meine eigene Vorliebe tendiert zu der Idee, dass eine einfache Schlüsselspeicherung mit etwas Ähnlichem wie dem "Tresor"-Mechanismus von ansible erreicht werden könnte. Wo Sie eine verschlüsselte Textdatei im Build-Kontext (oder Quellen außerhalb / neben dem Build-Kontext) haben. Dann kann ein Entsperrschlüssel alle Klartext-Passwörter oder API-Schlüssel usw. aus dieser Datei entsperren.

Ich sage das nur, nachdem ich die eigene "Vault" -Lösung von anisible verwendet habe. Was relativ schmerzlos / einfach ist. Der Tresor von Hashicorp ist sicherer, aber auch schwieriger einzurichten und im Allgemeinen komplexer. Wobei ich keinen technischen Grund wüsste, warum man das darunter nicht letztendlich doch als Backend verwenden könnte (verstecke es / vereinfache es hinter einem Docker-orientierten Kommandozeilen-Tool).

Ich würde eine lokale Dateispeicherung vorschlagen, da dadurch die Einrichtung eines komplexen und potenziell unzuverlässigen HTTP-Schlüsselspeicherservers vermieden wird. Die Speicherung von Geheimnissen ist in hohem Maße eine Sicherheitsangelegenheit und sollte daher allen Benutzern zur Verfügung stehen, nicht nur für Unternehmen. Nur meine 2 Cent Meinung.

+1 zu einem lokalen Dateispeicher-Backend, für fortgeschrittenere Anwendungsfälle würde ich jedoch die volle Leistung einer Hashicorp Vault-ähnlichen Lösung bevorzugen. Wenn wir über den Einsatz in einer Organisation sprechen, wird argumentiert, dass diejenigen, die Geheimnisse bereitstellen und kontrollieren, andere Personen sind als diejenigen, die sie verwenden. Dies ist eine gängige Sicherheitsmaßnahme, um den Kreis der Personen mit Kontrollbefugnis auf sehr vertrauenswürdige Sicherheitsingenieure zu beschränken...

Ich weiß nicht, ob dies von Nutzen ist oder funktionieren würde, aber hier ist ein kleiner Vorschlag für das linke Feld, um den Fall zu lösen, in dem ich zur Laufzeit ein Geheimnis in einen Container injizieren möchte (z. B. ein Postgres-Passwort).

Wenn ich zum docker run Zeitpunkt den Einstiegspunkt überschreiben und auf ein Skript meiner Wahl setzen könnte, zB /sbin/get_secrets, das nach dem Abrufen von Geheimnissen von einem Mechanismus meiner Wahl (zB KMS) den ursprünglichen Einstiegspunkt ausführen würde (und wird so zu einem bloßen Wrapper, dessen einziger Zweck darin besteht, Umgebungsvariablen mit Geheimnissen INNERHALB des Containers einzurichten. Ein solches Skript könnte zur Laufzeit über ein Volume-Mount bereitgestellt werden. Bei einem solchen Mechanismus würden niemals Geheimnisse auf die Festplatte geschrieben ( einer meiner Lieblingshasser) oder von Docker durchgesickert (nicht Teil von Docker Inspect), würde aber sicherstellen, dass sie nur innerhalb der Umgebung von Prozess 1 innerhalb des Containers existieren, wodurch die 12-Faktoren-Struktur erhalten bleibt.

Das kann man (glaube ich) schon machen, wenn in den Image-Metadaten nicht Entrypoint verwendet wird, sondern nur cmd, da Entrypoint dann den Befehl umschließt. Wie bereits erwähnt, könnte der Wrapper dann zur Laufzeit über einen Volmount gemountet werden. Wenn der Einstiegspunkt bereits in den Bildmetadaten verwendet wird, können Sie dies meiner Meinung nach derzeit nicht erreichen, es sei denn, es ist möglich, den ursprünglichen Einstiegspunkt aus dem Container zu sehen (nicht die cmdline-Überschreibung) - nicht sicher, ob Sie dies tun können oder nicht .

Schließlich wäre es meiner Meinung nach sogar möglich, über die traditionelle env var-Injektion einen verschlüsselten Einmalschlüssel bereitzustellen, mit dem das externe /sbin/get_secrets die tatsächlichen Geheimnisse (zB das Postgres-Passwort) anfordern könnte, wodurch Docker eine zusätzliche Sicherung hinzugefügt wird den Einmalschlüssel durchsickern lassen.

Ich kann nicht herausfinden, ob dies nur Schichten auf Schichten sind oder ob das Problem möglicherweise gelöst wird. Entschuldigung, wenn nur die erste.

@thaJeztah - Ich kann bestätigen, dass die Lösung, die ich oben

@gtmtech Interessant. Würde mich interessieren, wie Sie aus Ihrer Binärdatei Get Secrets herausgefunden haben, was der ursprüngliche Einstiegspunkt war.

Vielleicht würde ein Beispiel-Code-Ordner den Ansatz etwas einfacher machen, um zu demonstrieren / zu verstehen.

Beispielcode und Arbeitsszenarien hier @ dreamcat4 @kaos >

https://github.com/gtmtechltd/secret-squirrel

Ich kann mich irren, aber warum diese komplizierten Methoden? Ich verlasse mich auf Standard-Unix-Dateiberechtigungen. Übergebe alle Geheimnisse an Docker mit -v /etc/secrets/docker1:/etc/secrets lesbar nur für Root und dann läuft ein Skript beim Containerstart als Root, das die Geheimnisse an entsprechende Stellen für relevante Programme (zB Apache config) weitergibt. Diese Programme verwerfen Root-Berechtigungen beim Start, sodass sie bei einem Hackerangriff später das Root-Geheimnis nicht lesen können. Ist diese Methode, die ich verwende, irgendwie fehlerhaft?

Danke @gtmtech :)
Leider haben wir weder einen Standard-Einstiegspunkt, noch kann ich Docker-Inspect vor dem Docker-Lauf kontrolliert ausführen. Aber mir gefällt Ihr Ansatz.

Ich kann mich irren, aber warum diese komplizierten Methoden? Ich verlasse mich auf Standard-Unix-Dateiberechtigungen. Übergebe alle Geheimnisse an Docker mit -v /etc/secrets/docker1:/etc/secrets nur für Root lesbar und dann läuft beim Containerstart als Root ein Skript, das die Geheimnisse an entsprechende Stellen für relevante Programme (zum Beispiel Apache) weitergibt konfigurieren). Diese Programme verwerfen Root-Berechtigungen beim Start, sodass sie bei einem Hackerangriff später das Root-Geheimnis nicht lesen können. Ist diese Methode, die ich verwende, irgendwie fehlerhaft?

Hi,
Ich stimme zu und denke, dass dieser Ansatz ^^ im Allgemeinen als bester Weg für RUNTIME-Geheimnisse empfohlen werden sollte. Es sei denn, irgendjemand hier hat einen starken Einwand dagegen. Danach kann man dann nachträglich auch noch alle verbleibenden Eckfälle (zur RUNTIME) auflisten, die dadurch nicht abgedeckt werden ^^.

Leider kann ich nicht sehen, wie das geheime Eichhörnchen abhebt, weil es für die meisten normalen Nicht-Techniker einfach zu kompliziert ist, um es als eine beliebte Strategie zu erlernen und zu übernehmen.

Dann bleibt (du hast es wahrscheinlich schon erraten)...
Bauzeit-Geheimnisse!

Aber ich denke, das ist ein Fortschritt! Da nach langer Zeit nicht wirklich weitergekommen, vielleicht halbiert und ca. 45-50% des Gesamtproblems gelöst.

Und wenn es immer noch Probleme mit Geheimnissen gibt, werden sie zumindest spezifischere / fokussiertere sein und können danach weiter voranschreiten / angehen.

Ja, ich werde nicht zu sehr ins Detail gehen, aber diese Ansätze würden für eine Situation, mit der ich gerade arbeite, nie funktionieren, da ich ein höheres Maß an Sicherheit benötige, als sie bieten. ZB keine unverschlüsselten Geheimnisse auf der Festplatte, keine gültigen Entschlüsselungsschlüssel, sobald sie im Zielprozess entschlüsselt wurden, regelmäßige Verschlüsselungsrotation und ein einziges Repository für verschlüsselte Geheimnisse (und nicht auf Server verteilt). Es ist also eher für Leute, die das von mir vorgeschlagene Sicherheitsniveau als möglichen Ansatz vorgeschlagen haben.

secret_squirrel ist sowieso ein Hack in einem Bereich, in dem ich noch keine praktikablen Lösungen sehen kann, etwa um Docker, der noch keine Secrets-API bereitstellt, oder einen steckbaren Secrets-Treiber, den sie hoffentlich irgendwann werden werden, aber vielleicht dient es zur Veranschaulichung dieser Einstellung ENV vars im Container vor Process Exec, aber nicht als Teil des Docker-Erstellungsprozesses (oder der Metadaten) ist eine sichere Methode, um 12-Faktor-kompatibel mit Geheimnissen zu sein, und vielleicht kann die Docker-Entwicklungsgemeinschaft diese Idee verwenden, wenn sie mit dem Aufbau eines secrets-api/driver, wenn sie denken, dass es gut ist!

Viel Spaß beim Docken!

Wir haben den Ansatz, den @gtmtech beschreibt, mit großem Erfolg verwendet. Wir injizieren KMS-verschlüsselte Geheimnisse über Umgebungsvariablen und lassen dann den Code im Container nach Bedarf entschlüsseln.

Normalerweise beinhaltet dies einen einfachen Shim-Einstiegspunkt vor der Anwendung. Wir implementieren dieses Shim derzeit mit einer Kombination aus Shell und einer kleinen Golang-Binärdatei (https://github.com/realestate-com-au/shush), aber ich mag den Klang des Pure-Go-Ansatzes.

@gtmtech @mdub Ich würde mich auf jeden Fall freuen, mehr davon zu sehen.
@dreamcat4 Ich denke, die Definition von "kompliziert" könnte pfadabhängig sein, was offensichtlich ganz in Ordnung ist. Dennoch kann es sich wahrscheinlich nicht um ein abstrahierbares Urteil handeln. Daher erscheint mir ein Sicherheits-Wrapper innerhalb des Docker-Containers auf Designebene jedoch nicht allzu kompliziert. Ein weiterer Aspekt sind Best Practices: Diese müssen nicht nur aus der Entwicklerperspektive, sondern aus der Betriebsperspektive betrachtet werden.
meine 2 Cent

Tresor +1

Tresor -1. Vault hat einige Betriebseigenschaften (Entsiegelung), die es für viele Leute wirklich unerwünscht machen.

Eine steckbare API wäre am sinnvollsten.

Theres auch ansibles Tresor. Das ist eher ein anderes Tier.

@gtmtech danke für den Vorschlag, er hat mich dazu inspiriert, diesen Einstiegspunkt zu schreiben:

#!/bin/bash

if [ -d "/var/secrets" ]; then
  tmpfile="$(mktemp)"
  for file in /var/secrets/*
  do
    if [ -f $file ]; then
      file_contents=$(cat $file)
      filename=$(basename "$file")
      underscored_filename="${filename//-/_}"
      capitalized_filename=${underscored_filename^^}
      echo "export $capitalized_filename=$file_contents" >> $tmpfile
    fi
  done

  source $tmpfile
  rm -f $tmpfile
fi

exec "$@"

Ich füge es einfach so in das Dockerfile (vergiss nicht chmod + x darauf):

ENTRYPOINT ["/app/docker-entrypoint.sh"]

Und voila. Zur Laufzeit verfügbare ENV-Variablen. Gut genug :)

Wenn ich das richtig verstehe, sollte das /var/secrets über Volumes gemountet werden, oder??
Auch wenn es Kommentare dazu gibt, dass Geheimnisse nicht auf Disc geschrieben werden, wie schlimm ist es dann, sie auf Disc zu schreiben und sie dann zu löschen???

Schön! Sie sollten jedoch shred , um die Datei sicher zu löschen.

Am Donnerstag, 3. März 2016, Juan Ignacio Donoso [email protected]
schrieb:

Wenn ich das richtig verstehe, sollte das Verzeichnis /var/secrets durch gemountet werden
Volumen richtig??
Auch wenn es Kommentare dazu gibt, dass Geheimnisse nicht auf Disc geschrieben werden, wie?
schlecht ist sie auf Disc zu schreiben und dann zu löschen???

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/docker/docker/issues/13490#issuecomment -191887424.

Rui Marinho

Inspiriert von @gtmtechs "geheimem Eichhörnchen" habe ich mein Geheimverwaltungs-Tool "shush" erweitert, um es als Bildeinstiegspunkt nutzbar zu machen:

ADD shush_linux_amd64 /usr/local/bin/shush
ENTRYPOINT ["/usr/local/bin/shush", "exec", "--"]

Dadurch werden alle KMS_ENCRYPTED_xxx Envariablen entschlüsselt und die Ergebnisse wieder in die Umgebung eingefügt.

https://github.com/realestate-com-au/shush#use -as-a-command-shim

Der Thread beginnt also mit TUN SIE KEINES VON DIESEN DINGEN.....

... aber ich sehe keine.

Was IST die offizielle Best-Practice für jetzt? Als Docker-Benutzer ist es etwas frustrierend, eine lange Liste von Dingen zu sehen, die wir nicht tun sollten, aber dann keine offiziellen Alternativen angeboten bekommen. Verpasse ich etwas? Existiert einer nicht? Ich bin mir sicher, dass Dinge hinter den Kulissen passieren und dass das Docker-Team daran arbeitet, aber wie gehen wir im Moment am besten mit der Geheimverwaltung um, bis eine kanonische Lösung präsentiert wird?

@alexkolson
Soweit ich verstanden habe, sollten Sie, wenn Sie Geheimnisse zur Laufzeit benötigen, entweder Volumes (Dateisystemgeheimnisse) oder einige Dienste wie HashiCorp Vault (Netzwerkgeheimnisse) verwenden.

Bei Build-Time-Geheimnissen ist es komplizierter.
Volumes werden zur Build-Zeit nicht unterstützt, daher sollten Sie Container verwenden, um Befehle auszuführen, die das Dateisystem ändern, und Docker-Commit verwenden.

Was also fehlt, ist eine Möglichkeit, Geheimnisse während der Build-Zeit zu verwalten, indem Sie nichts außer einer Dockerdatei verwenden, ohne dass docker commit .

Einige Leute sagen sogar, dass die Verwendung eines Dateisystems für Geheimnisse nicht sicher ist und dass der Docker-Daemon eine API bereitstellen sollte, um Geheimnisse sicher bereitzustellen (mit Netzwerk/Firewall/automatisch bereitgestelltem Volume?). Aber niemand hat eine Vorstellung davon, wie diese API aussehen und wie man sie verwenden würde.

Wenn ich an Unzulänglichkeiten von env vars denke, denke ich an nicht dockerspezifische Probleme wie:

1. Aggregieren von Protokollen, die alle env vars oder vergessene phpinfo auf einem Produktions-Webserver abfangen - seien Sie also vorsichtig mit den Geheimnissen und der richtigen Konfiguration.
2. Vielleicht ein Trojaner, der env vars enthüllt - also keine nicht vertrauenswürdige Software ausführen.
3. Angriffe, die Schwachstellen ausnutzen, wie z. B. SQL-Injection – validieren Sie die Eingaben und verwenden Sie eine Web-App-Firewall.

Die Schwächen, die oben in diesem Thread vorgestellt wurden:

Zugänglich für jeden Vorgang im Behälter, dadurch leicht "ausgesickert"

1 & 2 von oben kreuzen. Legit, aber mit Vorsicht angesprochen, oder? Außerdem führt Ihr Docker-Container weit weniger Prozesse aus als ein Full-Stack-Webserver.

Was ist mit der Konfiguration in env var, aber geheime env vars haben verschlüsselte Werte und die App hat den Schlüssel im Code? Dies ist nur eine Verschleierung, da der Schlüssel im Code enthalten ist, aber Exploits erfordern würde, um sowohl auf den Schlüssel als auch auf die env vars zuzugreifen. Verwenden Sie möglicherweise die Konfigurationsverwaltung, um den Schlüssel auf dem Docker-Host statt im App-Code zu verwalten. Kann bei Rouge-Prozessen und versehentlichen Lecks helfen, aber offensichtlich nicht bei Injektionsangriffen von jemandem, der den Schlüssel hat.

In Zwischenebenen eines Bildes beibehalten und in Docker Inspect sichtbar

Backen die Leute Umgebungsvariablen in Docker-Images, anstatt sie zur Laufzeit einzustellen, oder missverstehe ich diese. Niemals Geheimnisse in Artefakte zurückverwandeln, oder? Ja sudo docker inspect container_name gibt die env var, aber wenn Sie auf meinem Produktionsserver sind, dann ist ich bereits verloren. sudo docker inspect image_name hat keinen Zugriff auf meine zur Laufzeit festgelegten Umgebungsvariablen.

Mit jedem Container geteilt, der mit dem Container verknüpft ist

Wie wäre es, stattdessen auf Links und die neue Vernetzung zu verzichten?

Das einzige Problem, das wie ein Docker-Problem aussieht und nicht universell ist, sind Links ...

Setzen Sie mich in das Lager der Leute, die während docker build einen guten Weg brauchen, um mit Geheimnissen

Ich habe keinen guten und vernünftigen Weg gefunden, mit dieser misslichen Lage umzugehen, ohne einige der anderen Dinge zu besiegen, die ich an Docker vorteilhaft finde (siehe: docker squash ).

Ich musste jetzt einen Rückschritt darin machen, Teile der Anwendung außerhalb des Containers zu erstellen und COPY zu verwenden, um das Endprodukt in den Container zu bringen. Meh.

Ich denke, dass docker build einige Funktionen benötigt, um kurzlebige Daten wie Geheimnisse zu behandeln, damit sie nicht ihren Weg in den endgültigen Versandbehälter finden.

Ich denke, Docker-Build benötigt einige Funktionen, um mit kurzlebigen Daten wie Geheimnissen umzugehen

Dies ist eher ein philosophisches als ein technisches Problem. Solche kurzlebigen Daten würden den wesentlichen Vorteil von Docker zunichte machen: die Reproduzierbarkeit.

Die Philosophie von Docker ist, dass Ihre Dockerfile zusammen mit einem Kontext ausreicht, um ein Image zu erstellen.
Wenn Sie einen Kontext außerhalb des resultierenden Images benötigen, sollten Sie ihn aus dem Netzwerk abrufen und das Schreiben in das Dateisystem überspringen. Denn jede Dockerfile-Zeile führt zu einem Dateisystem-Snapshot.

Wenn Geheimnisse nicht Teil eines Images sein sollten, könnten Sie einen ephemeren Container ausführen, der alle Ihre geheimnisgeschützten Ressourcen spiegelt/vollzieht und einen geheimnislosen Zugriff bietet. Die Spiegelung hat übrigens eine andere Begründung: https://developers.slashdot.org/story/16/03/23/0652204/how-one-dev-broke-node-and-thousands-of-projects-in-11-lines -von-javascript

Sie können auch den SSH-Schlüssel selbst teilen, aber Sie könnten seine Verwendung nicht kontrollieren.

@bhamilton-idexx Wenn Sie sicherstellen, dass die Authentifizierung für Ihre privaten Repositorys mit einem kurzlebigen Token funktioniert, müssen Sie sich keine Sorgen machen, dass das Geheimnis im Docker-Image beibehalten wird.
Sie lassen das Build-System ein Token mit einer ttl von 1 Stunde generieren, stellen dieses dem Docker-Build als Umgebungsvariable zur Verfügung.
Sie können die erforderlichen Build-Details abrufen, aber das Geheimnis läuft kurz nach Abschluss Ihrer Builds ab, wodurch dieser Angriffsvektor geschlossen wird.

Ich habe jetzt eine Reihe dieser Threads gelesen und eine Funktion, die hier einige Anwendungsfälle lösen würde und Anwendungsfälle außerhalb von Geheimnissen hätte, ist ein --add Flag für docker run , das eine Datei in den Container kopiert, genau wie die ADD Anweisung in Dockerfiles

Dieser Artikel ist A+ http://elasticcompute.io/2016/01/21/runtime-secrets-with-docker-containers/

Das ist in der Tat ein toller Artikel. Sehr gut zu lesen. Und genau das, was wir uns erhofft haben.

Übrigens:

Habe auch ein paar andere geheime Tools gefunden, die dort aus dem Artikel anscheinend übersehen wurden. Entschuldigung für eventuelle Wiederholungen / Vervielfältigungen. Ist mir auch noch nicht aufgefallen, dass sie hier erwähnt werden:

Bauen Sie Zeitgeheimnisse auf:

https://github.com/defunctzombie/docket

Laufzeit-Geheimnisse:

https://github.com/ehazlett/docker-volume-libsecret

Was denken die Leute? Vielen Dank.

Für mich:

Diese neueren Tools ^^ sehen jetzt sehr gut aus. Und sie existierten sicherlich nicht, als wir dieses Ticket zum ersten Mal starteten. ABER die Hauptsache fehlt mir jetzt noch am meisten:

Bessere Funktionen für Build-Time-Geheimnisse auf dem DockerHub. Was dort schlecht ist und eine Entweder-Oder-Entscheidung erzwingt. Wir müssen auf die Vorteile der einen Lösung zugunsten der anderen verzichten. Je nachdem, welcher Gesamtsatz von Feature(s) wichtiger ist. Da lokale Gebäude definitiv besser sind, um Geheimnisse zu schützen, aber verständlicherweise schlechter als der Dockerhub in anderer Hinsicht.

Wir haben ein weiteres Tool geschrieben, ähnlich wie docket, das das neue Bildformat verwendet:

https://github.com/AngryBytes/docker-surgery

Unsere Implementierung erstellt zuerst einen Layer mit den kommentierten Geheimnissen SECRETS , erstellt dann eine Kopie des Dockerfiles mit einem modifizierten FROM , erstellt und entfernt schließlich alle SECRETS Layer aus dem resultierenden Image.

Es gibt immer Vorbehalte, dies zu hacken, und es wäre gut, wenn Docker eine Rebasing- oder Layer-Splicing-Funktionalität eingebaut hätte. Das Entfernen von Zwischenschichten ist jetzt langsam, da alle Lösungen hinter den Kulissen einen docker save / docker load Tanz machen müssen.

Außerdem ist das Build-Caching defekt. Im Moment verwenden wir docker commit , um die kommentierte Secrets-Ebene zu erstellen, aber einen ordnungsgemäßen Cache dieser Ebenen zu verwalten, ist immer noch eine Menge Arbeit, die wir wahrscheinlich nicht tun werden. Die Verwendung einer Dockerfile zum Erstellen des Secrets-Layers kann dies lösen, aber es gibt keine Möglichkeit, den Layer zu kommentieren, was es schwierig macht, genau zu bestimmen, was danach entfernt werden soll.

@Vanuan [Dockerfile] kann keine Reproduzierbarkeit haben. Der RUN-Befehl garantiert, dass Sie und ich vernünftigerweise nicht erwarten können, aus zwei Durchläufen genau das gleiche Bild zu erhalten. Wieso den? Weil die Leute meistens RUN verwenden, um auf Netzwerkressourcen zuzugreifen. Wenn Sie das gleiche Bild wie ich haben möchten, müssen Sie Ihr eigenes Bild "VON" von mir erstellen. Keine andere Anordnung wird uns die gleichen Bilder geben. Keine andere Anordnung kann uns die gleichen Bilder geben. Alle dauerhafte Reproduzierbarkeit kommt von Docker Hub, nicht Dockerfile.

Wenn die einzige Verteidigung, warum wir keine ephemeren Daten haben können, darin besteht, dass Docker glaubt, alle ephemeren Daten entfernen zu können, dann müssen Sie die RUN-Anweisung verwerfen.

@stephank Ich habe bei der Arbeit ein Docker-Build-Tool implementiert, das einen etwas anderen Ansatz verfolgt. Meine Hauptsorge galt nicht den Geheimnissen der Build-Zeit, aber es kümmert sich auch darum (die Geheimnisse aus dem gebauten Image herauszuhalten, das heißt, wie Sie überhaupt an die Geheimnisse kommen, liegt an Ihnen).

Und zwar durch Ausführen eines "Build-Managers" mit dem Projektcode in einem VOLUME. Der Manager führt dann eine beliebige Anzahl von Build-Tools in separaten Containern aus, die den Projektcode mithilfe von Volumes des Managers mounten. Alle erstellten Artefakte und anderen produzierten Dateien werden also im Manager-Volume aufbewahrt und folgen der Build-Pipeline für jeden Build-Schritt. Am Ende kann der Manager unter Verwendung des erzeugten Build-Ergebnisses ein endgültiges Produktions-Image erstellen. Alle dabei benötigten Geheimnisse waren im Manager und/oder den Build-Containern verfügbar, aber nicht das endgültige Image. Es werden keine Docker-Image-Assistenten verwendet, und Build-Caches funktionieren wie erwartet.

Wie die Build-Pipeline aussieht, hängt ganz vom Projekt ab, das eine Spezifikationsdatei verwendet, die die Build-Anforderungen konfiguriert.

Tatsächlich bin ich ziemlich gehypt auf dieses Tool, ich warte nur darauf, dass wir es als Open Source veröffentlichen können (vorbehaltlich der Verabschiedung der Richtlinien des Unternehmens).

@kaos Einerseits wollte ich nicht von den Docker-Standardtools abweichen. Auf der anderen Seite denke ich, dass es wirklich mehr Konkurrenz zwischen den Image-Build-Tools geben sollte. Das klingt also interessant! 😀

@thaJeztah für Umgebungsgeheimnisse (12-Faktor) sperren wir den Docker-Daemon über Twistlock (+Scalock), um das Durchsickern von Umgebungsvariablen über inspect zu verhindern. Es wäre großartig, wenn wir eine Docker-native Möglichkeit hätten, nicht so viele privilegierte Informationen über Inspect preiszugeben, um dies zu einer realistischeren Realität zu machen.

@alexkolson Ich denke, der Schlüssel zu diesem Thread ist "DONT DOTHIS", es sei denn, Sie haben X, Y, Z gemildert. Es ist eindeutig ein technischer Spinner - es wird immer "Lösungen" für allgemeine Probleme geben. Das heißt, es ist wichtig, aufzuklären, was man nicht tun sollte und warum, damit die echten Problemumgehungen beginnen können. Der Teufel steckt immer in den Standardeinstellungen – daher müssen wir sicherstellen, dass neue Benutzer verstehen, was gefährdet ist.

Vielleicht können mir ja einige von euch helfen, da ich noch nicht so viel Erfahrung mit Docker habe.
Ich habe einen Hashicorps-Tresor benutzt, um meine Geheimnisse zu holen.

Im Grunde habe ich ein Token als Build-Argument übergeben und das Token kann verwendet werden, um vertrauliche Informationen aus Vault abzurufen. Dies geschieht zur Erstellungszeit und kann nur erfolgreich sein, wenn der Tresor im Zustand "unversiegelt" (zum Abrufen von Daten geöffnet) ist. Nach dem Erstellen wird der verwendete Token widerrufen.

Aber ich glaube, ich habe noch einige allgemeine Probleme.

• Ich muss neue Bilder erstellen, wenn sich sensible Daten ändern
• Wenn mein Bild gestohlen / gehackt wurde, befinden sich die sensiblen Daten im Bild.

Es ist möglich, das verwendete Token mit Docker Inspect zu finden, aber es kann nicht mehr verwendet werden.
Ich habe mich entschieden, den Hashicorps-Tresor nur zur Bauzeit zu versiegeln und zu entsiegeln, um den Zugang zum Geheimnisspeicher so weit wie möglich einzuschränken. Ich habe auch keine Option zum Speichern von Geheimnissen beim Abrufen von Daten zur Laufzeit gesehen.

Also, wie schlecht habe ich es gemacht (es ist in Ordnung zu sagen, wenn ich es richtig vermasselt habe ;) ) Hat jemand Tipps und Tricks für mich, um die Dinge sicherer zu machen?

@weemen AFAIK, Geheimnisse in Ihrem Bild zu speichern, ist auch keine gute Idee. Ihr Image sollte keine eingebrannten Anmeldeinformationen haben (einschließlich Vault-Token). Verwenden Sie stattdessen das App-ID-Authentifizierungs-Back-End von Vault für Ihre Container, um Geheimnisse über die Ladezeit zu erhalten. Speichern Sie sie irgendwie im Speicher des Containers, abhängig vom verwendeten App-Stack.

Außerdem arbeitet Vault an einem AWS-Authentifizierungs-Backend, das in Zukunft nützlich sein wird, wenn Sie AWS als Cloud-Anbieter verwenden.

@jaredm4 Können Sie diese Aussage bitte klarstellen?:

„Verwenden Sie stattdessen das App-ID-Authentifizierungs-Backend von Vault für Ihre Container, um Geheimnisse über die Ladezeit zu erhalten. Speichern Sie sie irgendwie im Speicher des Containers, abhängig vom verwendeten App-Stack.“

Mir ist noch nicht klar, wann / wo die Geheimnisse aus Vault (oder Keywhiz usw.) abgerufen werden sollen. Wird dies vor dem Ausführen des Dockers durchgeführt und an den Befehl run übergeben? Geschieht dies irgendwann während der Container-Initialisierung (wenn ja, Beispiele)? Soll meine Anwendung diese bei Bedarf abrufen? Meine Rails-App benötigt beispielsweise Google API-Schlüssel. Schreibe ich etwas in Rails, um den Tresor aufzurufen, wenn die Schlüssel benötigt werden?

Ich denke, ich bin mir der Notwendigkeit bewusst, so etwas wie Vault zu verwenden, und weiß, wie man es konfiguriert.

Jede Anleitung hier wäre dankbar. Vielen Dank

Sicher @mcmatthew , obwohl ich

Ich habe versucht, es so zu codieren, dass die einzigen Informationen, die Sie an den Container übergeben, etwas sind, das für die Authentifizierung Ihres Codes bei Vault erforderlich ist. Wenn Sie ein App-ID-Back-End verwenden, sind das app-id selbst und die Adresse Ihres Vault.

Beim Booten des Containers wird Ihre Rails-App feststellen, dass sie noch keine Geheimnisse enthält und diese aus Vault abrufen muss. Es hat das bereitgestellte app-id und muss es irgendwie generieren user-id . Diese Benutzer-ID-Generierung muss von Ihnen bestimmt werden, aber ihre Dokumentation weist darauf hin, dass "es im Allgemeinen ein für eine Maschine eindeutiger Wert ist, z. B. eine MAC-Adresse oder Instanz-ID, oder ein aus diesen eindeutigen Werten gehashter Wert".

Sobald Ihre Rails-App die App-ID und die Benutzer-ID bereit hat, kann sie die Vault-API für /login verwenden. Von dort aus können Sie dann API-Aufrufe durchführen, um Ihre benötigten Geheimnisse abzurufen.

Um nun zu verdeutlichen, was ich mit dem Speichern im Speicher gemeint habe -- dies hängt von der Art der verwendeten App ab, aber mit Rails sollte es eine Möglichkeit geben, Ihre Geheimnisse in einem Userland-Variablen-Cache zu speichern, der es Rails ermöglicht, auf die Geheimnisse aus dem Speicher jede Anfrage, anstatt sie immer wieder aus Vault zu bekommen (was, wie Sie sich vorstellen können, langsam wäre). Sehen Sie sich diese Anleitung zum Caching in Rails an. Nämlich Abschnitt 2.0, aber sicher, dass er memory_cache und nicht disk verwendet.

Stellen Sie abschließend sicher, dass Sie es in Rails und nicht mit einem speziellen Docker-Entrypoint-Skript oder ähnlichem codieren. Rails sollte nach Geheimnissen im Speicher suchen und sie holen, wenn sie nicht vorhanden sind.

Ich hoffe das hilft. Ich weiß, ein bisschen auf hohem Niveau, aber so haben wir es geplant.

Was nicht klar ist, ist, was geheim gehalten werden soll, App-ID, Benutzer-ID oder beides.

Ok, die Antwort ist beides https://www.vaultproject.io/docs/auth/app-id.html
Aber es ist immer noch nicht klar, warum es sicherer ist als nur ein einfacher Firewall-Zugang.
Vielleicht sollte jedes Host-Geheimnis mit dem Anwendungs-(Richtlinien-)Geheimnis verknüpft werden?
Dh, wenn Sie Zugriff auf das Geheimnis des Hosts haben, können Sie auf bestimmte Anwendungen zugreifen, wenn Sie deren geheime Namen kennen?

Jetzt müssen wir irgendwo 2 Token speichern?

@Vanuan Sie sollten beide so geheim wie möglich gehalten werden, ja.

Der Hauptzweck der App-ID besteht darin, den Zugriff auf bestimmte Geheimnisse in Vault über Richtlinien einzuschränken. Jeder mit Zugriff auf die App-ID erhält Zugriff auf die Geheimnisse der Richtlinien dieser App-ID. Die App-ID sollte von Ihrer Bereitstellungsstrategie bereitgestellt werden. Wenn Sie beispielsweise Chef verwenden, können Sie dies in den Parametertaschen (oder CustomJSON für OpsWorks) festlegen. Es erlaubt jedoch niemandem, auf Vault zuzugreifen. Jemand, der Zugriff auf Chef erhält, kann dann also nicht auf Vault zugreifen.

Die Benutzer-ID wird NICHT von Chef bereitgestellt und sollte an bestimmte Maschinen gebunden sein. Wenn Ihre App redundant über Instanzen hinweg skaliert wird, sollte jede Instanz eine eigene Benutzer-ID haben. Es spielt keine Rolle, woher diese Benutzer-ID stammt (obwohl sie Vorschläge machen), aber sie sollte nicht von derselben Stelle stammen, an der die App-ID bereitgestellt wurde (dh Chef). Wie sie sagten, kann es auf andere Weise gescriptet werden. Jede Software, die Sie zum Skalieren von Instanzen verwenden, könnte Benutzer-IDs an die Instanzen/Docker-Container liefern und die Benutzer-ID für die App-ID autorisieren. Dies kann auch manuell erfolgen, wenn Sie Ihre Instanzen nicht dynamisch skalieren. Jedes Mal, wenn ein Mensch eine neue Instanz hinzufügt, erstellt er eine neue Benutzer-ID, autorisiert sie für die App-ID und stellt sie der Instanz mit den für sie am besten geeigneten Mitteln zur Verfügung.

Ist das besser als Firewalling-Instanzen? Denke das kommt darauf an. Firewalling schränkt den Zugriff auf Geheimnisse in Vault nicht ein (afaik), und wenn jemand Zugriff auf Ihre Instanzen erhält, könnte er leicht in Ihren Vault gelangen.

Auf diese Weise ist es schwer für sie, alle Teile des Puzzles zu bekommen. Um noch einen Schritt weiter zu gehen, lässt app-id auch CIDR-Blöcke zu, die Sie verwenden sollten. Wenn jemand die App-ID und die Benutzer-ID irgendwie erhalten hat, konnte er immer noch nicht auf Vault zugreifen, ohne sich in diesem Netzwerk zu befinden.

(Wieder, dies ist meine Interpretation, nachdem ich die Dokumentation so gut wie möglich durchgearbeitet habe)

@Vanuan @mcmatthew tolle Fragen! @jaredm4 vielen Dank für diese Klarstellung, das wird mir sicherlich helfen. Dies ist sehr nützlich für alle, die eine praktischere Umsetzung suchen! Wenn ich in den kommenden zwei Wochen Zeit habe, dann werde ich es noch einmal versuchen!

@thaJeztah :

Zugänglich für jeden Vorgang im Behälter, dadurch leicht "ausgesickert"

Können Sie diese Behauptung unterstützen? Nicht-privilegierte Prozesse können nicht auf die Umgebungsvariablen von Nicht-Elternprozessen zugreifen. Siehe https://help.ubuntu.com/community/EnvironmentVariables#Process_locality.

Für den Container festgelegte Umgebungsvariablen (über --env oder --env-file ) _sind_ für jeden Prozess im Container zugänglich.

Natürlich, da sie Kinder des Einstiegspunktprozesses sind. Es ist die Aufgabe dieses Prozesses oder Sie, falls es sich zB um eine Shell handelt, die geheimen Umgebungsvariablen so schnell wie möglich aufzuheben.

Relevanter ist, ob Prozesse mit einer anderen Benutzer-ID als 0 auf diese Umgebungsvariablen innerhalb und/oder außerhalb des Containers zugreifen können. Dies sollte auch nicht der Fall sein, wenn die Software, die Sie im Container verwenden, die Berechtigungen ordnungsgemäß aufgibt.

Ich weiß, dass es nicht zum Thema gehört, aber hat jemand bemerkt, dass dieses Problem jetzt fast ein ganzes Jahr lang aktiv ist? Morgen ist Jubiläum. 👏

Wäre es für einen Containerprozess möglich, env-Variablen im Prozessspeicher zu lesen und sie dann (in der Umgebung) aufzuheben? Behebt dies die meisten Sicherheitsprobleme zur Laufzeit?

@davibe Das Problem dabei ist, dass diese

Ich habe es versucht, aber es sieht so aus, als ob env vars nach dem Relaunch noch vorhanden sind.

dade<strong i="6">@choo</strong>:~/work/grocerest(master)$ cat test.js
console.log("FOO value: " + process.env.FOO);
delete(process.env.FOO);
console.log("FOO value after delete: " + process.env.FOO);

dade<strong i="7">@choo</strong>:~/work/grocerest(master)$ docker run --name test -it -e FOO=BAR -v $(pwd):/data/ node node /data/test.js
FOO value: BAR
FOO value after delete: undefined

dade<strong i="8">@choo</strong>:~/work/grocerest(master)$ docker restart test
test

dade<strong i="9">@choo</strong>:~/work/grocerest(master)$ docker logs test
FOO value: BAR
FOO value after delete: undefined
FOO value: BAR
FOO value after delete: undefined

vielleicht führt docker-run mein Ding als Kind von bash aus? Ich denke, das sollte nicht sein..

@davibe :

unset 'SECRET_ENV_VAR'

Ich denke, das Hauptproblem/Merkmal bei all dem ist, dass Sie sich bei Docker als root anmelden, sodass alles, was Sie in einen Container legen, überprüft werden kann, sei es ein Token, ein Volume, eine Variable oder ein Verschlüsselungsschlüssel. .. irgendetwas.

Eine Idee wäre also, sudo und su aus Ihrem Container zu entfernen und einen USER Befehl vor jedem ENTRYPOINT oder CMD hinzuzufügen. Jeder, der Ihren Container betreibt, sollte jetzt keine Chance haben, als root zu laufen (wenn ich mich nicht irre) und Sie könnten jetzt tatsächlich etwas vor ihm verbergen.

Eine andere Idee (am besten IMHO) wäre, dem Docker-Socket und den Containern den Begriff der Benutzer und Gruppen hinzuzufügen, so dass Sie erkennen können, dass GROUP-A Zugriff auf Container mit TAG-B hat und USER-C zu GROUP- gehört. A, damit es Zugriff auf diese Container hat. Es könnte sich sogar um eine Berechtigung pro Vorgang handeln (GRUPPE-A hat Zugriff auf Start/Stop für TAG-B, GRUPPE-B hat Zugriff auf exec, GRUPPE-C hat Zugriff auf rm/inspect und so weiter).

Nachdem ich dies ein paar Stunden lang recherchiert habe, kann ich nicht glauben, dass es keine offiziell empfohlene Lösung oder Problemumgehung für Build-Time-Geheimnisse zu geben scheint, und so etwas wie https://github.com/dockito/vault scheint die einzige praktikable Option dafür zu sein Build-Time-Geheimnisse (abgesehen davon, dass das gesamte resultierende Bild zerquetscht oder zuerst manuell erstellt wird). Leider ist https://github.com/dockito/vault ziemlich spezifisch für ssh-Schlüssel, also versuche ich, es auch für das Hosten von git https-Credential Store-Dateien anzupassen ...

Nach einer gefühlten Ewigkeit (ursprünglich hörte ich, dass die Veröffentlichung im vierten Quartal 2015 geplant war) scheint AWS ECS endlich sein Versprechen eingelöst zu haben, IAM-Rollen in Docker-Apps zu integrieren . Hier ist auch der Blogbeitrag .

Es scheint, dass dies in Kombination mit einigen KMS-Vorteilen eine praktikable kurzfristige Lösung ist. Theoretisch müssen Sie nur die Geheimnisse an bestimmte Principals/IAM-Rollen binden, um zu verhindern, dass Nicht-Authentifizierungsrollen nach etwas fragen, was sie nicht sollten, und KMS sicheren Speicher überlassen.

Habe es noch nicht probiert, steht aber auf meiner Shortlist...

Kubernetes scheint auch einige Geheimnisse zu haben, die mich stark an verschlüsselte Datenbags von Chef erinnern.

Ich verstehe, dass dies nicht der plattformunabhängige OSS-Weg ist, der der springende Punkt dieses Threads ist.
wollte aber diese beiden Optionen für Leute da draußen werfen, die in diesen Infrastrukturräumen spielen, die _JETZT_ etwas brauchen.

Ich bin gerade auf etwas gestoßen, das in dieser Hinsicht helfen könnte: https://github.com/docker/docker/pull/13587

Das sieht so aus, als ob es ab Docker v1.10.0 verfügbar ist, aber mir war es bisher nicht aufgefallen. Ich denke, die Lösung, zu der ich an dieser Stelle tendiere , besteht darin,

Auf jeden Fall war das fehlende Stück für mich der Ort, an dem die Geheimnisse sicher aufbewahrt werden konnten, wenn sie wiedergefunden wurden. Die Option tmpfs scheint mir gut zu sein. Es fehlt nur noch, dass ECS diesen Parameter anscheinend noch nicht unterstützt, weshalb ich dies heute eingereicht habe: https://github.com/aws/amazon-ecs-agent/issues/469

Alles in allem scheint das IMHO eine ziemlich umfassende Lösung zu sein.

@CameronGo , danke für den

@NikolausDemmel sorry ja, du hast

Jenkins übernimmt dies für uns und speichert die Zugangsdaten für den Git-Zugriff.

Wie funktioniert das mit Docker? Oder sind Sie nicht im Container selbst git clone ?

Nachdem ich diese Ausgabe vollständig durchgelesen habe, glaube ich, dass es immens von einer Aufteilung in separate Ausgaben für "Build-Time"- und "Run-Time"-Geheimnisse profitieren würde, die sehr unterschiedliche Anforderungen haben

Wenn Sie wie ich sind und hierher kommen, um zu entscheiden, was Sie jetzt tun sollen, dann beschreibe ich FWIW die Lösung, für die ich mich entschieden habe, bis etwas Besseres auftaucht.

Für Laufzeitgeheimnisse habe ich mich für http://kubernetes.io/docs/user-guide/secrets/ entschieden. Dies funktioniert nur, wenn Sie Kubernetes verwenden. Ansonsten sieht Tresor ok aus. Alles, was entweder im generierten Bild oder in der temporären Ebene geheim ist, ist eine schlechte Idee.

In Bezug auf Build-Time-Geheimnisse - ich kann mir keinen anderen Anwendungsfall für Build-Time-Geheimnisse vorstellen, als privaten Code zu verteilen. An dieser Stelle sehe ich keine bessere Lösung, als mich darauf zu verlassen, dass auf der Host-Seite etwas "Geheimes" ausgeführt wird und das generierte Paket/jar/wheel/repo/etc. zum Bild. Das Speichern eines LOC, das das Paket auf der Host-Seite generiert, ist es nicht wert, das Risiko der Offenlegung von SSH-Schlüsseln oder der Komplexität der Ausführung des Proxy-Servers zu riskieren, wie in einigen Kommentaren vorgeschlagen.

Vielleicht könnte das Hinzufügen eines "-v" -Flags zum Docker-Build, ähnlich dem Docker-Run-Flag, gut funktionieren? Es würde vorübergehend ein Verzeichnis zwischen Host und Image teilen, aber auch sicherstellen, dass es im Cache oder im generierten Image leer erscheint.

Ich arbeite derzeit an einer Lösung mit Vault :

1. Auf dem Builder-Computer ist Vault installiert und ein Token ist lokal gespeichert
2. Wenn der Build startet, fordert der Builder-Computer ein neues temporäres Token an, das nur für Minuten gültig ist (basierend auf dem Build wäre 1 Stunde sogar akzeptabel).
3. Injiziert das Token als build arg
4. Das Docker-Image hat auch Vault installiert (oder installiert und entfernt es während des Builds) und mit diesem Token kann es die wahren Geheimnisse abrufen

Es ist wichtig, dass die Geheimnisse mit demselben Befehl entfernt werden, damit beim Zwischenspeichern der angegebenen Schicht durch Docker keine Reste übrig bleiben. (Dies gilt natürlich nur für Bauzeitgeheimnisse)

Ich habe das noch nicht gebaut, arbeite aber daran.

In gewisser Weise mit dem Kommentar von vorstellen , als privaten Code zu verteilen."

Vielleicht kein spezielles Build-Time-Geheimnis, aber ich benötige für den Anwendungsfall ein Kennwort (sichern) während der Build-Zeit in einer Dockerfile, damit ein bereits erstelltes Artefakt über einen RUN curl-Befehl heruntergeladen werden kann. Der Build-Time-Download erfordert Benutzeranmeldeinformationen, um sich zu authentifizieren, um das Artefakt zu erhalten – also übergeben wir das Passwort gerade als Umgebungsvariable im Dockerfile (wir sind immer noch in Dev). Builds finden automatisch hinter den Kulissen statt, da wir OpenShift verwenden, und Umgebungsvariablen im Dockerfile werden während des Builds in Protokollen ausgegeben, wie bei jedem Docker-Build-Befehl. Dadurch wird das Passwort für jeden sichtbar, der Zugriff auf die Protokolle hat, einschließlich unserer Entwickler. Ich habe verzweifelt versucht, einen Weg zu finden, das Passwort zu senden, damit es während des Docker-Builds verwendet werden kann, aber dann nicht die Passwortausgabe in Protokollen oder am Ende in irgendwelchen Ebenen.

Ich unterstütze auch, was @wpalmer über die

Ich denke, es könnte sich lohnen, einige Tests für jeden (Laufzeit-)Geheimmechanismus zu definieren, der von jemandem erfunden wird. Denn es gibt viele Leute in diesem Thread, die sich für sehr schwache Sicherheit einsetzen.

Als Einstieg schlage ich vor:

• Das Geheimnis wird in Docker Inspect nicht angezeigt
• Nachdem Prozess 1 gestartet wurde, ist das Geheimnis in keiner Datei verfügbar, auf die über den Container zugegriffen werden kann (einschließlich Volume-Mounting-Dateien).
• Das Geheimnis ist in /proc/1/cmdline nicht verfügbar
• Das Geheimnis wird verschlüsselt an den Container übertragen

Jede oben vorgeschlagene Lösung, die eine dieser Bedingungen verletzt, ist problematisch.

Wenn wir uns auf eine Definition des Verhaltens eines Geheimnisses einigen können, dann werden zumindest endlose Lösungen aussortiert, die nicht für den Zweck geeignet sind.

@gtmtech tolle Vorschläge :)

Nachdem Prozess 1 gestartet wurde, ist das Geheimnis in keiner Datei verfügbar, auf die über den Container zugegriffen werden kann (einschließlich Volume-Mounting-Dateien).

Ich bin mir nicht sicher, ob ich damit einverstanden bin. Obwohl ich zustimme, dass es nur über den Container (idealerweise im Arbeitsspeicher) zugänglich sein sollte, gibt es mehrere Fälle, in denen eine Anwendung Zeit zum "Starten" benötigt und die Dateien nicht darunter entfernt werden. Ich denke, etwas im Speicher für die Dauer des Containerlaufs (beim Stoppen entfernt) ist ein etwas besserer Ansatz.

Ich würde der Liste der Laufzeitanforderungen hinzufügen:

• Container-Authentifizierung/Autorisierung beim Bootstrapping des ersten Geheimnisses.

Vault bietet beispielsweise eine Autorisierung mit dem AppRole-Backend , ist jedoch hinsichtlich der Identifizierung von Containern offen.

Nick Sullivan präsentierte vor einigen Wochen das PAL-Projekt von Clouflare und versprach, es bald als Open Source zu öffnen, was eine mögliche Antwort auf die Authentifizierungsfrage mithilfe eines Docker-Notars liefern sollte.

Aus Anwendungssicht gibt es drei Möglichkeiten, damit umzugehen:

1. Rufen Sie ein Geheimnis aus einer Umgebungsvariablen ab.
2. Holen Sie sich ein Geheimnis aus einer Datei.
3. Holen Sie sich ein Geheimnis von einem anderen System.

1 und 2 oben sind im Allgemeinen die gebräuchlichsten, da die meisten Anwendungen diesen Mechanismus unterstützen. #3 ist wahrscheinlich idealer, da sie die wenigsten "Krümel" hinterlässt, aber die Anwendung muss speziell dafür entwickelt werden und muss oft noch über einen Zugangsausweis verfügen, um das Geheimnis zu lüften.

Bei Docker dreht sich alles um Vielseitigkeit und die Unterstützung einer Vielzahl von Anwendungsfällen. Auf dieser Grundlage sind 1. und 2. aus Sicht der Anwendung am attraktivsten, obwohl beide "Krümel" im System hinterlassen.

Ein gängiger Ansatz, den ich sicherlich verwende, besteht darin, Geheimnisse über ein Einstiegsskript einzufügen (z. B. ein Tool wie credstash oder einfaches KMS in AWS verwenden und mit IAM-Rollen kombinieren). In dieser Hinsicht machen Sie tatsächlich #3 oben im Einstiegspunktskript und entweder #1 (eine Umgebungsvariable setzen) oder #2 (in eine Datei schreiben). Dieser Ansatz ist dynamisch und macht für Nr. 1 (Umgebungsvariablen) keine Anmeldeinformationen in Docker-Protokollen oder Docker-Inspect verfügbar.

Das Schöne am Entrypoint-Ansatz ist, dass Sie die Anliegen des Secret-Managements von der Anwendung trennen.

Dies ist ein Bereich, in dem Docker Funktionen hinzufügen könnte, um zu vermeiden, dass Sie eigene Einstiegspunktskripts verwenden müssen. Docker liebt Plugins und könnte einen Hook in den Containerlebenszyklus bereitstellen, wo es "Geheimnisse"-Provider-Plugins unterstützen könnte, die im Wesentlichen die Funktion eines manuellen Einstiegspunktskripts ausführen und Geheimnisse in den Container einschleusen (über eine interne Umgebungsvariable oder Datei). Sie könnten also einen Hashicorp Vault-Geheimnisanbieter, einen AWS KMS-Geheimnisanbieter usw. haben. Docker könnte vielleicht einen eigenen Anbieter haben, der auf der RSA-Verschlüsselung (über digitale Zertifikate) basiert. Dieses ganze Konzept ähnelt dem Kubernetes-Konzept der Geheimnisse, das Geheimnisse im Container-Dateisystem präsentiert.

Natürlich gibt es die Komplexität der Autorisierung des Zugriffs auf den Geheimdienstanbieter, was ein Problem ist, mit dem Sie sich heute trotzdem konfrontiert sehen. Bei Hashicorp können Sie ein einmaliges/zeitlich begrenztes Token für die Authentifizierung ausgeben und weitergeben, bei AWS sind es IAM-Rollen, bei dem erwähnten Docker RSA-Verschlüsselungsansatz könnten nur Geheimnisse übergeben werden, die mit dem öffentlichen Zertifikat der Docker Engine verschlüsselt wurden.

Dieser Thread ist großartig. Ich hoffe, wir sehen mehr Threads wie diesen, in denen Menschen aus der Community und allen Berufszweigen ihre Erfahrungen, Gedanken und Lösungen teilen können.

Das Thema "Geheime Null" ist ein heikles Thema. Build-Time oder Run-Time? Beide haben ihre Vor- und Nachteile sowie offensichtliche Sicherheitsmaßnahmen und Mängel (und Hacks und Workarounds!).

Allerdings habe ich viel darüber nachgedacht, wie die Verwaltung eines Passes/Schlüssels auf die Anwendung und/oder den Dienst hinausläuft.

In den kommenden Monaten werden wir daran arbeiten, einen gemeinsamen, globalen Konfigurationsunterstützungsdienst über Schlüssel/Wert-Paare aufzubauen, der von Consul verteilt und als Umgebungsvariable verfügbar gemacht wird (oder eingefügt wird, wenn die Verwendung von Umgebungsvariablen nicht unterstützt wird). Dies unterstützt nur Ihre unsicheren Werte. Aus Sicherheitsgründen werden wir zu Vault wechseln und es wie einen unterstützenden Dienst behandeln - ähnlich wie eine Datenbank oder jede andere Abhängigkeit.

Code, Konfiguration und Geheimnisse werden über Backing-Service(s) bereitgestellt. In diesem Fall verwenden wir Stash, Consul und Vault. Solange die Abhängigkeit besteht, besteht auch die Möglichkeit, Konfigurationen und Geheimnisse nach Bedarf abzurufen.

Ich habe dies nirgendwo als solide Lösung gesehen, daher poste ich hier darüber. Aber um es auf den Zweck dieses Threads zurückzubringen, es ist ein Ansatz, mit dem wir experimentieren werden, um das Docker/Geheimnis-Problem zu umgehen. Wir werden Anwendungen entwickeln, die dies nativ unterstützen, anstatt uns auf die sie umgebenden Frameworks und Plattformen zu verlassen, auf denen sie ausgeführt werden.

In Bezug auf Build-Time-Geheimnisse hat sich Rockers MOUNT Direktive als nützlich erwiesen, um vorübergehende Verzeichnisse und Dateien zu erstellen, die _nur_ zur Build-Zeit existieren. Einige ihrer Vorlagenfunktionen können in dieser Situation ebenfalls hilfreich sein, aber ich habe sie noch nicht gründlich verwendet.

Ich würde diese Funktionalität gerne als Builder-Plugin im Docker-Kern implementiert sehen (sowie einige der anderen nützlichen Funktionen von Rockerfiles)!

Ich sehe, dass alle 4 Vorschläge, die derzeit in OP sind, sich auf geheime Speicherung beziehen 🙁

Ich würde sagen, Docker sollten die Weitergabe eines Geheimnisses/Passworts an eine _Docker-Instanz_ erleichtern, aber das Speichern/Verwalten dieser Geheimnisse liegt (und sollte) außerhalb des Bereichs von Docker.

Beim _Übergeben eines Geheimnisses_ würde ich sagen, dass ein Laufparameter fast perfekt ist, außer dass dies normalerweise protokolliert wird. Also würde ich dies auf eine Nicht-Klartext-Parameterfunktion eingrenzen. Ein Ansatz wäre, eine Verschlüsselung mit Schlüsseln zu verwenden, die pro Docker-Instanz generiert werden.

Was die _Verwaltung von Geheimnissen angeht_, würde ich alles sagen, was der Benutzer will, von einem Homebrew-Bash-Skript bis hin zur Integration durch Software wie Kubernetes .

Was ist falsch daran, einfach MOUNT wie Rocker Mounts zu implementieren, wie @agilgur5 zuvor bemerkt hat? Ich kann nicht glauben, dass diese Debatte so lange gedauert hat, dass ein Team den Befehl docker build effektiv abspalten musste, um diesen wirklich einfachen Anwendungsfall zu erfüllen. Brauchen wir einen weiteren HTTP-Server in der Mischung? KUSS.

Ich habe so viele Stunden mit diesem Thema verbracht ...

Im Moment ist der beste Weg, um Geheimnisse während der Build-Phase zu verwalten, das Erstellen in zwei Schritten, also zwei Docker-Dateien. Hier ein gutes Beispiel .

[Habitus] (http://www.habitus.io/) scheint eine weitere Option zu sein, aber in meinem Fall möchte ich keine weiteren Tools hinzufügen, hauptsächlich weil ich den Build-Prozess auf dem CI-Server UND auf dem Computer des Benutzers behalten möchte einfach / gleich.

Und wie sieht es mit Docker-in-Docker (dind) aus?

Hier ein Beispiel für zwei Schritte, die mit Dind erstellt wurden, wie ich gerade oben gesprochen habe: https://github.com/BenoitNorrin/docker-build-with-secrets

Kommentieren Sie gerne...

Interessant. Erinnert mich irgendwie daran, wie OpenShift Builds macht.

Für mich sieht es so aus, als ob Sie das Passwort an der Befehlszeile übergeben. Gibt es einen Weg, das zu umgehen?

Beachten Sie, dass es hier eine in Arbeit befindliche PR für Build-Time-Geheimnisse gibt; https://github.com/docker/docker/pull/28079 (Laufzeitgeheimnisse für Dienste befinden sich in Docker 1.13, siehe https://github.com/docker/docker/pull/27794)

@thaJeztah :
Was die #28079 angeht, bin ich ein bisschen pessimistisch, als ich in den letzten zwei Jahren so viele PR zu diesem Thema gesehen habe, die gescheitert sind ...
Ich möchte keinen Schwarm als Abhängigkeit haben. Ein Teil meiner Kunden verwendet einen anderen Cluster Orchestrator.

@cassiussa :
ich verstehe nicht was du meinst?
1/ Passwörter wurden an den "Container Builder" übergeben, der nicht das endgültige Image ist. Dieser Builder führt einen Docker-Build aus und erzeugt ein Image basierend auf der Dockerfile.realease. Im Verlauf dieses endgültigen Bildes sind keine Geheimnisse gespeichert.
2/ Fühlen Sie sich frei, docker-compose ( Beispiel ) zu verwenden, wenn Sie das Passwort nicht an die Befehlszeile übergeben möchten

@BenoitNorrin Ich denke, es könnte in Zukunft auf Nicht-Schwarm erweitert werden, aber @diogomonica weiß vielleicht mehr darüber

Klingt wie es:

Dies gilt derzeit nur für den Swarm-Modus, da der Backing Store Swarm ist und als solcher nur für Linux gilt. Dies ist die Grundlage für zukünftige geheime Unterstützung in Docker mit möglichen Verbesserungen wie Windows-Unterstützung, verschiedene Backing Stores usw.

Wäre toll wenn es genauso umgesetzt würde wie Rocker, kann sein
einfach, muss nicht "Unternehmen" sein.

Am Di, 29 Nov 2016, 15:53 ​​Michael Warkentin, [email protected]
schrieb:

Klingt wie es:

Dies gilt derzeit nur für den Swarm-Modus, da der Backing Store Swarm und as . ist
das ist nur für Linux. Dies ist die Grundlage für zukünftige geheime Unterstützung in
Docker mit Verbesserungspotential wie Windows-Unterstützung, verschiedene
Backshops usw.

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/docker/docker/issues/13490#issuecomment-263608915 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAZk5vlLwsBHHTTbUS_vvx-qTuwnkp6Oks5rDEpjgaJpZM4Eq021
.

Eine Lösung wäre, einige Teile der Informationen zu verschlüsseln, die aus einer docker-compose Datei übergeben werden.

Führen Sie beispielsweise docker inspect und die verschlüsselten Informationen sollten als _verschlüsselt_ angezeigt/markiert werden. Dann würde docker inspect --encryption-key some_key_file alle verschlüsselten Informationen unverschlüsselt anzeigen.

Auf der anderen Seite sollten Apps in den Containern verschiedene Mechanismen implementieren können, um auf diese verschlüsselten Informationen zuzugreifen und sie für ihre Verwendung zu entschlüsseln.

Ich denke, Verschlüsselung _ist der Schlüssel_ :)

Der Zweck ist für meinen (wirklich, wirklich, wirklich häufigen) Anwendungsfall:
Softwareprojekt von einem Git-Server, der eine Authentifizierung erfordert, sowohl für
das Projekt und seine Abhängigkeiten. Rocker hat es genagelt, indem er die Montage erlaubt hat
eine Datei oder ein Verzeichnis während des Builds (in diesem Fall ein SSH-Agent-Socket)

Am Dienstag, 3. Januar 2017, 04:14 Uhr schrieb Hisa, [email protected] :

Eine Lösung wäre, einige Teile der weitergegebenen Informationen zu verschlüsseln
aus einer docker-compose-Datei.

Führen Sie beispielsweise docker inspect aus und die verschlüsselten Informationen sollten
als verschlüsselt angezeigt/markiert . Dann docker inspect --encryption-key
some_key_file würde alle verschlüsselten Informationen unverschlüsselt anzeigen.

Auf der anderen Seite sollten sich in den Containern Apps implementieren lassen
verschiedene Mechanismen, um auf diese verschlüsselten Informationen zuzugreifen und sie für ihre Verwendung zu entschlüsseln.

Ich denke, Verschlüsselung ist der Schlüssel :)

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/docker/docker/issues/13490#issuecomment-270049742 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAZk5qEphZo5SR9vOWVL5dck50EPadpVks5rOcsUgaJpZM4Eq021
.

Da ich es nicht erwähnt gesehen habe, ist hier ein weiterer guter Artikel zum Umgang mit Geheimnissen in AWS ECS: https://aws.amazon.com/blogs/security/how-to-manage-secrets-for-amazon-ec2-container- servicebasierte-anwendungen-durch-verwenden-amazon-s3-und-docker/

In Docker 1.13 gibt es einen neuen "docker secret"-Befehl. Dieses Problem sollte geschlossen werden können, wenn die Dokumentation für diese Funktion für die hier genannten Anwendungsfälle geeignet ist.

Der Docker-Secret-Befehl scheint derzeit nur für Docker Swarm (dh Docker-Dienste) zu gelten, ist also derzeit für generische Docker-Container nicht geeignet.

Außerdem verwaltet docker secret nur Laufzeit-Geheimnisse, keine Build-Zeit-Geheimnisse.

Beeindruckend. Es ist, als hätte niemand im Produktmanagement-Team jemals daran gedacht
der Anwendungsfall, bei dem alles andere als nicht authentifizierte Open-Source-Software verwendet wird
in einem Docker-Container oder einer anderen Sprache als Golang gebaut, wo alle
Abhängigkeiten werden kopiert und eingefügt, sorry, 'versioniert' in das Git-Repository.

Ich kann einfach nicht verstehen, wie die Leute so unglaublich stumpfsinnig sein sollen. Nur
Eine Erklärung, die ich mir vorstellen kann, ist, dass das Produktmanagement-Team es nicht ist
Praktiker und haben das Produkt noch nie verwendet. das sehe ich oft
Charakteristik manifestiert sich, wenn Organisationen auf Basis eingestellt werden
Jira/Agile Fähigkeiten.

Ich werde Rocker einfach bis 2019 verwenden oder immer dann, wenn jemand Sinn sieht.

Am Sonntag, 22. Januar 2017, 23:47 Uhr schrieb Shane StClair, [email protected] :

Außerdem verwaltet Docker-Geheimnisse nur Laufzeit-Geheimnisse, keine Build-Zeit-Geheimnisse.

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/docker/docker/issues/13490#issuecomment-274370450 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAZk5vJVJe4OeypWd1Cwqmh8Gzyn8P-mks5rU-qqgaJpZM4Eq021
.

Ich nehme den letzten Kommentar zurück, sorry, ich mache Luft. Nur frustriert das
einfache Randfälle erscheinen oft wie eine Gelegenheit, etwas unterzuschieben
wie Konsul oder erschaffe etwas wirklich Überentwickeltes, anstatt nur
Implementieren Sie etwas so Einfaches wie Build-Time-Mount.

Am Mo, 23. Januar 2017, 09:31 Uhr schrieb Bryan Hunt,

Beeindruckend. Es ist, als hätte niemand im Produktmanagement-Team jemals daran gedacht
der Anwendungsfall, bei dem alles andere als nicht authentifizierte Open-Source-Software verwendet wird
in einem Docker-Container oder einer anderen Sprache als Golang gebaut, wo alle
Abhängigkeiten werden kopiert und eingefügt, sorry, 'versioniert' in das Git-Repository.

Ich kann einfach nicht verstehen, wie die Leute so unglaublich stumpfsinnig sein sollen. Nur
Eine Erklärung, die ich mir vorstellen kann, ist, dass das Produktmanagement-Team es nicht ist
Praktiker und haben das Produkt noch nie verwendet. das sehe ich oft
Charakteristik manifestiert sich, wenn Organisationen auf Basis eingestellt werden
Jira/Agile Fähigkeiten.

Ich werde Rocker einfach bis 2019 benutzen oder immer wenn es jemand sinnvoll sieht
dann.

Am So, 22. Januar 2017, 23:47 Uhr Shane StClair, [email protected]
schrieb:

Außerdem verwaltet Docker-Geheimnisse nur Laufzeit-Geheimnisse, keine Build-Zeit-Geheimnisse.

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/docker/docker/issues/13490#issuecomment-274370450 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAZk5vJVJe4OeypWd1Cwqmh8Gzyn8P-mks5rU-qqgaJpZM4Eq021
.

@binarytemple Jeder möchte jetzt alle Funktionen. Wenn etwas nicht fertig ist, dann ist es einfach nicht fertig. Den Umfang eines neuen Features einzuschränken ist definitiv keine schlechte Sache, denn selbst bei einem begrenzten Umfang gibt es immer Raum für Verbesserungen.

Wenn jemand wirklich daran interessiert ist, ein Feature zu integrieren, sollte er mit einem oder mehreren Betreuern darüber sprechen, wie er die Arbeit dafür beitragen kann.

Ich dachte dasselbe wie @mixja , da der Befehl secret nur Schwarmbenutzern hilft, keine allgemeinere Lösung ist (wie sie es beim Anhängen von persistenten Volumes getan haben). Wie Sie Ihre Geheimnisse verwalten (was sie sind und wer Zugriff darauf hat) ist sehr systemabhängig und hängt davon ab, welche kostenpflichtigen und/oder OSS Sie zu Ihrer "Plattform" zusammenbasteln. Da Docker eine Plattform bereitstellt, überrascht es mich nicht, dass ihre erste Implementierung schwarmbasiert ist, genauso wie Hashicorp Vault in Atlas integriert – es macht Sinn.

Wie die Geheimnisse weitergegeben werden, liegt außerhalb des Bereichs von docker run . AWS tut dies mit Rollen und Richtlinien zum Erteilen/Verweigern von Berechtigungen sowie einem SDK. Chef tut dies mit verschlüsselten Databags und Krypto-Bootstrapping zur Authentifizierung. K8S hat eine eigene Version von dem, was gerade in 1.13 veröffentlicht wurde. Ich bin mir sicher, dass Mesos mit der Zeit eine ähnliche Implementierung hinzufügen wird.

Diese Implementierungen scheinen in 2 Lager zu fallen.
1) Übergeben Sie das Geheimnis über das Volume-Mount, das die "Plattform" bereitstellt, oder (chef/docker secret/k8s
2) Anmeldeinformationen übergeben, um mit einem externen Dienst zu kommunizieren, um beim Booten Dinge abzurufen (iam/credstash/etc)

Ich glaube, ich hatte gehofft, etwas mehr in Richtung der zweiten Option zu sehen. Bei der ersten Option gibt es meiner Meinung nach nicht genügend Trennung der Belange (das Ding, das den Start ausführt, hat auch Zugriff auf alle Schlüssel), aber das ist Präferenz, und wie alles andere beim Systembau macht es jeder gerne anders .

Ich bin ermutigt, dass Docker diesen ersten Schritt getan hat und hoffe, dass daraus ein allgemeinerer Mechanismus für docker run entsteht (um Lager #2 zu unterstützen) – was leider bedeutet, dass dieser Thread meiner Meinung nach nicht geeignet ist Die erste Mission wurde erfüllt und sollte noch nicht abgeschlossen werden.

mögen!
wirklich einfaches, aber sehr effektives Design

@bacoboy , @mixja - Single Node Swarm und ein Single Container Service ist gar nicht so schlimm
Docker Swarm init , Docker Service Create Replica=1

Für mich ist es logisch, dass Docker Swarm von nun an der Standard für die Ausführung von Containern/Diensten ist.

Liege ich richtig in der Annahme, dass sich dieser neue schwarmbasierte Vorschlag nur auf Laufzeitgeheimnisse auswirkt? Ich sehe wirklich keine Notwendigkeit für eine spezielle Behandlung von Laufzeitgeheimnissen, da es bereits so viele Möglichkeiten gibt, Geheimnisse in einen laufenden Container zu bringen.

Build- Time-Geheimnisse sind wichtig, und soweit ich weiß, geht dieser Vorschlag nicht darauf ein.

Um Build-Time-Geheimnisse zu injizieren, können wir jetzt docker build --squash , um Folgendes sicher zu tun:

COPY ssh_private_key_rsa /root/.ssh/id_rsa
RUN git pull ...
RUN rm -rf /root/.ssh/id_rsa

Das Flag --squash erzeugt eine einzelne Ebene für das gesamte Dockerfile: Es gibt keine Spur des Geheimnisses.

--squash ist in docker-1.13 als experimentelles Flag verfügbar.

@hmalphettes Dies bedeutet, dass Sie die Vorteile der gemeinsamen unteren Ebenen zwischen den Builds verpassen.

Dies ist definitiv nicht die Absicht von Squash. Ich würde immer noch sehr vorsichtig sein, wenn Sie solche Geheimnisse hinzufügen.

@zoidbergwill niedrigere Ebenen werden weiterhin geteilt.

Ich stimme @cpuguy83 zu 100% zu. Es wäre ziemlich riskant, sich auf ein Build-Time-Flag zu verlassen, um Geheimnisse zu lüften. Es gab eine Vorschlags-PR für die Build-Zeit (https://github.com/docker/docker/pull/30637). Ich werde an einer Neubasis arbeiten, um mehr Feedback zu erhalten.

@wpalmer Wenn Sie über automatisierte Image-Builds verfügen, sollten Ihre Tools wissen, wie Sie Build-Zeit-Geheimnisse erhalten.

Beispielsweise möchten Sie möglicherweise Ihre Build-Time-Geheimnisse in einem verschlüsselten Ansible-Tresor aufbewahren, der in ein Image eingebettet ist, und Containern, die von diesem Image ausgeführt werden, Zugriff auf das Laufzeitgeheimnis gewähren, das Ihr Tresor-Passwort enthält.

WDYT?

Warum verwechseln wir ständig Build-Zeit-Geheimnisse mit Laufzeit-Geheimnissen? Es gibt bereits viele gute Möglichkeiten für Docker (oder verwandte Tools wie Kubernetes), um die Laufzeitgeheimnisse bereitzustellen. Das einzige, was wirklich fehlt, sind die Geheimnisse der Bauzeit. Diese Geheimnisse werden während der Laufzeit nicht verwendet, sie werden während der Installationszeit verwendet, dies können beispielsweise interne Repositorys sein. Die einzige funktionierende Möglichkeit, die ich in diesem und verwandten Themen gesehen (aber auch davon abgeraten) habe, besteht darin, einen HTTP-Server während der Buildzeit für den Container bereitzustellen. Der HTTP-Server-Ansatz macht die Sache ziemlich kompliziert, um an diese Geheimnisse zu gelangen.

+1 Build-Zeit-Geheimnis != Laufzeit-Geheimnis

Wie Paulus betont. Es ist nicht wünschenswert, ein internes Repository zu backen
Anmeldeinformationen in das Bild.

Warum ist das so schwer zu verstehen?

Am Do, 16 Feb 2017, 14:42 Paul van der Linden, [email protected]
schrieb:

Warum verwechseln wir ständig Build-Zeit-Geheimnisse mit Laufzeit-Geheimnissen? Dort
gibt es bereits viele gute Möglichkeiten für Docker (oder verwandte Tools wie Kubernetes)
die Laufzeitgeheimnisse bereitstellen. Das einzige was wirklich fehlt ist die Bauzeit
Geheimnisse. Diese Geheimnisse werden nicht während der Laufzeit verwendet, sondern während
Installationszeit, dies können beispielsweise interne Repositorys sein. Das einzige
Arbeitsweise, die ich in diesem und verwandten Themen gesehen habe (aber auch empfohlen)
dagegen) stellt dem Container während der Buildzeit einen http-Server zur Verfügung.
Der HTTP-Server-Ansatz macht es ziemlich kompliziert, ihn tatsächlich zu erreichen
diese Geheimnisse.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/docker/docker/issues/13490#issuecomment-280348116 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAZk5h0Z2OGwApVnLNEFWKRdOfGxLOmRks5rdGBagaJpZM4Eq021
.

@pvanderlinden Sie können das auch mit zwei Schritten bauen.
Hier ein Beispiel: https://github.com/BenoitNorrin/docker-build-with-secrets

@timka Wie bereits erwähnt, ist es nicht wünschenswert, Anmeldeinformationen in das Image zu integrieren, da dies ein Sicherheitsrisiko darstellt. Hier ist ein Vorschlag für Build-Zeit-Geheimnisse: https://github.com/docker/docker/pull/30637

@BenoitNorrin Nicht sicher, wie das in meinem (und anderen) Anwendungsfall wäre.
Die zu installierenden Pakete sind bereits erstellt, wenn ich den Docker-Build-Prozess starte. Aber der Docker-Build muss diese Pakete installieren, er benötigt Zugriff auf ein internes Anaconda-Repository und/oder einen Pypi-Server (Python). Die Standorte und Passwörter sind natürlich privat.
Sieht so aus, als wäre #30637 ein weiterer Versuch, hoffentlich landet das im Docker!

@timka die erste Hälfte Ihrer Nachricht scheint Build-Time-Geheimnisse zu erwähnen, aber die zweite Hälfte spricht explizit von Laufzeit-Geheimnissen. Laufzeitgeheimnisse sind einfach. Meine aktuelle "Lösung" für Build-Time-Geheimnisse besteht darin, einen Container, der private Daten unter Verwendung eines Laufzeit-Geheimnisses abruft, als völlig separaten Schritt vorab auszuführen. Ein weiterer Schritt führt dies dann in den Baum ein, bevor ein regulärer docker build Befehl ausgeführt wird.

Die Alternative, wenn Build-Time-Secrets eine Standardfunktion wären, bestünde darin, diese Schritte innerhalb der Dockerfile auszuführen.

Meine Werkzeuge wissen zwar, wie diese Schritte automatisch ausgeführt werden, aber ich musste dies selbst backen, was für einen so häufigen Wunsch etwas absurd ist.

Zu Ihrer Information, ich habe https://github.com/abourget/secrets-bridge geschrieben , um das Problem mit den Geheimnissen der Build-Zeit zu lösen.

Es erstellt eine Wegwerfkonfiguration, die Sie als Argumente übergeben können, während des Build-Prozesses stellt es eine Verbindung zum Host her und ruft die Geheimnisse ab, verwendet sie und dann können Sie die Host-Bridge beenden. Selbst wenn die Build-Args irgendwo gespeichert werden, werden sie in dem Moment, in dem der Server beendet wird, nutzlos.

Der Server unterstützt die SSH-Agentenweiterleitung, die über eine TLS-Websocket-Kommunikation getunnelt wird. Es funktioniert auch unter Windows!

Alexandre, was Sie gemacht haben, ist äußerst kreativ und kompetent. Es gerade
macht mich traurig, dass es notwendig ist, all diese Schritte zu überspringen, nur um
das gleiche erreichen, was möglich wäre, wenn 'docker build' das 'mount' unterstützt
Befehl statt blindes Beharren darauf, dass alles in die
Container.

Ich bin mein Fall, ich werde 'Docker Build' aufgeben und stattdessen Rocker verwenden oder
etwas, wenn meine eigene Kreation.

Am Do, 13.07.2017, 16:23 Uhr Alexandre Bourget, [email protected]
schrieb:

Zu Ihrer Information, ich habe https://github.com/abourget/secrets-bridge geschrieben , um die
Build-Time-Geheimnisse-Problem.

Es erstellt eine Wegwerfkonfiguration, die Sie als Argumente übergeben können.
Während des Build-Prozesses wird eine Verbindung zum Host hergestellt und die
Geheimnisse, verwenden Sie sie, und dann können Sie die Host-Bridge töten. Auch wenn die
build-args werden irgendwo gespeichert, sie werden nutzlos, sobald der Server
wurde getötet.

Der Server unterstützt SSH Agent Forwarding, getunnelt durch ein TLS
Websocket-Kommunikation. Es funktioniert auch unter Windows!

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/moby/moby/issues/13490#issuecomment-315111388 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AAZk5hZqTAgPBjS9cFP_IsYNa9wv-yoAks5sNjaBgaJpZM4Eq021
.

Hier ist der neueste Geheimvorschlag: https://github.com/moby/moby/issues/33343

Ich denke, die neue "mehrstufige Build"-Funktionalität, die in der letzten Docker CE-Version enthalten ist, löst einen großen Teil unserer Probleme.

https://docs.docker.com/engine/userguide/eng-image/multistage-build/

Container, die erzeugt werden, um Befehle von Dockerfile auszuführen, werden mit gekochten /dev und keine dort vorgenommenen Änderungen sollten in einer Ebene aufgezeichnet werden. Kann Docker Benutzergeheimnisse über diesen Mount-Punkt bereitstellen? Auf ähnliche Weise bietet es /dev/init ?

Dies ist immer noch ziemlich wichtig, da mehrstufige Builds mit Argumenten nicht im Image durchsickern, sondern Ihre Geheimnisse dennoch als Teil von Prozesslisten auf dem laufenden System preisgeben, sodass sie nicht wirklich gelöst werden.

Es ist August 2017. Inzwischen verlinken "ältere Vorschläge zum Umgang mit Geheimnissen" in der Originalausgabe auf Ausgaben von 2014.

Es gibt noch keine guten Lösungen für Build-Time-Geheimnisse. Die PR, die das Flag --build-time-secret anbot, wurde ohne Erklärung geschlossen. Nichts in "Also, was wird benötigt?" Abschnitt umgesetzt wird.

inzwischen

Neu installierter CEO Steve Singh mit Fokus auf Geschäftskunden
Letzte Runde von 75 Millionen US-Dollar zur Unterstützung des Vertriebs- und Marketingteams

UPD.: Wie @cpuguy83 unten richtig und zu Recht darauf hingewiesen hat, ist die vollständige Zusammenfassung der Vorschläge unter #33343

Ich weiß, dass es nicht integriert ist, aber secrets-bridge funktioniert im Moment ziemlich gut.

@dmitriid Ich verstehe Ihre Frustration, dass diese Funktion fehlt. Dies ist jedoch nicht die Art, wie man eine Open-Source-Community (oder eine andere Community) anspricht.

Ich habe oben einen Link zu einem Vorschlag gepostet und habe bis auf meinen eigenen genau 0 Kommentare dazu gesehen.

Hier ist der neueste Geheimvorschlag: #33343

@cpuguy83 Genial ! Ich habe das letzte Drittel dieser Diskussion (und ein paar andere) irgendwie übersprungen, da es viel zu lesen ist (während gleichzeitig nach einer Lösung gesucht wird), also habe ich deinen Kommentar wirklich verpasst, sorry :(

Dieser Thread wurde 2015 gestartet.

Es ist 2017.

Warum gibt es noch keine Lösung für Build-Time-Geheimnisse, die nicht hackisch und schrecklich ist? Es ist ganz offensichtlich ein großes Problem für viele Leute, aber es gibt immer noch keine wirklich gute Lösung!

@mshappe

Warum gibt es noch keine Lösung für Build-Time-Geheimnisse, die nicht hackisch und schrecklich ist?

Weil es ein schwieriges Problem ist, richtig zu lösen, und es wird von buchstäblich Millionen von Menschen verwendet.

Bitte beachten Sie meinen Kommentar direkt über Ihrem:

Ich habe oben einen Link zu einem Vorschlag gepostet und habe bis auf meinen eigenen genau 0 Kommentare dazu gesehen.
Hier ist der neueste Geheimvorschlag: #33343

Wenn Sie etwas implementiert sehen möchten, müssen Sie mehr tun, als sich darüber zu beschweren, dass etwas nicht implementiert ist. Bitte kommentieren Sie den Vorschlag!

Es ist so einfach zu lösen. Es braucht nur etwas, alles was nicht ist
in die Bilder eingebrannt. Und eigentlich ist es sehr einfach zu lösen, hör auf zu verwenden
'docker build' und verwenden Sie die Python-API, Rocker oder etwas anderes.

Am Mittwoch, 23. August 2017 um 21:42 Uhr, Brian Goff [email protected]
schrieb:

@mshappe https://github.com/mshappe

Warum gibt es keine Lösung für Build-Time-Geheimnisse, die nicht hackisch ist und
schrecklich, doch?

Weil es ein schwieriges Problem ist, richtig zu lösen, und es ist etwas, das
wird von buchstäblich Millionen von Menschen genutzt.

Bitte beachten Sie meinen Kommentar direkt über Ihrem:

Ich habe oben einen Link zu einem Vorschlag gepostet und habe genau 0 Kommentare zu gesehen
es außer meinem eigenen.
Hier ist der neueste Geheimvorschlag: #33343
https://github.com/moby/moby/issues/33343

Wenn Sie etwas implementiert sehen möchten, müssen Sie mehr tun als
beschweren, dass etwas nicht implementiert ist. Bitte kommentieren Sie den Vorschlag!

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/moby/moby/issues/13490#issuecomment-324441280 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AAZk5oEpcipmfCji1mXz6MOVt0p6-OA6ks5sbIC0gaJpZM4Eq021
.

@binarytemple Ich habe angefangen, Rocker als Alternative zu betrachten ... aber nur wegen dieser seltsamen mentalen Blockade, die Docker über Build-Time-Geheimnisse zu haben scheint.

Es ist komisch. Ich rede mit Leuten und sie machen alle möglichen dummen Hacks
wie die Verwendung eines HTTP-Dienstes - alles wegwerfen (Überwachung/granular
Berechtigungen/Einfachheit) die POSIX/SELinux-Kombination bereitstellt. Ich tue es einfach nicht
verstehen. Die Ablehnung erscheint mir unlogisch.

Am Mittwoch, 23. August 2017, 23:03 Uhr Michael Scott Shappe [email protected]
schrieb:

@binarytemple https://github.com/binarytemple Ich habe angefangen zu suchen
Rocker als Alternative, eigentlich...aber nur deswegen so seltsam
mental block docker scheint über Build-Time-Geheimnisse zu verfügen.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/moby/moby/issues/13490#issuecomment-324461257 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AAZk5ppZYsOhdfvgotCUk5l41Truo_EEks5sbJOLgaJpZM4Eq021
.

Mehrstufige Docker-Builds lösen viele dieser Probleme.

In seiner einfachsten Form können Sie Geheimnisse als Build-Argumente einfügen, und sie werden nur Teil der Bildhistorie der Bilder sein, die ausdrücklich sagen, dass sie das Argument benötigen. Wie neclimdul betont , werden die Geheimnisse während des

Unser Build-Server läuft mit einigen Geheimnissen, die als Volumes gemountet sind, daher ist unsere CI-Kopie in z. /mnt/secrets/.npmrc in das aktuelle Arbeitsverzeichnis. Dann verwenden wir ein Dockerfile ähnlich dem unten.

FROM node:latest
WORKDIR /usr/src/app
COPY .npmrc .
RUN echo '{ "dependencies": [ "lodash" ] }' > package.json
RUN npm install
RUN ls -lah

FROM alpine:latest
WORKDIR /usr/src/app
COPY --from=0 /usr/src/app/node_modules ./node_modules
RUN ls -lah
CMD ["ls", "./node_modules"]

Das resultierende Image hat die installierten Abhängigkeiten, aber nicht die .npmrc oder irgendwelche Spuren seines Inhalts.

Die Verwendung von mehrstufigen Builds gibt Ihnen die volle Kontrolle darüber, wie Sie Build-Zeitgeheimnisse für den Build-Prozess offenlegen. Sie können Geheimnisse von externen Speichern wie Vault, über Volumes (die wir aus dem Secrets-Speicher in Kubernetes mounten) abrufen, indem Sie sie im Repository gpg-verschlüsseln, Travis-Secrets usw.

Wenn Sie mehrstufige Builds für diesen Anwendungsfall verwenden, stellen Sie sicher, dass die geheimen Daten in einem ungetaggten Image im lokalen Daemon verbleiben, bis dieses Image gelöscht wird, damit diese Daten für den Build-Cache in nachfolgenden Builds verwendet werden können. Es wird jedoch nicht an die Registrierung übertragen, wenn das letzte mit Tags versehene Image übertragen wird.

@androa Ich mag diese Lösung, bin mir aber nicht sicher, wie ich mich darüber fühle, dass die Geheimnisse in das Arbeitsverzeichnis kopiert werden. Das ist wahrscheinlich auf einem privaten CI-Server in Ordnung, aber es ist nicht so toll für lokale Gebäude, wo Sie Dateien kopieren würden, die Sie nicht von geschützten Orten aus kopieren sollten (ganz zu schweigen davon, dass das Kopieren selbst sowohl ärgerlich als auch gefährlich ist, da sie versehentlich enden könnten in der Quellcodeverwaltung). Die andere Möglichkeit wäre, einen breiteren Docker-Build-Kontext zu verwenden, aber für viele gemeinsame Geheimnisse könnte das das gesamte Root-Volume bedeuten. Irgendwelche Vorschläge, wie man dies für Local und CI schön machen kann?

Das ist erschreckend. Die selbsternannte "weltweit führende Software-Container-Plattform" kann sich seit 3 ​​Jahren nicht mehr die Mühe machen, Build-Time-Geheimnisse sicher in Container zu übertragen.

Durch den Ansatz "Wir wissen es besser" und "Machen Sie keine Software, die Fehler erlaubt" und was bestenfalls als bedauerliche Auslassung in der Designphase beschrieben werden kann, gibt es keine Unterstützung und keinen sichtbaren Fortschritt in Richtung einer der erforderlichen Funktionen von DevOps-Software. Alle von der Community vorgeschlagenen und manchmal sogar zu fusionsbereiten Verbesserungen entwickelt werden, aus Angst, dass jemand sie missbraucht. Als Ergebnis dieses Cluster-Fehlers müssen alle Möglichkeiten zum Übergeben privater Schlüssel, die nur für die Build-Phase des Docker-Containers benötigt werden, diese Geheimnisse im Build-Verlauf speichern oder in der Prozessliste sichtbar sein, in der Hoffnung, dass der Build-Verlauf das vertrauenswürdige Maschine oder niemand, der die Prozessliste nie sehen soll. Beide werden selbst die meisten freizügigen Sicherheitsüberprüfungen fehlschlagen.

Diese Ausgabe ist seit über 2 Jahren offen, um zusammenzufassen, was damals über das Problem bekannt war und was man dagegen tun kann. Es gibt immer noch keine Lösung. Damit meine ich keine umfassende Lösung, die die komplexesten Geheimverwaltungsschemata out of the box unterstützt. Es gibt ÜBERHAUPT keine Lösung, keine Host-Umgebungsvariablen, kein Laden von Geheimnissen aus dem Dateipfad außerhalb des Build-Kontexts. Nichts, was auch nur unter den geringsten Bedingungen als sicher angesehen werden kann.

@OJezu Wie ich bereits mehrfach zu diesem Thema gesagt habe, gibt es einen offenen Vorschlag mit grundsätzlich 0 Kommentaren dazu.
Wenn Sie wissen möchten, wie Geheimnisse vorangetrieben werden, nehmen Sie sich bitte die Zeit, den Vorschlag zu kommentieren.

Anstatt die Leute, die jeden Tag daran arbeiten, mit Waffen zu attackieren, versuchen Sie das nächste Mal, Fragen zu stellen und zumindest die neuesten Kommentare zu dem Thema zu lesen, zu dem Sie kommentieren.

Die Dinge können oft ins Stocken geraten, wenn wirklich nur Leute hart arbeiten.
Informationen zum Build finden Sie unter github.com/moby/buildkit, wo die meisten dieser Arbeiten heute stattfinden.

Vielen Dank.

Ich bin ein bisschen beschwipst, weil ich heute 9 Stunden damit verbracht habe, eine Lösung für etwas zu finden, das kein Problem sein sollte, insbesondere in einem Projekt, das in Vollzeit bearbeitet wird und sich als De-facto-Standard und Go-to-Solution positioniert . Ich versuchte sehr, nicht zu fluchen und aufzuhören, mich selbst zu verletzen, während ich diese Kommentare schrieb.

Ich habe mir dieses Problem angesehen und Hinweise auf zwei Lösungen gesehen, eine seit April ins Stocken geraten, die andere bereits geschlossen. Ich kann nicht umhin zu bemerken, dass der Vorschlag für 0 Kommentare 4 Teilnehmer hat, die gleiche Anzahl von Kommentaren hat und einige offensichtliche interne Diskussionen erwähnt, vermutlich von Leuten, die mit den Feinheiten von vertrauter sind. Wenn Sie jedoch zusätzliches Feedback von jemandem wünschen, der nicht einmal in go programmiert, kann ich Ihnen weitere Gedanken zu Problemen geben, die ich im vorherigen Kommentar angesprochen habe.

@OJezu

Es gibt zumindest eine einfache Lösung: Verwenden Sie einen dedizierten Dienst (zB auf Jenkins laufen), um Artefakte zu erstellen.
Dieser Dienst stellt sicher alle erforderlichen Schlüssel für den Zugriff auf Artefakte bereit, von denen Ihr Image abhängt.
Am Ende werden Artefakte an einem sicheren Ort (zB Jenkins) platziert. Diese Artefakte würden keine Geheimnisse enthalten, nur ein Verzeichnis mit binaries/sources/etc.
Dann greift ein anderer Dienst (zB ein anderer Jenkins-Job) auf diese vorgefertigten Artefakte zu und wandelt sie in ein Image um, das sicher in eine Image-Registry gepusht werden kann, die wiederum sicher mit rbac/keys geschützt ist, um von Entwickler-/Produktionsmaschinen darauf zuzugreifen.

Dh der Docker-Image-Build-Prozess unterscheidet sich nicht von jedem anderen Build-System auf dem Markt: Sie müssen eine Build-Pipeline haben.

@ Vanuan nicht alle Sprachen sind mit Verpackung und Installation so einfach, dass sie einfach mit einem Artefakt installiert werden.

Beispiele?

Python-Projekte beziehen ihre Anforderungen auf die Installationszeit, nicht auf die gebaute Zeit. In unserem Fall aus einem privaten Pypi/Conda-Repository (passwortgeschützt)

So? Machen Sie die Installation zu einem Teil Ihres Build-Prozesses und kopieren Sie dann installierte Pakete in ein neues Image.

Sie müssen nur sicherstellen, dass Ihr Build-Image und Ihr Produktions-Image auf demselben Python-Basisimage basieren.

Sie können tatsächlich alles in ein neues Bild kopieren. Das entfernt jedoch den ganzen Sinn einer Dockerfile. Warum ein Dockerfile haben, wenn Sie es nur verwenden können, um eine Reihe von Verzeichnissen zu kopieren?

Ich kann also keinen einfachen Flow haben, in dem ich einfach docker build . ausführe, wo auch immer - entweder auf der Entwicklungsmaschine oder auf CI, aber ich muss mich auf CI verlassen, um Pakete zu erstellen. Warum sich dann überhaupt mit Docker beschäftigen? Ich kann eine Travis-Datei schreiben oder den Flow in Bambus konfigurieren.

Können Sie nicht einfach pip install requirements.txt in Ihrem ersten Stage-Build mit Geheimnissen aus Ihren privaten Repositorys abrufen? Dann kopiert der nächste Stage-Build einfach die Site-Pakete aus der ersten Stage.

Warum ein Dockerfile haben, wenn Sie es nur verwenden können, um eine Reihe von Verzeichnissen zu kopieren?

Warum nicht? Die Verwendung einer Dockerfile zum Erstellen ist konsistent.

Die Bildspezifikation ist mehr als nur ein Haufen gezippter Dateien. Es gibt Umgebungsvariablen, Befehlszeilenargumente, Volumes usw

Lesen Sie die Dockerfile-Referenz:
https://docs.docker.com/engine/reference/builder/

Es sieht so aus, als ob Sie sich hauptsächlich auf die Anweisung RUN und denken, dass Dockerfile ein Ersatz für Ihr Makefile ist. Es ist nicht. Dockerfile ist nur für eines gedacht: ein Image aus Quellmaterial zu erstellen. Was dieses Quellmaterial wäre - eine über http heruntergeladene Binärdatei oder ein Git-Repository - spielt keine Rolle. Docker muss nicht Ihr CI-System sein, auch wenn Sie es unter bestimmten Bedingungen als solches verwenden können.

Ich kann eine Travis-Datei schreiben oder den Flow in Bambus konfigurieren.

Wenn Sie das Ergebnis Ihres Build-Prozesses abrufen und ihn dann in einer anderen Umgebung ohne Images und Container ausführen können, müssen Sie sich mit Docker nicht mehr herumschlagen. Warum würdest du?

Separate, streng kontrollierte Umgebung, die garantierte Resets zwischen Builds erhält, jedoch nur, wenn sich die Build-Schritte geändert haben. Möglichkeit, es überall auszuführen, nicht nur auf CI-Servern (wie bei Travis), Build-Anweisungen mit Code zu verknüpfen, was meiner Meinung nach gut ist, wenn Build-Änderungen für verschiedene Code-Zweigs vorgenommen werden (z. B. Version der Ausführungsumgebung nur auf einem Zweig ändern). Möglichkeit, einen Build-Container auf Entwicklermaschinen auszuführen, wodurch die gesamte Umgebung an Entwickler gesendet werden kann, die ansonsten keine Ahnung haben, wie sie ihr eigenes System aktualisieren sollen, aber in der Lage sind, Anwendungen mit ihren Änderungen lokal mit derselben Umgebung wie alle anderen zu erstellen.

Wenn ich das alles nicht wollte, würde ich bei lxc + ansible bleiben, dann brauche ich kein Docker.

Dafür brauchst du nicht docker build .

Dafür brauchst du nicht docker build .

Natürlich können Sie für jedes Projekt auch ein benutzerdefiniertes Makefile oder build_image.sh Skript anstelle eines einzelnen autarken Dockerfiles bereitstellen, aber das hat mehrere Nachteile:

• Plattformübergreifende Kompatibilität: Mit der Bereitstellung eines Dockerfiles weiß ich, dass jedes System, auf dem docker build werden kann, das Image erstellen kann. Bei der Bereitstellung eines benutzerdefinierten Makefile oder build_image.sh muss ich manuell sicherstellen, dass diese auf allen Plattformen funktionieren, die ich unterstützen möchte.
• Bekannte Schnittstelle für Benutzer: Wer Docker kennt, kennt einiges vom Verhalten von docker build für jedes Projekt, auch ohne das Dockerfile anzuschauen (zB in Bezug auf Caching, etc...). Wenn ich ein benutzerdefiniertes Makefile oder build_image.sh , muss ich für jedes Projekt zuerst herausfinden, welche Befehle zu erstellen, zu bereinigen sind, wo und in welcher Form das Ergebnis vorliegt, falls vorhanden ist etwas Caching und in welcher Form, ...

Oh, Dockerfile ist alles andere als autark. Speziell für die Entwicklungsumgebung.
Bedenken Sie:

• die meisten Entwickler kennen nicht all die verschiedenen Optionen von docker build , aber fast jeder weiß, wie man Bash-Skripte ausführt
• docker build hängt vom Kontextverzeichnis ab . Wenn Sie also nicht warten möchten, bis Gigabyte an Daten (Ihr Quellcode mit Abhängigkeiten) für jede einzelne Quellzeilenänderung von einem Ort zum anderen wandern, werden Sie ihn nicht für die Entwicklung verwenden.
• Wenn Sie nicht ALLES von Grund auf neu erstellen, sind Sie von der Docker-Registrierung abhängig
• es ist wahrscheinlich, dass Sie auf Betriebssystem-Repositorys angewiesen sind (unabhängig davon, ob Sie Debian- oder Alpine-basierte Images verwenden), es sei denn, Sie booten einen Container direkt in die statisch erstellte Binärdatei
• Wenn Sie nicht alles an Git übergeben, haben Sie einige Abhängigkeiten auf Projektebene, sei es npm, Python-Paketindex, Rubygems oder irgendetwas anderes. Sie sind also auf eine externe Paketregistrierung oder ihren Spiegel angewiesen
• Wie die meisten hier bemerkt haben, sind Sie für Ihre privaten Abhängigkeiten von einem geheimen Paketspeicherort
• Für den Zugriff auf diesen sicheren Ort ist die Bereitstellung von Geheimnissen erforderlich. Sie sind also auf ein System angewiesen, das Geheimnisse an Entwickler verteilt.
• zusätzlich zu Dockefile benötigen Sie docker-compose.yml, und es ist nicht plattformübergreifend: Sie sind immer noch auf Vorwärts-/Rückwärtsstrichunterschiede angewiesen.

Plattformübergreifende Kompatibilität: Mit der Bereitstellung eines Dockerfiles weiß ich, dass jedes System, das Docker-Build ausführen kann, das Image erstellen kann.

Dockerfile gewährleistet keine plattformübergreifende Kompatibilität. Sie müssen weiterhin mehrere Dockerfiles für mehrere Plattformen bereitstellen. "Can run docker build" bedeutet nicht mehr "Uses Linux". Docker unterstützt auch native Windows-Images. Sie müssen weiterhin Cygwin + Linux VM verwenden, wenn Sie etwas speziell für Linux-Maschinen auf einem Windows-Host ausführen möchten.

Oh, und ich habe x86 vs ARM nicht einmal erwähnt...

Bekannte Schnittstelle für Benutzer: Wenn Sie Docker kennen, kennen Sie einiges über das Verhalten von Docker Build für jedes Projekt, auch ohne sich das Dockerfile anzusehen

Es sei denn, Sie tun es nicht. Jeder weiß, wie man ein Bash-Skript ohne Parameter oder einen einzigen make Befehl ausführt. Nur wenige Leute wissen, wie man die verschiedenen Befehlszeilenoptionen für docker build , docker run oder docker-compose richtig angibt. Es ist unvermeidlich, dass Sie ein Wrapper-Bash- oder CMD-Skript haben.

Bei allem Respekt vor dem, was die Docker-Leute getan haben, ich denke, Sie verlangen zu viel. Ich fürchte, das Mobyproject hat nicht so einen breiten Anwendungsbereich, um alle erdenklichen Entwicklungsworkflows zu unterstützen.

Ich werde nicht alle Ihre Punkte einzeln widerlegen. Erstens kann man natürlich immer Situationen finden, in denen der "Single Dockerfile"-Ansatz überhaupt nicht funktioniert. Ich würde jedoch argumentieren, dass für fast alle Ihre Punkte, die Sie angesprochen haben (die alle gültig und relevant sind), der Ansatz "benutzerdefiniertes Skript oder Makefile" entweder genauso schlecht oder schlechter ist. Nur als Beispiel ein Punkt:

Die meisten Entwickler kennen nicht all die verschiedenen Optionen des Docker-Builds, aber fast jeder weiß, wie man Bash-Skripte ausführt

Wenn ich an 10 Projekten beteiligt bin und alle ein Dockerfile verwenden, muss ich Docker nur einmal lernen, aber mit Ihrem Vorschlag muss ich 10 völlig unterschiedliche Build-Skripte lernen. Wie lösche ich den Cache und beginne für das Projekt Foo's build_image.sh wieder von vorne? Es ist nicht klar. Wenn das Image mit docker build , ist es klar (ofc muss ich wissen, wie Docker funktioniert, aber ich muss das auch tun, um das Image zu verwenden, das aus build_image.sh ).

Insgesamt denke ich, dass ich und andere versuchen, darauf hinzuweisen, dass für / viele/ Szenarien der "Single Dockerfile" -Ansatz für die Leute wirklich gut zu funktionieren scheint (was ein Grund dafür ist, dass Docker so beliebt ist), insbesondere in den Open-Source-Welt, in der normalerweise alle Ressourcen ohne Geheimnisse zugänglich sind. Aber wenn Sie versuchen, das gleiche Muster, das Sie lieben gelernt haben, in einem Kontext anzuwenden, in dem ein Teil Ihrer Ressourcen Zugangsberechtigungen benötigt, scheitert der Ansatz. Es gab eine Reihe von Vorschlägen (und Implementierungen) von technologisch nicht allzu komplexen Wegen, um es zum Funktionieren zu bringen, aber es ist über lange Zeit nichts daraus geworden (dies wurde oben oft dargelegt). Daher der Frust.

Ich weiß es zu schätzen, dass sich die Leute Mühe geben, zum Beispiel mit dem verlinkten Vorschlag in #33343. In meinem Beitrag geht es darum, zu motivieren, was manche Leute was machen und warum sie immer wieder hierher kommen und danach fragen.

Bei allem Respekt vor dem, was die Docker-Leute getan haben, ich denke, Sie verlangen zu viel. Ich fürchte, das Mobyproject hat nicht so einen breiten Anwendungsbereich, um alle erdenklichen Entwicklungsworkflows zu unterstützen.

Es scheint mir, dass die meisten Leute hier nichts dergleichen verlangen, sondern nur eine einfache Möglichkeit, Geheimnisse in docker build auf eine Weise zu verwenden, die nicht weniger sicher ist als in Ihrem benutzerdefinierten build_image.sh . Eine Möglichkeit, dieses Bedürfnis zu befriedigen, scheint darin zu bestehen, Zeithalterungen zu erstellen. Sie haben Nachteile, es gibt wahrscheinlich bessere Möglichkeiten, aber es wird nicht darum gebeten, jeden möglichen Eckfall abzudecken.

Es tut mir leid, aber jede Person in diesem Ticket hat einen etwas anderen Anwendungsfall. Das sind Eckfälle und erfordern andere Lösungen.

1. Ich möchte Produktionsimages auf Entwicklungsmaschinen ausführen. Docker-Registry verwenden
2. Ich möchte ein verteiltes CI-System, damit jeder Entwickler einen reproduzierbaren Build hat. Verwenden Sie docker run , um Ihr Projekt zu erstellen, verwenden Sie docker prune zum Aufräumen
3. Ich möchte Docker-Images erstellen, damit ich sie verteilen kann. Verwenden Sie einen dedizierten CI-Server, auf dem Sie mehrstufige Builds ausführen können.

@Vanuan , also denke ich, Ihr Ansatz ist im Grunde: Verwenden Sie Docker-Build nicht für mehr als die grundlegende Umgebung. Dies ist ein Problem, das geschaffen wurde, um das zu ändern. "Man muss es anders machen" IST das Problem, nicht die Lösung.

Leute, die das Thema vorantreiben, möchten einfachere und unkompliziertere Ansätze mit Docker-Images haben, ohne Docker-Beschränkungen umgehen zu müssen.

Für alle Interessierten: Ich hatte versucht, "standardmäßig maskierte" Build-Args wie FTP_PROXY auszunutzen, um Kontexte zu erstellen. Es ist sicher, dass Docker-Build diese maskierten Argumente weder Bildmetadaten noch Bildebenen aussetzt.

36443 war ein Versuch, es zu einem Build-Arg namens SECRET damit wir Benutzer dazu ermutigen können, es als einfache Lösung für das Problem der Geheimverwaltung zu verwenden.

Die Arbeit wurde jedoch vernünftigerweise abgelehnt, da die maskierte Natur dieser Build-Argumente in Zukunft nicht garantiert werden kann.

Meine beste Wette danach ist, dem Rat von @AkihiroSuda zu folgen, docker build --network oder ein Tool wie habitus zu verwenden, um Geheimnisse über einen temporären TCP-Server zu speichern / weiterzugeben.

Teilweise kommentieren, so dass ich in 5 Jahren benachrichtigt werde, wenn Docker endlich beschließt, uns einen kleinen Schritt in Richtung einer ordnungsgemäßen Verwaltung von Anmeldeinformationen zu geben.... und auch, um einen Überblick über den Hack zu geben, den ich derzeit verwende , um anderen zu helfen oder Löcher hineinzustecken, von denen ich nichts weiß.

In der folgenden @mumoshu- Ausgabe bekam ich endlich den Hinweis, die vordefinierten Argumente für Build-Geheimnisse zu verwenden.

Im Wesentlichen kann ich docker-compose mit einer Zuordnung wie dieser verwenden:

  myProject:
    build:
      context: ../myProject/
      args: 
        - HTTPS_PROXY=${NEXUS_USERNAME}
        - NO_PROXY=${NEXUS_PASSWORD}

Erstellen Sie dann im Ordner mit der Datei docker-compose.yml eine Datei namens ".env" mit den Schlüssel-Wert-Paaren NEXUS_USERNAME und NEXUS_PASSWORD - und den entsprechenden Werten dort.

Schließlich geben wir im Dockerfile selbst unseren run-Befehl wie folgt an:
RUN wget --user $HTTPS_PROXY --password $NO_PROXY

Und deklarieren Sie diese NICHT als ARGs im DockerFile.

Ich habe meine Anmeldeinformationen noch nirgendwo im resultierenden Build gefunden ... aber ich weiß nicht, ob ich überall suche ..... Und für den Rest der Entwickler in meinem Projekt müssen sie einfach jeder Erstellen Sie die .env-Datei mit den entsprechenden Werten.

@darmbrust Ich habe Ihre Lösung ausprobiert, konnte sie aber nicht zum
Hier ist mein Compose-Yml:
Version: "3.3"
Dienstleistungen:

  buildToolsImage:
    image: vsbuildtools2017:web-v6

    build:
      context: .
      dockerfile: ./vsbuild-web-v6-optimized.dockerfile
      args:
        - CONTAINER_USER_PWD=${CONTAINER_USER_CREDS}

Hier ist die .env-Datei neben der yml-Datei:

CONTAINER_USER_CREDS=secretpassword

Und hier ist mein Dockerfile:

# escape=`
FROM microsoft/dotnet-framework:4.7.2-sdk
# Add non-root user
CMD ["sh", "-c", "echo ${CONTAINER_USER_PWD}"] 
RUN net user userone ${CONTAINER_USER_PWD} /add /Y

Und schließlich lautet der Befehl zum Anstoßen so:

docker-compose -f docker-compose.buildImage.yml build

Es erstellt das Image, jedoch ohne das in der .env-Datei gespeicherte Passwort zu verwenden.

[Warnung] Mindestens ein Build-Arg [CONTAINER_USER_PWD] wurde nicht verbraucht

Was fehlt mir hier?
Vielen Dank!

Sie müssen eines der https://docs.docker.com/engine/reference/builder/#predefined -args in der Docker-Datei verwenden. Sie können keine eigenen Argumentnamen wie CONTAINER_USER_PWD verwenden.

So funktioniert der Trick, denn Docker hat ein spezielles Verhalten für die vordefinierten Argumente, indem Sie sie verwenden können, ohne sie zu deklarieren. Und wenn Sie sie verwenden, ohne sie zu deklarieren, scheinen sie nirgendwo protokolliert zu werden.

Mit der Datei docker-compose können Sie diese vordefinierten Argumente einem vernünftigeren Namen zuordnen.

@darmbrust Ja, das hat
Aber finden Sie nicht, dass es stinkt? Gibt es bessere Empfehlungen?
Vielen Dank!

Es ist wahrscheinlich nicht so übel wie die Offenlegung Ihrer SSH-Agent-Anmeldeinformationen über TCP
über socat für jeden lokalen Prozess zum Stehlen, aber tatsächlich, wie bei allem
Was Geheimnisse betrifft, ist 'Docker Build' in der Tat ziemlich stinkend.

Eigentlich hatte ich vergessen, dass Docker für Mac keine Unix-Domain freigeben kann
Sockets auf dem osx-Host zu den Containern, so dass sich noch mehr von a
Dose Würmer.

Meine aktuelle Lösung: Führen Sie ein Centos-VM, ein GitHub-Computerbenutzerkonto aus
Zugangsdaten gehen hinein, erstellen Sie mit dem "Rocker" (veralteten) Tool.

Am Do, 26. Juli 2018, 21:49 Uhr schrieb Sameer Kumar, [email protected] :

@darmbrust https://github.com/darmbrust Ja, das hat geholfen .
Aber finden Sie nicht, dass es stinkt? Gibt es bessere Empfehlungen?
Vielen Dank!

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/moby/moby/issues/13490#issuecomment-408230125 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AAZk5iz1kvCpZ0s65ng4TwL7LmHa9zZvks5uKitDgaJpZM4Eq021
.

Dieser ganze Fehler stinkt. Ich habe keinen besseren Weg gefunden ... es gibt oben mehrere andere Ansätze, aber ich denke, alle anderen sicheren erfordern einen kleinen http-Server, um die Informationen in das Bild einzugeben. vielleicht weniger stinkend, aber mehr Komplexität, mehr Werkzeuge, mehr bewegliche Teile.

Ich bin mir nicht sicher, ob jemand eine "gute" Lösung gefunden hat ... wir alle warten darauf, dass die Docker etwas dagegen unternehmen ... halten Sie nicht den Atem an, da dieser Fehler 2015 geschrieben wurde, und sie haben Es wurde noch nicht einmal eine Roadmap vorgeschlagen, geschweige denn eine Lösung.

Es ist so einfach und offensichtlich, ermöglichen Sie das Einbinden von Volumes (Dateien oder
Verzeichnisse) während des Builds in den Container.

Dies ist keine technische Einschränkung, sondern eine Entscheidung, keine Geheimnisse zuzulassen
um das Verhalten von - check out, run build, same input, same . beizubehalten
Ausgabe, ändern Sie ein Build-Argument, wenn Sie den Cache ungültig machen möchten ...

Das Problem ist, dass die Abstraktion immer undicht wird
mit Leuten, die alle möglichen kludgy, unsicheren Hacks verwenden, um ein "Geheimnis" zu bekommen
in einen Behälter.

Newsflash, Offenlegen Ihres SSH-Schlüsselbunds über TCP, auch auf localhost nicht
sicher, ebenso wenig wie die Weitergabe von Anmeldeinformationen über Umgebungsvariablen (hint, run
ps oder ein Blick in das /proc-Dateisystem), Befehlsargumente und Umgebungsvariablen sind für die Welt sichtbar.

Für Entwickler von Golang-Code war dies traditionell kein Problem, da sie kopieren und einfügen
ihre Abhängigkeiten in ihre Projekte zu integrieren, anstatt ein Abhängigkeitsmanagement-Tool zu verwenden, nennen Golang-Entwickler diese Praxis „Vendoring“.

Für alle, die in anderen Ökosystemen arbeiten, in denen das Build-System
Abhängigkeiten von Git oder Repositorys abruft, die eine Authentifizierung erfordern, ist dies ein großes Problem.

Ich bin mir ziemlich sicher, dass es irgendwo eine Startregel in der Art gibt:
"nehmen Sie nicht an, dass Sie wissen, wie oder warum Ihre Benutzer das Produkt verwenden".

Am Do, 26. Juli 2018, 22:00 Uhr schrieb Dan Armbrust, [email protected] :

Dieser ganze Fehler stinkt. Ich habe keinen besseren Weg gefunden ... es gibt
einige andere Ansätze oben, aber ich denke, alle anderen sicheren sind
erfordern das Aufstellen eines kleinen http-Servers, um die Informationen in die
Bild. vielleicht weniger stinkend, aber mehr Komplexität, mehr Werkzeuge, mehr bewegend
Teile.

Ich bin mir nicht sicher, ob jemand eine "gute" Lösung gefunden hat... wir stecken alle fest
warte darauf, dass die Hafenarbeiter etwas dagegen tun... halte dich nicht fest
Atem, da dieser Fehler 2015 geschrieben wurde und sie nicht einmal vorgeschlagen haben
noch eine Roadmap, geschweige denn eine Lösung.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/moby/moby/issues/13490#issuecomment-408233258 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AAZk5nvbBTj4BAv5TtELNIHhJN8mU0Ctks5uKi38gaJpZM4Eq021
.

@binarytemple Jeder, der schon einmal an Docker/moby gearbeitet hat (wie in den Ingenieuren dahinter) weiß genau, was das Problem ist und ist sogar darauf gestoßen.

Volumes ist eine Lösung, die selbst unglaublich undicht ist.
Es gibt einen Vorschlag, der im Kommentarstream ein wenig erwähnt wird und versucht, dies auf vernünftige Weise zu lösen (https://github.com/moby/moby/issues/33343)

Hier geht es vor allem darum, die "richtige" Abstraktion bereitzustellen und nicht "jede Abstraktion, die zufällig funktioniert" ... wir wissen natürlich, dass dies für viele nicht nur in diesem Fall schmerzhaft ist.

In letzter Zeit wurde viel an dem Builder gearbeitet, was noch nicht unbedingt sichtbar ist, aber die Früchte dieser Bemühungen werden sich in den kommenden Monaten zeigen.
Docker 18.06 wird zunächst mit einer alternativen Builder-Implementierung ausgeliefert, die von https://github.com/moby/buildkit unterstützt wird
Sie denken vielleicht: "Wie hilft mir das?". Buildkit bietet viele Low-Level-Primitive, die es uns ermöglichen, im Docker-Builder viel flexibler zu sein. Sie können sogar Ihren eigenen Build-Parser bereitstellen (der von einem erweiterten Dockerfile-Parser bis hin zu etwas ganz anderem sein kann). Parser werden oben in der "Dockerfile" angegeben und sind einfach ein beliebiges Bild, das Sie zum Parsen der Datei verwenden möchten.

Wenn Sie jetzt wirklich etwas sehen möchten, können Sie Buildkit selbst nehmen und heute damit ausführen, es sitzt auf containerd, Sie können ziemlich schnell eine benutzerdefinierte Integration erstellen.

Unterstützung für geheime Halterungen wurde dem Buildkit in https://github.com/moby/buildkit/pull/522 hinzugefügt. Sie erscheinen ausschließlich auf tmpfs, sind vom Build-Cache ausgeschlossen und können eine konfigurierbare Datenquelle verwenden. Noch kein PR, der es in einer Dockerfile-Syntax verfügbar macht, aber eine einfache Ergänzung sein sollte.

Es gibt 2 Lösungen, um Bilder mit Geheimnissen zu erstellen.

Mehrstufiger Aufbau:

FROM ubuntu as intermediate
ARG USERNAME
ARG PASSWORD
RUN git clone https://${USERNAME}:${PASSWORD}@github.com/username/repository.git

FROM ubuntu
# copy the repository form the previous image
COPY --from=intermediate /your-repo /srv/your-repo

Dann: docker build --build-arg USERNAME=username --build-arg PASSWORD=password my-image .

Verwenden eines Image-Builders: docker-build-with-secrets

@BenoitNorrin Entschuldigung, aber Sie haben dieses Passwort für jeden Prozess auf dem Hostsystem verfügbar gemacht. Unix-Sicherheit 101 - Geben Sie keine Geheimnisse als Befehlsargumente ein.

Ja, aber es gibt einige Anwendungen, bei denen die Sicherheit etwas weniger wichtig ist:

• Sie möchten auf Ihrem eigenen Computer bauen
• Sie bauen auf Ihrem Unternehmens-CI-Server (wie Jenkins) auf. Meistens geht es darum, Zugriff auf ein privates Repository (nexus, git, npm usw.) zu haben, sodass Ihr CI möglicherweise seine eigenen Anmeldeinformationen dafür hat.
• Sie können eine von Docker-Maschine erstellte VM verwenden und sie danach entfernen.

Wenn das das einzige Problem ist, @binarytemple , dann sollte das einfache Hinzufügen des Flags docker image build --args-file ./my-secret-file eine ziemlich einfache Lösung für dieses ganze Problem sein, nicht wahr ? :Denken:

@yajo könnte sein, ja, es ist zumindest ein Workaround, bis das Buildkit mit Secrets Mount ausgeliefert wird. Guter Vorschlag. Vielen Dank. B

Leider enthüllen die meisten der in diesen und vielen anderen Tickets erwähnten Workarounds immer noch die Geheimnisse des resultierenden Images oder funktionieren nur mit bestimmten Sprachen, bei denen Sie nur während der Kompilierzeit und nicht während der Installation Abhängigkeiten benötigen.

@binarytemple das wird nie passieren, die Docker-Betreuer haben bereits mindestens einen PR vollständig dokumentiert und vollständig implementiert einer sicheren geheimen Funktion getötet. Angesichts des Rests der Geschichte (dieses 3 Jahre alte Ticket ist nicht das älteste und definitiv nicht das einzige Ticket / PR zu diesem Thema) kann man mit Sicherheit sagen, dass die Docker-Maintainer die Notwendigkeit von Sicherheit nicht verstehen, was eine große Bedeutung hat Problem.

Der größte Schmerzpunkt sind für mich geheime Rotationen

Sie müssen ein Diagramm der Abhängigkeiten von geheimen Diensten verwalten und jeden Dienst zweimal aktualisieren (um zum ursprünglichen geheimen Namen zurückzukehren).

Auflisten von Geheimnissen von Diensten scheint nicht einfach zu sein (ich habe nach einigen Versuchen um docker service inspect --format='{{.Spec.TaskTemplate.ContainerSpec.Secrets}}' <some_service> aufgegeben), Dienstabhängigkeiten von docker secret inspect <secret_name> aufzulisten wäre auch nützlich. Also pflege ich diesen (ungefähren) Graphen vorerst nur manuell.

Sie müssen auch das geheime Ziel angeben, wenn es nicht der Standardwert /run/secrets/<secret_name> im Docker Service Update-Befehl ist

Ich hoffe nur auf eine einfachere Möglichkeit, Geheimnisse zu rotieren

@caub hier ist eine CLI-Hilfe:

Docker-Dokumente zur Formatierung helfen beim Rest Ihres Prüfformats:

docker service inspect --format='{{range .Spec.TaskTemplate.ContainerSpec.Secrets}}{{println .SecretName}}{{end}}'

Dadurch werden alle geheimen Namen in einem Dienst aufgelistet. Wenn Sie sowohl den Namen als auch die ID haben möchten, können Sie:

docker service inspect --format='{{range .Spec.TaskTemplate.ContainerSpec.Secrets}}{{println .SecretName .SecretID}}{{end}}' nginx

Ich habe immer meine CI/CD (Dienstaktualisierungsbefehle) oder Stack-Dateien den Pfad hartkodiert, damit Sie dieses Problem bei der Rotation nicht haben.

Mit Labels können Sie die CI/CD-Automatisierung veranlassen, das richtige Geheimnis zu identifizieren, wenn Sie keine Stack-Dateien verwenden (ohne den geheimen Namen zu benötigen, der jedes Mal anders wäre).

docker build --secret ist endlich in Docker 18.09 verfügbar https://medium.com/@tonistiigi/build -secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066

@thaJeztah Sind wir bereit, dieses Problem zu schließen?

Für ältere Versionen von Docker ist die Verwendung eines mehrstufigen Builds mit dem Kopieren von Geheimnissen vor dem Build-Befehl eine praktikable Option, oder?

```
VON debian als build
KOPIEREN ./secret.conf /path/on/image/
RUN build.sh
...

VON debian
COPY --from=build ...

@andriy-f ja, das funktioniert, solange du;

• (offensichtlich) kopiere das Geheimnis nicht in die letzte Phase 😉, oder:
• Verwenden Sie die build Stufe / Stufe, in der ein Geheimnis vorhanden ist, als "Elternteil" für das endgültige Bild
• _push_ die Build-Phase niemals in eine Registry
• Vertrauen Sie dem Host, auf dem Ihr Daemon läuft; dh unter Berücksichtigung, dass Ihre "Build"-Phase als Bild erhalten bleibt; jemand mit Zugriff auf dieses Bild könnte Zugriff auf Ihr Geheimnis erhalten.

Build-Zeit-Geheimnisse sind jetzt möglich, wenn Buildkit als Builder verwendet wird; siehe den Blogbeitrag hier https://medium.com/@tonistiigi/build -secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066

und die Dokumentation; https://docs.docker.com/develop/develop-images/build_enhancements/

Die Option RUN --mount die für Geheimnisse verwendet wird, wird bald auf die standardmäßige (stabile) Dockerfile-Syntax übergehen

Danke @thaJeztah Ich habe nur ein wenig weiter gegraben und diesen Artikel kurz nach dem Posten gefunden (vorheriger Beitrag ist jetzt gelöscht). Danke noch einmal!

Cool. Damit ist die Frage nach den Geheimnissen der Build-Zeit abgeschlossen. Alles für Laufzeit/Devtime (ssh in OS X)?