Moby: --insecure-registry sollte auf "Docker Pull" stehen

Wir betreiben interne ungesicherte Docker-Registrys in allen CI- und Produktionsumgebungen. Ich muss sagen, dass es sehr sinnvoll wäre, einfach den Zugriff auf alle unsicheren Registrys zu ermöglichen, ohne sie einzeln auflisten zu müssen. Wir haben mehrere Registrierungen in jeder Umgebung für HA. Diese Änderung hat die Dinge für uns viel komplizierter gemacht. Ich werde ein weiteres Issue-Ticket eröffnen, das speziell darauf ausgerichtet ist, da dieses Problem eher darin besteht, die Option in den Pull zu verschieben als in den Daemon.

Und es gibt ein kleines Henne-Ei-Problem, wenn Sie keinen festen Port zum Ausführen der Registrierung verwenden.

Da Sie im Voraus nicht wissen, welcher Port von Docker zugewiesen wird, können Sie die Demo nicht wirklich mit einem Flag starten, das darauf verweist.

:+1:

Ich denke also, dass die Unterstützung von --insecure auf der docker pull Befehlszeile, das zwangsweise Deaktivieren von Sicherheitsprüfungen, offensichtlich für _diesen_ Pull-Befehl, auch Ihr Problem @proppy und @octalthorpe lösen würde,

@abourget es muss auch in der Remote-API unterstützt werden.

Derzeit stellt docker-py ein insecure_registry Flag für die pull Funktion bereit, das jedoch nur zum Auflösen des Endpunkts verwendet wird: https://github.com/docker/docker-py/blob/master/ docker/client.py#L794

Der Täter scheint https://github.com/docker/docker/commit/6a1ff022b0744213ed588d9c16dbb13ce055eda6 . zu sein

Aber ich konnte keine entsprechende PR oder Themen finden, in denen diese Änderung diskutiert wurde.

@tiborvass irgendwelche ideen?

@proppy - Dies wurde als Sicherheitslücke mit einem Embargo behandelt und in einer öffentlichen PR nicht diskutiert. Das Kernteam hatte Sichtbarkeit und Abstimmung über das Thema.

Ich muss über die Auswirkungen einer solchen Änderung für localhost/127.0.0.1 nachdenken, aber ich bin nicht besonders daran interessiert. Es handelt sich um eine nicht standardmäßige, ungewöhnliche Konfiguration und die Lösung ist gut dokumentiert.

@ewindisch auf der anderen Seite läuft bereits eine Menge Docker-Daemon, wobei der Registrierungscontainer auf localhost läuft.

Wenn buchstäblich alle diese Benutzer --insecure-registry localhost:5000 , können Sie es genauso gut zum Standard machen.

@ewindisch Haben Sie eine Dokumentation oder Anleitung für eine Schwachstelle der Embargoklasse? Dies ist kein entferntes, nicht authentifiziertes RCE. Die Gefahr scheint hier bei weitem nicht akut genug zu sein, um einen Breaking Change in einem Point Release ohne Vorwarnung zu rechtfertigen.

@mmdriley - allgemein gilt die Definition nach Mitre/NST. In diesem Fall ist ein Man-in-the-Middle-Angriff möglich, der die Ausführung von beliebigem nicht vertrauenswürdigem Code auf betroffenen Systemen ermöglicht, also ja, wir klassifizieren dies als RCE. Dies bedeutet, dass ein anderer Benutzer dieses WLAN-Zugangspunkts potenziell beliebige von einem Angreifer bereitgestellte Anwendungen ausführen könnte, wenn Sie Docker verwenden, um beispielsweise Bilder auf einen Laptop in einem Café zu laden. Sie könnten möglicherweise auch Zugriff auf Ihr DockerHub-Konto oder andere Registrierungsstellen erhalten, bei denen Sie sich authentifizieren würden.

BEARBEITEN: Link für CVE-Beschreibung hinzufügen: https://groups.google.com/d/msg/docker-user/oYm0i3xShJU/0QbAw9eN9qkJ

Ja, es war falsch zu sagen, dass dies nicht RCE war. Es ist ein schlimmer Fehler und ein großartiger Beweis dafür, warum eine robuste Bildsignierung eine großartige Idee ist. Die Ausbeutung ist jedoch nicht trivial: Es erfordert, dass ein aktiver Angreifer bei Starbucks rumhängt und hofft, dass jemand in der Nähe Docker über unsicheres WLAN nutzt. Dies wird nicht über Nacht zur Waffe gemacht – und verdient daher keine abwärts-inkompatible Änderung ohne Vorwarnung.

Wie oben angedeutet, gab es offensichtliche Möglichkeiten, die Sicherheit sofort zu verbessern, ohne die Kompatibilität zu beeinträchtigen. Beispielsweise hätte das Deaktivieren des HTTPS-Fallbacks für index.docker.io und die Handvoll anderer beliebter öffentlicher Registrierungsstellen das Problem für die meisten Benutzer effektiv gelöst. Das Hinzufügen einer Warnung zur Konsolenausgabe, dass ein HTTP-Fallback aufgetreten ist, hätte den interaktiven Fall gemildert. HTTP-Fallback würde als veraltet markiert und beispielsweise in der Veröffentlichung des nächsten Monats entfernt. Schließlich sind localhost und ::1 offensichtlich nicht angreifbar.

Auch hier hätte ich das Ausmaß der Sicherheitsanfälligkeit nicht außer Acht lassen sollen, aber ich mache mir Sorgen, dass der Reaktionsprozess und die Fehlerbehebung nicht genügend Wert darauf gelegt haben, Kunden nicht zu verletzen.

Wir erstellen/zerstören derzeit Docker-Registrys dynamisch in einer Umgebung, in der für viele dieser Instanzen kein FQDN verfügbar ist. Die Unterstützung der Option --insecure-repository für registrierungsbezogene Anfragen (über Remote-API) würde erhebliche Komplikationen beseitigen, die dieser Sicherheitsfix für uns geschaffen hat.

Wir haben ein ähnliches Problem mit Docker 1.3.1. Wir verwenden die lokale (private) Docker-Registrierung unter der Adresse http://docker :5000/. Bis Docker 1.3.0 funktionierte es einwandfrei. Mit Docker-Version 1.3.1 funktioniert es nicht mehr, da der Docker-Client automatisch davon ausgeht, dass die Registry über HTTPS erreichbar ist. Aber wir verwenden überhaupt kein HTTPS.

Es wäre schön, einen Fallback-Mechanismus zu implementieren, der HTTP verwendet, wenn ein Docker-Registry-Server nicht über HTTPS erreichbar ist.

@kruxik Wenn Sie beim Starten des Daemons --insecure-registry docker:5000 , wird auf HTTP zurückgegriffen.

@tiborvass danke für den Vorschlag. Du hast Recht. Wenn Sie jedoch viele Entwickler mit ihren Workstations und Notebooks haben, ist die Einstellung von --insecure-registry für jede Station unpraktisch. Zumindest als optionaler Parameter für Pull/Push-Operationen wäre es für uns ausreichend ;)

+1

Das hat bei uns mit 1.3.0 funktioniert, aber mit 1.3.1

Docker-Version
....
Serverversion: 1.3.1
....
docker push 10.121.4.236:5000/debian7/consul
-> ....Wenn diese private Registry nur HTTP oder HTTPS mit einem unbekannten CA-Zertifikat unterstützt, fügen Sie bitte --insecure-registry 10.121.4.236:5000 zu den Argumenten des Daemons hinzu. Wenn Sie im Fall von HTTPS Zugriff auf das CA-Zertifikat der Registrierung haben, ist das Flag nicht erforderlich; Platzieren Sie einfach das CA-Zertifikat bei

Herabstufung
Serverversion: 1.3.0
docker push 10.121.4.236:5000/debian7/consul
-> Container-Uploads ohne Probleme.

Für andere, die Probleme mit der 1.3.0 bis 1.3.1 hatten, musste ich die folgenden Änderungen für OS X mit boot2docker vornehmen:

$ boot2docker delete #removes old image
$ rm -f ~/.ssh/id_boot2docker* # remove old keys
$ boot2docker init #generates new keys, cert
$ boot2docker up
$ boot2docker ssh
$ # add EXTRA_ARGS="--insecure-registry <YOUR INSECURE HOST>" 
$ # to /var/lib/boot2docker/profile
$ sudo /etc/init.d/docker restart

dann _sollten_ Sie in der Lage sein, einen Docker-Pull durchzuführen.

Wenn Sie fig verwenden, benötigen Sie auch Abb. 1.0.1 und tun:

$ fig up --allow-insecure-ssl

@mhamrah Danke! Habe Stunden damit verbracht, das zu beheben...

+1 für die Annahme, dass localhost sicher ist. Ist eigentlich jemand dagegen?

Ja, die Annahme, dass localhost sicher ist, würde viel helfen. Ich verwende Vagrant für meine Docker-Box, daher ist es einfach ineffizient, das Init-Skript jedes Mal zu aktualisieren, wenn ich eine Box zerstöre oder aufrufe. Ich denke, ich muss jetzt meine Docker-Box puppen, damit ich die Init auf dem Vagabunden ändern kann.

auch die Verwendung eines --insecure-Flags beim Ziehen und Drücken wäre schön, damit ich bei Bedarf die IP der Vagabunden verwenden könnte.

@thocking : Angenommen, localhost ist sicher: siehe https://github.com/docker/docker/issues/8898

Um ehrlich zu sein, habe ich mich auch gefragt, warum meine automatisierten Jenkins Containerbuilds beim Pushen...
(Gut, eine Testv. zu haben, bevor man es in Produktion nimmt).
Ich muss überprüfen, ob dieses "Feature" wirklich angekündigt wurde - wenn nicht, werde ich bei so extremen massiven Änderungen des Daemons-Verhaltens noch paranoider.

Was ich in dieser Diskussion vermisse:
Warum muss ich dem Daemon überhaupt sagen, dass er für jeden Host den "standardmäßigen" sicheren / unsicheren Modus verwenden soll?

Sollte es nicht produktiver sein, die Registrierung mit diesem Standardverhalten einzurichten?
Wenn also kein Parameter --secure oder --insecure angegeben ist, sollte der Daemon je nach Setup anfordern
wenn sicherer Weg möglich ist und wenn nicht, dass der Fallback auf ungesichert verwendet wurde.

Eines der Hauptmerkmale von Docker ist, dass es völlig einfach zu bedienen ist und eine komplette Umgebung einrichten kann. bitte töte diesen WOW-Effekt nicht mit solchen "Freigaben/Entscheidungen"...

Nur meine 2 Cent...

Ähnliche Probleme hier wie oben, einschließlich @jwthomp. Ich habe gut 10+ Stunden damit verbracht, dieses Problem zu lösen, und habe in der Zwischenzeit auf Docker 1.3.0 zurückgestuft.

Ich führe die Docker-Registrierung unter Marathon aus und die Docker-Registrierung "unterstützt derzeit SSL durch Ausführen von nginx als Frontend" (siehe https://github.com/docker/docker-registry/issues/697 ), aber die Verwendung von nginx als Frontend ist kompliziert, indem Marathon die Docker-Registry auf verschiedenen Slave-Hosts/Ports ausführt.

Ich könnte SSL direkt in der Registrierung aktivieren (mit GUNICORN_OPTS), aber dann spricht es _nur_ SSL und kann die Marathon-Zustandsprüfungen nicht bestehen.

Ich habe das Bamboo HAProxy-Konfigurationssystem geändert, um HAProxy auch als https-Frontend für alle Dienste zu konfigurieren, so wie es nginx gewesen wäre, aber ich habe immer noch Probleme mit der Validierung des Zertifikats durch Docker in meiner privaten Registrierung, also ist das immer noch nicht möglich ich zu dieser Zeit.

Es ist gut, sich gegen RCE zu schützen, aber es muss auch eine gewisse Abwärtskompatibilität gegeben sein. Zumindest ein Flag für den Docker-Daemon, um alle Registrierungen als unsicher anzugeben. Es sollte eine Möglichkeit geben, http oder https als Teil des Registrierungsnamens in jedem Docker-Pull-Befehl anzugeben. Im Moment scheint 1.3.1 ein großer Catch-22 für jeden zu sein, der eine private Registry verwendet.

@mhamrah https://github.com/boot2docker/boot2docker/pull/630

Schön.
Am Freitag, 14. November 2014 um 10:42 Uhr Ilya Radchenko [email protected]
schrieb:

@mhamrah https://github.com/mhamrah boot2docker/boot2docker#630
https://github.com/boot2docker/boot2docker/pull/630

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

@mhamrah Ich musste die ssh-Schlüssel usw. nicht entfernen. Ich habe nur die erforderliche Zeile in /var/lib/boot2docker/profile hinzugefügt und Docker neu gestartet. Danke für den Tipp!

Cool. Ich hatte Probleme, mich reinzuschleichen, ich vermute wegen irgendeiner Version
Nichtübereinstimmung zwischen Docker-ISOs. Ich bin tatsächlich auf Vagabund umgestiegen +
coreos für Docker-Unterstützung, und es funktioniert gut. Sie müssen nur einstellen
DOCKER_HOST, was boot2docker automatisch macht.

Am Do 20 Nov 2014 um 01:52:21 Kayvan Sylvan [email protected]
schrieb:

@mhamrah https://github.com/mhamrah Ich musste nicht entfernen von
die ssh-Schlüssel usw. Ich habe gerade die benötigte Zeile hinzugefügt
/var/lib/boot2docker/profile und Docker neu gestartet. Danke für den Tipp!

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

Sorry Leute, ich wollte früher antworten.

Wie @ewindisch schon sagte, wollen wir dieses clientseitige Verhalten nicht fördern. Der Schmerz, der durch die Anforderung des Flags als Daemon-Flag verursacht wird, besteht darin, dass die Leute tatsächlich TLS in ihrer Registrierung einrichten. Sonst gibt es keinen Anreiz. Danke für dein Verständnis.

Es gibt ein "offizielles" Docker-basiertes Image der Docker-Registry in der offiziellen Docker-Registry. Die empfohlene Verwendung erfolgt ohne TLS.

Wenn Docker möchte, dass Benutzer TLS in ihrer Registrierung einrichten, wäre es dann nicht sinnvoll, die "verursachten Schmerzen" mit einer gleichen und entgegengesetzten "Schmerzreduzierung" auszugleichen, indem ein offizielles Docker-Image bereitgestellt wird, das standardmäßig TLS bereitstellt?

@tiborvass . Sie ignorieren den internen Entwicklungsfall hinter der Firewall. Also muss ich jetzt entweder einen Reverse-Proxy mit aktiviertem SSL vor meiner Registrierung einrichten (es gibt einfach keinen Grund dazu) oder ich muss zu jedem einzelnen meiner Entwickler gehen und die Argumente für den laufenden Daemon ändern innerhalb von boot2docker. Das macht keinen Sinn. Es gibt viele Entwicklungsumgebungen, die konfigurierbare Sicherheit bieten, in denen die Sicherheit oft für Entwicklungsumgebungen deaktiviert ist. Ich bin überrascht, dass Sie dieses Thema schließen, wenn es so viele Stimmen für eine Lösung gegeben hat.

Was ist mit dem Whitelisting aller privaten IPs? Mittelweg?

Oder machen Sie den Protokollnamen 'http' oder 'https' als Teil des Image-Namens für Pull.

@tiborvass sowohl @sroebuck als auch @blevine machen große Punkte. Dies wird zunehmend zum Szenario für Shops, die Container im eigenen Haus bauen, und auch die Wut, den bisherigen Workflow zu durchbrechen, wird zunehmen. Wir alle verstehen die Sicherheitsseite davon, und vielleicht ist Pull nicht der richtige Ort, um es zu beheben, aber solange das offizielle Registry-Image keine einfache, sofort einsatzbereite Möglichkeit bietet, mit dieser Änderung umzugehen, sollte es als ein ziemlich wichtiges UX-Problem angesehen werden, das es zu lösen gilt.

Hallo @tiborvass ! Dieses Thema beißt uns auch gerade. Ich bevorzuge den Ansatz von @nickandrew . Wäre ein bisschen mehr wie git clone und eröffne in Zukunft auch die Möglichkeit verschiedener, steckbarer Protokolle. Ein Gewinn für Docker, da es die Kopplung reduzieren würde und ein Gewinn für die Gemeinschaft.

@blevine Beachten Sie, dass localhost 1.3.2 standardmäßig auf der Whitelist steht, siehe: https://github.com/docker/docker/pull/9124

Sie können die Registrierung auf localhost abhören lassen, indem Sie Folgendes übergeben: -p 127.0.0.0:5000:5000 an docker run

@proppy , ich bin mir nicht ganz sicher, wie mir das Hören auf localhost hilft.

docker pull {http}myregistry.domain.com/myapp:latest

Oder soll es eine tatsächliche URL werden? Ich weiß nichts über das Registrierungsprotokoll, aber es scheint nicht inkompatibel zu sein, die aktuelle Syntax zu erweitern, um eine richtige URL anzugeben.

@blevine bedeutet, dass Sie eine lokale Spiegelungsregistrierung einrichten können.

Arg, jetzt muss ich meine Cloud-Konfiguration für Coreos base64 decodieren, damit meine Maschinen starten

@tiborvass Wow, das ist wirklich schade. :(

Wir haben Entwicklungscluster, die wir im laufenden Betrieb hoch- und herunterfahren, und ein Teil unseres Umgangs mit diesen Clustern besteht darin, eine Registrierung für diesen Cluster zu erstellen. Ein Cluster kann aus vielen physischen Knoten oder VMs bestehen, und er kann sich auch auf einem Desktop-Computer oder Laptop eines Entwicklers befinden (obwohl wir normalerweise keinen vollständigen Stack starten können). Jeder Cluster ist ein vollständig eigenständiger Stack und eine Entwicklungsumgebung. Wir haben auch Docker-basierte Befehlszeilentools, die es einem Entwickler ermöglichen, mit jedem Entwicklungscluster-Setup im Unternehmen zu interagieren.

In solch einer komplexen und dynamischen Umgebung ist es ein Riesenschmerz, TLS in einer Registry zu einer Anforderung zu machen. Es ist ebenso mühsam, den Docker-Daemon-Start jedes Mal ändern zu müssen, wenn wir ein neues Netzwerk hinzufügen, in dem sich eine Registrierung befinden könnte.

Verstehen Sie mich nicht falsch, ich schätze den Gedanken hinter dem Wunsch, ausschließlich TLS zu unterstützen, aber ich ermutige Sie, zu bedenken, dass es gültige Fälle gibt, in denen die Umgebung die Komplexität von TLS sicher beseitigt, um den Aufwand und die Infrastruktur zu reduzieren, die für die Unterstützung erforderlich sind es.

@tiborvass +1. +1000. Dies hat absolut unnötige Komplexität für
uns zu einem hochdynamischen Entwicklungsworkflow. Die Eintrittsbarriere war
hier deutlich angehoben für etwas, das sich nur in a bewerben muss
Produktionskontext bzw. Bitte beenden Sie unseren Schmerz.

Am Dienstag, 9. Dezember 2014, Jeff Thompson [email protected]
schrieb:

@tiborvass https://github.com/tiborvass Wow, das ist einer davon
virtuelle Tischwendemomente leider. :(

Wir haben Entwicklungscluster, die wir im Handumdrehen hoch- und runterfahren und teilen
Wie wir mit diesen Clustern umgehen, besteht darin, eine Registrierung für diesen Cluster zu erstellen. EIN
Cluster können viele physische Knoten oder VMs sein, und er kann sich auch auf einem
Entwickler-Desktop-Computer oder -Laptop (obwohl wir normalerweise kein
voller Stapel). Jeder Cluster ist ein vollständig eigenständiger Stack und Entwicklung
Umgebung. Wir haben auch Docker-basierte Befehlszeilentools, die es ermöglichen,
Entwickler, um mit jedem Entwicklungscluster-Setup im Unternehmen zu interagieren.

In dieser komplexen und dynamischen Umgebung macht TLS eine Registrierung
Voraussetzung ist ein gigantischer Schmerz. Muss den Docker-Daemon-Start ändern
Jedes Mal, wenn wir einrichten, fügen wir ein neues Netzwerk hinzu, in dem sich eine Registrierung befinden könnte
gleichermaßen ein Schmerz.

Versteh mich nicht falsch, ich schätze die Denkweise, die hinter der Unterstützung steht
TLS, es gibt jedoch Fälle, in denen die Umgebung das Entfernen sicher unterstützt
die Komplexität von TLS für die Schmerzreduktion und die erforderliche Infrastruktur
es zu unterstützen.

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

@justinclayton @jwthomp @mattwilliamson @nickandrew @blevine

Löst --insecure-registry 0.0.0.0/8 Ihr Problem nicht? Auf diese Weise können Sie weiterhin HTTP verwenden.

Diese CIDR-Notation kann genauer verwendet werden, um "hinter der Firewall"-Konfigurationen zu ermöglichen, indem Bereiche wie "--insecure-registry 172.16.0.0/12" angegeben werden. Ich rate davon ab, diese Option zu verwenden, aber ich empfehle Benutzern, diese Option zu wählen, um einen selektiveren Bereich (wie ihren IP-Bereich) zu verwenden, anstatt alle Adressen wie möglich mit 0.0.0.0/8 zu verwenden.

Der Docker-Daemon ist in Coreos integriert, also muss ich diese Flags irgendwie zum Start im Cluster hinzufügen. Ich denke, es ist viel flexibler, es im Pull-Befehl für Umgebungen zu verwenden, in denen Sie den Docker-Daemon selbst nicht steuern können.

Dies entspricht der Aufforderung, eine php.ini-Datei für einen gemeinsam genutzten PHP-Host zu ändern.

Am 9. Dezember 2014 um 22:18 Uhr schrieb Tibor Vass [email protected] :

@justinclayton @jwthomp @mattwilliamson @nickandrew @blevine

Löst --insecure-registry 0.0.0.0/8 Ihr Problem nicht? Auf diese Weise können Sie weiterhin HTTP verwenden.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an.

@mattwilliamson Ausführungsflags sind mit CoreOS konfigurierbar. Sie können die systemd-Konfigurationsdatei für Docker bearbeiten. Um dies für einen Cluster zu konfigurieren, können Sie cloud-config verwenden.

Beispiele für das Ändern der Docker-Konfiguration finden Sie auf der CoreOS-Website. Man könnte die Anweisungen leicht ändern, um ein Debug-Flag hinzuzufügen, um stattdessen ein Flag für die unsichere Registrierung anzugeben.

https://coreos.com/docs/launching-containers/building/customizing-docker/

@tiborvass Das gesamte Konfigurations-Ökosystem muss dies unterstützen, damit es @mattwilliamson oben kurz erwähnt hat, unzählige Fälle wie Shared Build-Umgebungen, in denen eine Person, die den Daemon zum Abrufen eines Images verwendet, nicht mit der Person übereinstimmt, die den Daemon konfiguriert.

Die Quintessenz ist, dass dieses Argument auf der Clientseite eindeutig die weniger störende und vor allem die weniger präskriptive Lösung ist. Docker ist in Dutzenden, wenn nicht sogar Hunderten anderer Projekte und Workflows bereits primitiv geworden und sollte als solches wirklich keine Nutzungsmuster in diesem Umfang diktieren. Nur weil Git eine einfache Laufzeitkonfigurationsoption zum Deaktivieren von http.sslverify bietet, heißt das nicht, dass Linus Torvalds die Leute dazu ermutigt, ihre sensiblen Daten nicht in Kontexten zu sichern, in denen dies wichtig ist.

Die Git-Analogie ist ein gutes Beispiel dafür, wie dies funktionieren sollte. Git zwingt Sie nicht zur Verwendung von TLS, und es ist die Entscheidung des Benutzers beim Einrichten eines Hosts, welche Ebene er unterstützen möchte. Es ist auch die Entscheidung des Benutzers, welche Sicherheitsstufe er benötigt (oder umgehen möchte). Die Konfiguration ist ein einfacher Schritt, entweder global oder pro Repository. Obwohl Docker uns nicht zur Verwendung von TLS zwingt, bietet es keine anderen vernünftigen Optionen, indem es die Alternative nicht trivial macht.

Die CIDR-Notation ermöglicht einen wohl "schweren Hammer"-Ansatz, und AFAIK wird nicht auf DNS-Namen abgebildet. t funktioniert. Noch wichtiger ist, dass die Konfiguration nicht trivial ist.

Docker lebt von seiner Einfachheit bei der Containerisierung und senkt die Hürde für die Bereitstellung von Anwendungen in einer Vielzahl von Umgebungen erheblich. Wir alle kennen die Vorteile. Die meisten Entwickler können einfache Fragen zur CIDR-Notation nicht beantworten, die Docker-Konfigurationsdatei kann sich an nicht standardmäßigen Orten befinden (Boot2Docker- und CoreOS-Speicherorte unterscheiden sich von anderen Distributionen), und es ist ziemlich einfach, diese Konfigurationsdateien mit schwierigen Feedbackschleifen zu vermasseln Erfolg. Ich muss Syslog bereinigen? Oh warte, ich bin auf RHEL und es sind Nachrichten?

Ein neuer Entwickler kann leicht ein docker pull Snippet kopieren und einfügen, aber sie per SSH in einen boot2docker-Host einbinden, vi ausführen, eine Konfigurationsdatei bearbeiten und dann ein Syslog auf Fehler überprüfen ... nicht so sehr. Und oh ja, Sie haben vergessen, den Docker-Daemon neu zu starten.

Folgendes möchte ich sehen:

• Docker-Daemon-Einstellungen, die über den Docker-Befehl angewendet werden
• Docker-Pull-Einstellungen für TLS-Überschreibungen, angegeben über den Docker-Befehl
• Docker-Pull-Einstellungen werden befehlsübergreifend für eine bestimmte Registrierung beibehalten

Ja, aber Amazon erlaubt Ihnen nicht, eine Autoscscale-Konfiguration zu ändern. Ich muss eine Kopie davon machen oder eine ganz neue machen.

Am 9. Dezember 2014 um 23:55 Uhr schrieb Eric Windisch [email protected] :

Ausführungsflags sind mit CoreOS konfigurierbar. Sie können die systemd-Konfigurationsdatei für Docker bearbeiten. Um dies für einen Cluster zu konfigurieren, können Sie cloud-config verwenden.

Beispiele für das Ändern der Docker-Konfiguration finden Sie auf der CoreOS-Website. Man könnte die Anweisungen leicht ändern, um ein Debug-Flag hinzuzufügen, um stattdessen ein Flag für die unsichere Registrierung anzugeben.

https://coreos.com/docs/launching-containers/building/customizing-docker/

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an.

Ich muss dieses Problem derzeit in der Entwicklungsumgebung meines Unternehmens umgehen, indem ich diesen sorgfältig recherchierten Befehl jedes Mal ausführe, wenn ich "boot2docker up" mache.

boot2docker ssh 'sudo sh -c "echo \"EXTRA_ARGS=\\\"--insecure-registry 10.0.0.0/8\\\"\" > /var/lib/boot2docker/profile && sudo /etc/init.d/docker restart"'

Was für ein Schmerz. Die Übernahme von Docker in meinem Unternehmen mit mehr als 400 Mitarbeitern ist aufgrund dieses Problems ins Stocken geraten. Wir haben absolut keine Verwendung für TLS in unserer internen Entwicklungsumgebung, in der alles kontrolliert wird. Wir begrüßen seine Verwendung für öffentliche Hub-Repositories und halten es in jedem Fall für einen großen Fehler, dies an anderer Stelle zu erzwingen.

@CleanCut sehr gut formuliert. War wirklich enttäuscht, dass 1.4.0 kam und ging und dieses Problem offen bleibt.

@CleanCut genial - Was ich in boot2docker gerne hätte, ist, dass es mehr Informationen zur anfänglichen Nutzlast von boot2docker init hinzufügt, die dies dann für Sie erledigen würde.

löst nicht die nicht-VM-based-boot2docker-spezifischen Probleme, aber --insecure-registry ist nicht die einzige Site-spezifische Anpassung, die b2d-Benutzer wünschen.

Kannst du dafür bitte einen Pull Request oder Issue im boo2docker Repo machen?

Erhöht wirklich die Barriere für jemanden, ein Projekt zu nutzen, das für den Abbau von Barrieren gelobt wird.

Am 13. Dezember 2014 um 02:10 Uhr schrieb Justin Clayton [email protected] :

@CleanCut sehr gut formuliert. War wirklich enttäuscht, dass 1.4.0 kam und ging und dieses Problem offen bleibt.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an.

@SvenDowideit Klar. Hier ist es

Es hört sich so an, als ob es in diesem Thread Konsens gibt, dass dies kein gelöstes Problem ist; Könnten wir dieses Problem bitte wieder öffnen?

Ja bitte!
Le 2014-12-15 15:05, "Justin Clayton" [email protected] a écrit :

Es hört sich so an, als ob es in diesem Thread Konsens gibt, dass dies nicht gelöst ist
Problem; Könnten wir dieses Problem bitte wieder öffnen?

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

+1. Ich habe nichts hinzuzufügen, möchte aber einfach meinem Frust über diese Entscheidung Luft machen. Wie alle anderen betreibe ich eine Registry in einem lokalen Netzwerk, in der die Sicherheit an anderer Stelle bis zum Überdruss gehandhabt wird. Ich habe Dutzende von Docker-Containern in Betrieb, die jetzt gebounct werden müssen, um das Flag "gut dokumentiert" hinzuzufügen.

@bfirsh - dies ist eines dieser Beispiele, bei denen eine Docker-Daemon-Konfigurationsdatei und ein kill -HUP <dockerdaemonpid> großartig wären - veranlassen Sie es, die cfg erneut zu lesen, ohne sie neu starten zu müssen - und vermeiden Sie so den Container-Neustart

@SvenDowideit +1 für die Reload-Funktion, es ist wirklich ärgerlich, den Server durch einfache Konfiguration neu zu starten.

+1

Verzeihen Sie mir, wenn ich die Dinge nicht richtig verstehe, aber es scheint, als ob dieses Problem an der Wurzel meines eigenen Szenarios liegt (ähnlich dem von @blevine beschriebenen, bei dem mein Unternehmen über einen Proxy zum Umschreiben von Zertifikaten verfügt, der dazu führt, dass ich nicht in der Lage

http://stackoverflow.com/questions/27536180/docker-on-mac-behind-proxy-that-changes-ssl-certificate

+1, um diese Diskussion wieder zu eröffnen, da die Community mit der aktuellen Lösung anscheinend nicht wirklich zufrieden ist.

https://twitter.com/justinclayton42/status/550143834705780737

Ich versuche nur, dies aus allen Blickwinkeln zu treffen, bis wir eine endgültige Antwort zu diesem Thema hören.

+1, dies ist derzeit schwer zu konfigurieren und zu funktionieren.

@mhamrah macht große Punkte. Erzwingen Sie nichts, lassen Sie die Benutzer nach ihren eigenen Bedürfnissen entscheiden und konfigurieren.

Auch Registrierungen, die selbstsignierte Zertifikate verwenden, sind ein Problem, insbesondere
in einem Entwicklerkontext mit boot2docker, der zu einer schreibgeschützten Datei gewechselt hat
System. Dies erfordert einen zusätzlichen und anderen Konfigurationsschritt, um
Bootstrap der laufenden VM.

Ich glaube, jeder, der in diesem Thread gepostet hat, sieht den Wert und Nutzen
von Docker, verwenden es täglich, versuchen es in ihren
Organisationen, haben aber ein schmerzliches und unnötiges Problem, das
behindert die Annahme.

So viel wir alle wissen, ist Docker vielen Technikern noch unbekannt.
vor allem innerhalb des Unternehmens. Dokumentation hilft, aber wir sind es trotzdem
durch Reifen springen, und es ist ein großer Blocker mit einem negativen Overall
Wirkung.
Am Sonntag, 25. Januar 2015 um 17:54 Uhr schrieb Jay Taylor [email protected] :

+1, dies ist derzeit schwer zu konfigurieren und zu funktionieren.

@mhamrah https://github.com/mhamrah macht große Punkte. Nicht erzwingen
Dinge, lassen Sie die Benutzer entscheiden und für ihre eigenen Bedürfnisse konfigurieren.

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

+1 gut um schnell Dinge auszuprobieren

:+1:

:+1:

Super enttäuschend, dass wir immer noch nicht aus unsicheren Registern ziehen können, ohne eine Flagge an den Docker-Daemon zu übergeben. Dies ist nur ein weiterer Ärger für jede neue Maschine, die wir bereitstellen.

+1

Einige Gedanken:

1. Könnten wir Hostnamen-Wildcards haben? zB --insecure-registry=*.internal
2. Könnten selbstsignierte Zertifikate anders behandelt werden als http?
3. in Bezug auf 2, könnte Docker etwas Ähnliches wie SSH tun und den Benutzer auffordern, ein selbstsigniertes Zertifikat zu akzeptieren, wenn es ein neues sieht, / sich laut zu beschweren, wenn es ein nicht übereinstimmendes Zertifikat gibt?

Und während ich Vorschläge mache, warum behandeln Sie localhost nicht als immer sicher? (wie Chrome)

Edit: ah, ich sehe es schon.

+1000 auf dies.. und +1 auf die Funktion zum erneuten Laden der Konfiguration, das macht dies doppelt so schlimm. Ich bin bei v1.2 geblieben, weil ich dachte, dass ein Betreuer sicherlich erkennen würde, wie ärgerlich das --insecure-registry-Flag auf dem Daemon für die Bereitstellung ist, und es beheben, aber irgendwie ignorieren die Nebenversionen es weiterhin.

Wenn ich beispielsweise meine private Registrierungs-IP aus irgendeinem Grund ändern müsste, müsste ich jeden einzelnen Docker-Daemon auf jeder VM neu starten – nur weil sich meine Registrierung geändert hat!? Diese 2 Dinge sollten nie so eng verbunden werden. Und den Leuten zu sagen, sie sollen nur 0.0.0.0/8 hinzufügen, macht den ganzen Zweck der Sicherheitsimplementierung von vornherein zunichte.

Das Hinzufügen dieses Flags zu den Push/Pull-Befehlen scheint als Fallback für das Daemon-Flag so offensichtlich zu sein. Bitte erklärt mir jemand, warum sie immer noch dagegen kämpfen, aber in der Zwischenzeit "nice to have" -Funktionen hinzufügen.

Der Kommentar von

Da dies für eine beträchtliche Anzahl von Benutzern ein anhaltender Schmerz ist, erwägen wir, --insecure zu pull hinzuzufügen. @ewindisch und ich werden an einer PR arbeiten, die wir zu dieser Ausgabe verlinken.

Entschuldigung für die lange Wartezeit und vielen Dank, dass Sie Ihre Meinung geäußert und auf Ihre Schwachstellen hingewiesen haben.

@tiborvass Ich kann mir vorstellen, dass es eine ebenso große Anzahl von Benutzern gibt, die Pulls aus unsicheren Registrierungen _nicht_ zulassen möchten. Mir ist klar, dass Docker derzeit keine fein abgestimmte Kontrolle über Berechtigungen / Konfigurationen hat, aber wenn es die Möglichkeit gibt, dies "sperren" zu können, wäre das meiner Meinung nach eine nette Geste.

Oh mein, mach es so! Wollte es selbst umsetzen.

Gesendet von meinem BlackBerry 10-Smartphone im Bell-Netzwerk.
Von: Sebastian van Stijn
Gesendet: Montag, 23. Februar 2015 16:53 Uhr
An: Docker/Docker
Antwort an: docker/docker
Cc: Kristopher Cieplak
Betreff: Re: [docker] --insecure-registry sollte auf "docker pull" stehen (#8887)

@tibor vasshttps://github.com/tiborvass Ich kann mir vorstellen, dass es eine ebenso große Anzahl von Benutzern gibt, die Pulls aus unsicheren Registrierungen nicht zulassen möchten. Mir ist klar, dass Docker derzeit keine fein abgestimmte Kontrolle über Berechtigungen / Konfigurationen hat, aber wenn es die Möglichkeit gibt, dies "sperren" zu können, wäre das meiner Meinung nach eine nette Geste.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf Gi tHub anhttps://github.com/docker/docker/issues/8887#issuecomment -75644600.

@thaJeztah Ich versuche herauszufinden, an welchen Anwendungsfall Sie denken, der bedeutet, dass wir kein --insecure-registry Flag für docker pull .

• Wenn ein Benutzer nicht versehentlich MITMed in einer sicheren Registrierung sein möchte, kann er einfach vermeiden, --insecure-registry passieren
• Wenn ein Benutzer den Benutzern durchsetzen möchte, dass alle Bilder aus sicheren Registern stammen (dh ein 'Unternehmen'-Szenario), kann er dies im Moment sowieso überhaupt nicht durchsetzen!

Könnten Sie also näher erläutern, was docker pull --insecure-registry hemmt?

Um auf meinen zweiten Punkt einzugehen, ich kann nicht sehen, wie Sie dies sperren würden, ohne die Funktionsweise von Docker erheblich zu überdenken! Abgesehen davon, dass Sie docker load einen Tarball erstellen können, den Sie erhalten könnten, indem Sie Ihren eigenen Registry-Puller schreiben und docker run -v , um privs zu eskalieren und etwas zu den Daemon-Argumenten hinzuzufügen, gibt es eine sehr einfache Möglichkeit, alle zu umgehen 'Durchsetzung':

$ docker pull registry:5000/aidanhs/blah                                    
FATA[0004] Error: v1 ping attempt failed with error: Get https://registry:5000/v1/_ping: EOF. If this private registry supports only HTTP or HTTPS [...]
$ socat tcp4-listen:5000,reuseaddr,fork tcp4:registry:5000 &
[1] 22924
$ docker pull localhost:5000/aidanhs/blah
Pulling repository localhost:5000/aidanhs/blah
[...]
Status: Image is up to date for localhost:5000/aidanhs/blah:latest
$ docker tag localhost:5000/aidanhs/blah registry:5000/aidanhs/blah

Wenn ein Benutzer den Benutzern durchsetzen möchte, dass alle Bilder aus sicheren Registern stammen (dh ein 'Unternehmen'-Szenario), kann er dies im Moment sowieso überhaupt nicht durchsetzen!

Das ist das Szenario, ja.

Um auf meinen zweiten Punkt einzugehen, ich kann nicht sehen, wie Sie dies sperren würden, ohne die Funktionsweise von Docker erheblich zu überdenken

Ich verstehe voll und ganz, dass es (im Moment) keine Möglichkeit gibt, es zu sperren. Benutzer, die Zugriff auf docker.sock haben, haben effektiv Root-Zugriff, können also alles ändern, was sie wollen. Außerdem wären sie immer noch in der Lage, das Daemon-Flag zu ändern und den Daemon neu zu starten.

Es _gibt_ dem Benutzer jedoch ein klares Signal, wenn docker pull --insecure-registry .. einen Fehler ausgibt ("Unsichere Registrierungen sind deaktiviert"), der den Benutzer _benachrichtigen würde, dass dies nicht erwünscht ist, zum Beispiel beim Ausprobieren eines gefundenen Beispiels irgendwo.

Würde es also alle Fälle abdecken? Nein. Würde es _verletzen_, glaube ich auch nicht.

Ich persönlich denke, es würde mehr schaden als nützen, einfach weil es die Leute in die Irre führt zu denken "Oh, schau, Docker erzwingt das", obwohl es eigentlich ein sehr oberflächlicher Schutz ist. Ich könnte weitermachen, aber am Ende denke ich, es ist Geschmackssache.

Wenn Sie wissen, wie es weh tun könnte, scrollen Sie einfach nach oben. Es gibt unzählige UX-Probleme bei diesem Ansatz, die Hindernisse für die Akzeptanz schaffen, und sie sind alle oben beschrieben.

Ich sehe die Probleme hauptsächlich mit Docker, der nicht neu gestartet werden kann, ohne den Sub zu töten
Behälter. die die Konfiguration/Neukonfiguration erschweren.

Am Mittwoch, 15. April 2015 um 20:11 Uhr, Jan Krueger [email protected]
schrieb:

+1

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

Ich bin ziemlich enttäuscht, dass zu diesem Thema noch keine Maßnahmen ergriffen wurden. Es verursacht offensichtlich einer Reihe von Menschen Schmerzen.

Es ist offensichtlich für viele Leute ärgerlich, es blockiert gerade aktiv meine Arbeit. Dass Sie den Docker-Daemon neu starten müssen, um das Ziehen aus einer unsicheren Registrierung zu ermöglichen, reicht von nervig bis schlichtweg unmöglich, je nachdem, in welcher Situation Sie sich befinden.

Das Hauptargument dafür, dies nicht zu tun, scheint zu sein, dass der Systemadministrator in der Lage sein sollte, das System zu sperren und sicherzustellen, dass nur Images aus sicheren Repos abgerufen werden können. Dieser Anwendungsfall ist definitiv real, aber ich denke, es ist ein schlechter Standard. Es scheint viel vernünftiger zu sein, ein Flag zu haben, das beim Start an den Daemon übergeben werden kann, wie --no-insecure das die Verwendung von --insecure-registry in pull deaktiviert. Auf diese Weise kann ein Admin die Dinge sperren, wenn er/sie es wirklich möchte.

Für diejenigen, die dieses Verhalten stark wünschen, biete ich die folgende Problemumgehung an. Ich verstehe, dass es nicht für alle Benutzer geeignet sein wird, da es die Docker-API nicht für Pulls verwendet. Es ist auch etwas langsam...

Siehe mein Projekt 'docker-pull': https://github.com/ewindisch/docker-pull

Sie würden es so verwenden:

docker run ewindisch/docker-pull --insecure-registry 10.0.0.0/16 10.0.1.2/someimage | docker load

Es ist auch möglich, alle Registrierungen als unsicher zuzulassen:

docker run ewindisch/docker-pull --insecure 10.0.1.2/someimage | docker load

Ich erinnere daran, dass es _noch_ sehr schlecht beraten ist, dies tatsächlich zu tun.

@ewindisch raffinierter Hack.

Eine andere ziemlich gute Lösung ist die Verwendung eines TCP-Tunnels:

$ docker pull host:5000/image #fails
$ ssh -N -L 5000:host:5000 user<strong i="8">@host</strong>
$ docker pull localhost:5000/image #works

Das sind beides fantastische Workarounds!

Ich würde auch gerne die Standardeinstellung umgekehrt sehen.

Am 15. April 2015 um 18:14 Uhr schrieb Joe Doliner [email protected] :

Ich bin ziemlich enttäuscht, dass zu diesem Thema noch keine Maßnahmen ergriffen wurden. Es verursacht offensichtlich einer Reihe von Menschen Schmerzen.

Es ist offensichtlich für viele Leute ärgerlich, es blockiert gerade aktiv meine Arbeit. Dass Sie den Docker-Daemon neu starten müssen, um das Ziehen aus einer unsicheren Registrierung zu ermöglichen, reicht von nervig bis schlichtweg unmöglich, je nachdem, in welcher Situation Sie sich befinden.

Das Hauptargument dafür, dies nicht zu tun, scheint zu sein, dass der Systemadministrator in der Lage sein sollte, das System zu sperren und sicherzustellen, dass nur Images aus sicheren Repos abgerufen werden können. Dieser Anwendungsfall ist definitiv real, aber ich denke, es ist ein schlechter Standard. Es scheint viel vernünftiger zu sein, ein Flag zu haben, das beim Start an den Daemon übergeben werden kann, wie --no-insecure, das die Verwendung von --insecure-registry im Pull deaktiviert. Auf diese Weise kann ein Admin die Dinge sperren, wenn er/sie es wirklich möchte.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an.

also das ist wieder geöffnet und der aktuelle Stand nach 4 Monaten ist nichts und als Workaround ein paar Hacks verwenden? :-/ Wird darüber anderswo diskutiert oder ist es einfach tot?

Und ja, +1

+1

+1

Ich möchte darauf hinweisen, dass ich die Instanzen von "+1" auf dieser Seite gezählt habe und die Zahl bisher 31 beträgt. Das zählt nicht die anderen unterstützenden Kommentare, die nicht genau diese Zeichenfolge enthalten.

Das Problem dabei ist, dass das Aktivieren von --insecure beim Pull dem Systemadministrator die Kontrolle entzieht, wo sie hingehört.
Sicherheit ist schwer, und Änderungen zur Lockerung der Sicherheit sind keine leichte Entscheidung.
Außerdem werden Leute, die mit dem aktuellen Setup vollkommen zufrieden sind, nicht hierher kommen und auch hier -1 .
Auf der anderen Seite...
Es ist trivial, den Daemon neu zu konfigurieren, um unsichere Pulls aus einer Registry zu ermöglichen.
Es ist auch trivial, einige selbstsignierte Zertifikate einzurichten und nicht einmal Docker neu konfigurieren zu müssen.

"Sysadmin" ist ein Anwendungsfall für Docker, aber ich "Entwickler" und "Nicht-Systemadministrator" sind gleichermaßen gültige Anwendungsfälle. Für einen Entwickler verringert die Bereitstellung einer Option --insecure die Reibung im Workflow.

Vielleicht könnten wir das Beste aus beiden Welten haben, indem wir eine Option bereitstellen, die Systemadministratoren angeben können, um die Verwendung einer Option --insecure zu _verweigern_. Auf diese Weise haben Systemadministratoren immer noch die volle Kontrolle, aber Fälle, die keine Systemadministratoren sind, müssen sich nicht mit den Workflow-Problemen auseinandersetzen.

Was für einen Systemadministrator trivial ist, kann für Nicht-Systemadministratoren überraschend umständlich sein. Ich musste fast zwei Dutzend Entwicklern helfen, diese Konfigurationsänderung für 5 verschiedene Betriebssysteme, die in unserer Entwicklungsgruppe verwendet werden, vorzunehmen (und erneut vorzunehmen). Ich pflege tatsächlich ein Skript, um die Konfigurationsänderung für unsere Umgebungen zu automatisieren.

Unsere Systemadministratoren werden derzeit keine selbstsignierten Zertifikate für unsere Registrierung einrichten, egal ob dies trivial ist oder nicht.

Wie auch immer, selbst wenn sich das nicht ändert, werden sich die Leute irgendwann daran anpassen. Ich nehme an, dass die Schmerzen, mit denen ich zu tun habe, verschwinden werden, wenn unsere Systemadministratoren das nächste Mal Wartungsarbeiten an der Registrierung durchführen, da wir zu diesem Zeitpunkt in der Lage sein sollten, echte SSL-Zertifikate zu installieren. Vielleicht ist das der springende Punkt. Machen Sie es einfacher, den sicheren Weg zu gehen als den unsicheren Weg.

:+1: @CleanCut und alle anderen haben alles gesagt. Ich arbeite nur mit dem Entwicklerfall und das Umkonfigurieren des Docker-Daemons ist für uns nur Zeitverschwendung.

Wenn Sie heute Zugriff auf den Docker-Socket haben, _sind_ Sie ein Systemadministrator. Du bist
root bereits, Sie haben "Docker Load" und haben bereits Workarounds zu tun
unsichere Registry-Pulls. Das Hinzufügen der Bildoption zum Client wäre nicht
weniger sicher als der Status quo.

Es gibt jedoch etwas zu sagen über die absichtliche Erhöhung der
Reibung für Entwickler, die versuchen, das Falsche zu tun, um andere zu verführen
sie dazu, das Richtige zu tun.
Am 18. Juni 2015 um 12:41 Uhr schrieb "Brian Goff" [email protected] :

Das Problem hier ist, dass das Aktivieren von --unsicher beim Ziehen die Kontrolle wegnimmt
vom Systemadministrator, wo es hingehört.
Sicherheit ist schwer, und Änderungen zur Lockerung der Sicherheit sind keine Kleinigkeit
Entscheidung.
Auch Leute, die mit dem aktuellen Setup vollkommen zufrieden sind, gehen nicht hin
hier zu kommen und -1 dies entweder.
Auf der anderen Seite...
Es ist trivial, den Daemon neu zu konfigurieren, um unsichere Pulls von a . zu ermöglichen
Registrierung.
Es ist auch trivial, einige selbstsignierte Zertifikate einzurichten und nicht einmal zu müssen
Docker neu konfigurieren.

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

@ewindisch @tiborvass beim Zurücklesen sehe ich https://github.com/docker/docker/issues/8887#issuecomment -75638745;

Da dies für eine beträchtliche Anzahl von Benutzern ein anhaltender Schmerz ist, erwägen wir das Hinzufügen von --insecure to pull. @ewindisch und ich werden an einer PR arbeiten, die wir zu dieser Ausgabe verlinken.
Entschuldigung für die lange Wartezeit und vielen Dank, dass Sie Ihre Meinung geäußert und auf Ihre Schwachstellen hingewiesen haben.

Ist das noch die aktuelle Position? (Ich glaube nicht, dass eine PR erstellt wurde)

+1

Das stört und nervt mich täglich.

:( trauriger Kegelkopf.

--incure macht aus einem Entwickler-POV durchaus Sinn. Es liegt an der Person, die Docker in ihrer Umgebung implementiert, um es sicher zu machen.

+1

:+1:

_BENUTZER-UMFRAGE_

_Der beste Weg, um über Änderungen in dieser Diskussion benachrichtigt zu werden, besteht darin, oben rechts auf die Schaltfläche Abonnieren zu klicken._

Die unten aufgeführten Personen haben Ihre aussagekräftige Diskussion mit einem zufälligen +1 gewürdigt:

@justinclayton
@anandkumarpatel
@tangr1
@fred4jupiter
@mingfang
@djannot
@Frusty
@tobegit3hub
@testaccountspivey
@mhamrah
@mwhooker
@ryan-stateless
@jonathanvaughn
@gollawil
@ebartz
@maelp

+1

+1

+1

Wir verwenden eine interne Registry in einem geschlossenen Netzwerk, was uns die Bereitstellung erleichtern würde.

+1

Wenn dieses Thema bis Halloween noch offen ist, denke ich, dass alle +1 eine einjährige Jubiläumsparty zum Ertrinken in unseren Docker-Sorgen veranstalten sollten.

+1 für die Trauerfeier!

Am 14. September 2015 um 13:32 schrieb Gordon [email protected] :

BENUTZERUMFRAGE

Der beste Weg, um über Änderungen in dieser Diskussion benachrichtigt zu werden, besteht darin, oben rechts auf die Schaltfläche Abonnieren zu klicken.

Die unten aufgeführten Personen haben Ihre aussagekräftige Diskussion mit einem zufälligen +1 gewürdigt:

@justinclayton
@anandkumarpatel
@tangr1
@fred4jupiter
@mingfang
@djannot
@Frusty
@tobegit3hub
@testaccountspivey
@mhamrah
@mwhooker
@ryan-stateless
@jonathanvaughn
@gollawil
@ebartz
@maelp

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an.

+1

+1 für die Trauerfeier

Sehr geehrter Besitzer des Bots, der die Leute auffordert, "+1" nicht mehr zu verwenden:
Wir verwenden +1, um das Problem zu lösen, und mehr gibt es nicht zu sagen.

+1

+1

Es gibt einige Problemumgehungen, einschließlich der Verwendung von SSH-Tunneln – aber dafür sind SSH-Konten auf dem Registrierungshost erforderlich. Der folgende Workaround, braucht das nicht.

Führen Sie die Portweiterleitung der Registrierung wie folgt aus:

docker run --name registry_forwarder -d -p 5000:5000 -e REGISTRY_HOST="<registry_host_ip>" -e REGISTRY_PORT="5000" rsmoorthy/registry-forwarder

Und ziehen oder pushen Sie dann Bilder aus Ihrer lokalen Registrierung:

docker pull localhost:5000/your-image
docker push localhost:5000/my-image

@rsmoorthy Das ist fantastisch. Vielen Dank, dass Sie kurz und bündig die Sinnlosigkeit dieser aktuellen Einschränkung aufgezeigt haben.

Docker, bitte fügen Sie diesen speziellen Akku wieder ein.

+1

Ich muss sagen, dass die energische Förderung der Sicherheit des Benutzers meine Gedanken über die Verwendung von Docker ernsthaft beeinflusst hat. Ich verstehe vollkommen, dass wir dem Daemon beim Start das Flag --insecure-registry hinzufügen können, und ich werde nicht auf alle Gründe eingehen, die nicht immer funktionieren oder unmöglich sein können.

Ich habe eine Frage an die Docker-Entwickler, glaubst du wirklich, dass du weißt, was das Beste für den Endbenutzer ist? Ich für meinen Teil benötige überhaupt kein SSL für meine Registrierungen, da das Netzwerk, auf dem sie laufen, bereits vollständig verschlüsselt ist. Warum um alles in der Welt sollte ich verschlüsselten Datenverkehr verschlüsseln, bringt dies wirklich etwas anderes als das Hinzufügen von Overhead und das Verschieben von Teilen zu einem bereits komplexen und massiven System?

Gibt es auch wirklich Anwendungsfälle, in denen Menschen eine private Registrierung über das Internet verwenden? Was macht man in diesem Sinne mit der Authentifizierung? Könnte man nicht einfach ein Bild herunterziehen und es dann zerreißen? Anstatt zu versuchen, es auf dem Weg zu einem anderen Computer abzufangen?

TL;DR +1

+1

@Supernomad gut gesagt.

Sehen Sie es von Docker-Seite aus: Es ist ein Problem, das besser nie offiziell implementiert wird, sondern mit vielen möglichen Problemumgehungen, um den Schmerz zu lindern. Einige Benutzer, die laut schreien, sind immer noch weniger schmerzhaft als das Marketing, das Docker der Konkurrenz als "absichtlich unsicher" bezeichnet und ihrem Ruf für immer schadet.
Wie gesagt, +1.

@tiborvass @ewindisch Diese Ausgabe ist über ein Jahr alt. Es ist über 8 Monate her, seit Sie sagten, es solle neu bewertet werden. Hast du es ausgewertet? Wenn ja, was wurde beschlossen? Lass einen Bruder nicht hängen! :-)

Da dieses Problem ursprünglich geöffnet und geschlossen und wieder geöffnet wurde, hat sich die Community zahlreiche Möglichkeiten einfallen lassen, dies selbst zu beheben, hauptsächlich um die Sinnlosigkeit dieser Standardeinstellung zu demonstrieren:

• ssh -N -L 5000:host:5000 user<strong i="10">@host</strong> && docker pull localhost:5000/lolsecurity
• socat tcp4-listen:5000,reuseaddr,fork tcp4:registry:5000 && docker pull localhost:5000/lolsecurity
• docker-machine create -d virtualbox --engine-insecure-registry 0.0.0.0/0 lolsecurity
• docker run --name registry_forwarder -d -p 5000:5000 -e REGISTRY_HOST="<registry_host_ip>" -e REGISTRY_PORT="5000" rsmoorthy/registry-forwarder && docker pull localhost:5000/lolsecurity

Ganz zu schweigen davon, dass CoreOS jetzt standardmäßig mit --insecure-registry 0.0.0.0/0 . Diese Beispiele zeigen deutlich, dass die Idee, dass es zwischen dem "Systemadministrator" und dem "Entwickler" Trennungslinien gibt, im Jahr 2015 weitgehend willkürlich und falsch ist. Tatsächlich ist die Idee von Containern (deren Chef Docker ist) Evangelist) hat diesen Trend weg von den traditionellen Operationen, die sich immer noch die Mühe machen, jeden "Systemadministrator" zu nennen, stark beschleunigt.

Wie auch immer, ich würde gerne sehen, dass dies auf die eine oder andere Weise endgültig geschlossen wird.

+1

+1

+1

Warum sollte ich Docker Registry meinen privaten SSL-Schlüssel anvertrauen?

Für die anderen CoreOS-Benutzer, die durch diese Einmischung zum Trocknen ausgelassen wurden,
https://coreos.com/os/docs/latest/registry-authentication.html#using -a-registry-without-ssl-configured

@politician hätte es selbst nicht besser sagen können. Es scheint definitiv so, als würde Docker einfach die Tatsache ignorieren, dass ein großer Teil seiner Benutzer zumindest unzufrieden ist.

Tatsache ist, dass ich gerade dabei bin, komplett von Docker wegzukommen, und ich könnte mit dieser Entscheidung nicht glücklicher sein. Ich verwende derzeit git und lxc und es ist nicht nur schneller als Docker, sondern ermöglicht es mir auch, das Beste für mein Unternehmen zu tun und nicht das, was ein anderes Unternehmen, wenn auch völlig falsch, für das Beste für mich hält.

Ich empfehle dringend, einen Blick auf die Alternativen zu werfen, die ehrlich gesagt besser sind als Docker, wie z. B. rocket, raw lxc, qemu (nicht gleich, aber immer noch besser), um nur einige zu nennen.

Ich werde diese Vorgehensweise allen, die ich kenne, die Container in Betracht ziehen, nachdrücklich vorschlagen. Zumindest so lange, bis die Leute bei docker feststellen, dass sie keine Ahnung haben, und ich betone _absolut_ keine Ahnung, was für den Endbenutzer in Bezug auf Sicherheit am besten ist.

Ich gab auf und kaufte ein billiges dediziertes SSL-Zertifikat. Die Docker-CLI-Abhängigkeit vom CA-System ist einfach zu stark - selbstsignierte Zertifikate sind nicht nur betriebsfrustrierend, sie funktionieren einfach nicht.

• docker-machine löscht deine ca.crt-Überschreibung zwischen down/up
• Keines Ihrer Basis-Images enthält die Tools zur Zertifizierung von Zertifikaten wie Drohnen für CI unmöglich
• docker CLI verwendet einen nicht standardmäßigen Ordner für Zertifikate, das ist also nur etwas anderes, an das Sie sich erinnern sollten.
• selbst wenn du es 18 Stunden später zum Laufen bringst, wirst du immer das nagende Gefühl haben, dass noch etwas kaputt ist

Fazit: Docker fügt Ihrem Operations-Team eine dauerhafte Strafe zu, wenn es versucht, ein selbstsigniertes Zertifikat zu verwenden.

Das ist umso frustrierender, da curl -k schon seit Ewigkeiten existiert.

+1

Es ist ziemlich traurig, dass ihnen das egal ist. Wenn ein Entwickler nur mit Docker herumfummeln und seine eigene Umgebung hosten möchte, möchten Sie normalerweise nicht mit SSL-Zertifikaten und so herumspielen. Wenn Sie zu Hause einen eigenen Server haben, der nicht annähernd öffentlich ist, benötigen Sie einfach kein SSL.

@buehler Sie können die Option --insecure-registry zu den Einstellungen Ihres Daemons oder zu Ihrer Konfigurationsdatei daemon.json hinzufügen ; dann müssen Sie es nur einmal konfigurieren und ziehen, ohne das Flag angeben zu müssen

Nur ein Update von uns: Seitdem haben wir Registry aus unserer Infrastruktur entfernt und wieder

@buehler nur um @thaJeztahs Vorschlag zu konkretisieren, fügen Sie diese Zeile zur Konfiguration hinzu:

--insecure-registry 0.0.0.0/0

Sie können auf jede beliebige Registrierung zugreifen. Funktioniert gut zum Testen von Sachen.

@politician die Duplizierung tritt auf, wenn die Bilder mit verschiedenen Repositorys gekennzeichnet sind. Das Fehlen des Löschens von Blobs ist ein wesentlich größeres Problem.

@thaJeztah Wenn es so einfach ist, aber 80% (zugegebenermaßen eine beliebige Anzahl) der Benutzer müssen es tun, dann machen Sie es bitte einfach zum Standard.

@justinclayton nein; Wenn Sie diese Option einstellen, heißt es im Grunde "Ignoriere alle Probleme mit der sicheren Kommunikation mit der Registrierung", also erlauben Sie Man-in-the-Middle-Angriffe "out of the box" oder sogar den Daemon, der auf Nicht-TLS "http://" zurückgreift. . Docker hat es _does_ bereits als Standard für Registrierungen im Bereich 127.x.x.x .

Wenn Sie eine lokale Registrierung haben und kein Zertifikat dafür generieren möchten, dauert das Hinzufügen eines --insecure-registry zu Ihren Daemon-Optionen weniger als eine Minute. Es sollte jedoch eine absichtliche Aktion sein, nicht etwas, das standardmäßig festgelegt ist.

@thaJeztah Ich verstehe Ihre Argumentation, aber das kann nicht nur das Ende sein. Es gibt eine erhebliche Lücke in der Benutzererfahrung für neue Entwickler, da dies auf der Daemon-Seite stattfindet. Das _majority_-Szenario, in dem dies ein Problem ist, ist ein neuer Entwickler, der den Anweisungen auf docker.com folgt, um das Docker Toolbox-Installationsprogramm herunterzuladen und auf seinem Mac auszuführen. Nach Abschluss versuchen sie sofort, docker pull <internally-signed-registry>/foo auszuführen und werden mit einem Fehler begrüßt. Dies ist das wahre Problem. Vielleicht bedeutet das, dass dieses Problem umbenannt werden sollte?

Es gibt viele andere Möglichkeiten, für die dies ebenfalls gelöst werden könnte; Ich bin sicher, die Community und das Unternehmen könnten sich auf einen davon einigen:

• Der aktuelle Name dieses Problems lautet '--insecure-registry sollte auf "docker pull" stehen'. Da dieses Thema noch offen ist, muss ich davon ausgehen, dass diese Option noch in Betracht gezogen wird.
• Wenn eine Ein-Befehls-Lösung dafür bereitgestellt (und dokumentiert) würde, die für Anfänger einfach ist, würde dies dies lösen.
• In unserem Fall _ist_ die Registrierung gesichert. Es verwendet ein von unserer internen Zertifizierungsstelle signiertes Zertifikat wie alles andere in unserer Build-Umgebung. Dies ist eine ausreichende Sicherheit. Wenn der Daemon irgendwie in der Lage wäre, den Zertifikatsspeicher von MacOS zu respektieren, würden auch diese Kopfschmerzen verschwinden.
• Wenn sie während des Installationsprozesses der Toolbox aufgefordert würden, das Zertifikat hinzuzufügen oder diese Konfiguration auf dem Docker-Computer vorzunehmen, wäre das wahrscheinlich auch in Ordnung.

Bitte teilen Sie den über 70 Teilnehmern dieser Ausgabe mit, welche Richtung Sie mit dieser Ausgabe einschlagen möchten, oder schließen Sie die Ausgabe einfach, damit wir nicht hängen bleiben. Vielen Dank.

@thaJeztah
Es gibt keine Möglichkeit, eine einzelne --insecure-registry zu Daemon-Opts hinzuzufügen, ohne alle laufenden Container neu zu starten. Das ist eines der Hauptprobleme. Wir können die Konfiguration nicht ohne Neustart neu laden (Problem besteht seit 2013), wir können keine Bilder aus anderen unsicheren Registrierungen abrufen, ohne dem Daemon eine Option hinzuzufügen und auch neu zu starten. Und heutzutage haben wir immer noch keinen klaren Fahrplan zur Behebung dieses Problems.

@apakhomov denke, es könnte der Liste der Konfigurationsänderungen hinzugefügt werden, die ohne Neustart aktualisiert werden können https://docs.docker.com/engine/reference/commandline/daemon/#configuration -reloading. Kannst du dafür ein separates Thema eröffnen?

+1.

Einige PaaS-Anbieter gewähren keinen Zugriff auf den Daemon und betreiben ein privates Netzwerk für den Benutzer (z. B. Jelastic).

Ist es möglich, Docker mehrere unsichere Registrierungen hinzuzufügen?
so etwas wie --insecure-registry xxxx:xxxx --insecure-registry zzzz:zzzz

@kkorada --insecure-registry=0.0.0.0/0 Docker sich wie zuvor verhalten.

@kkorada ja, Sie können mehrere Registrierungen angeben (das Flag ist --insecure-registry=[] - eckige Klammern zeigen an, dass es mehrmals angegeben werden kann).

Auch für Docker 1.12 machen wir diese Option in der Konfigurationsdatei daemon.json konfigurierbar, ohne den Daemon neu zu starten. Siehe die offene Pull-Anfrage hier: https://github.com/docker/docker/pull/22337

danke @mingfang und @thaJeztah

Wie @mhamrah und @justinclayton vorgeschlagen , würde ich auch eine Lösung empfehlen, die zusätzlich zu TLS ssh verwendet, ähnlich wie Git den Zugriff auf ein Repository sowohl mit ssh als auch mit TLS ermöglicht. Dies könnte die von @justinclayton aufgeführte ssh- Problemumgehung verwenden .

Obwohl ich keine Daten habe, um meine Behauptung zu untermauern, würde ich vermuten, dass es viel mehr private Registrierungen gibt, die hinter Firewalls laufen, als Registrierungen, die im offenen Internet laufen. In diesem Fall ist ssh einfacher zu konfigurieren und, wenn nicht sogar sicherer als TLS.

Außerdem, nachdem ich tagelang mit docker push und meiner lokalen, privaten Registrierung in einer internen, ausreichend sicheren virtuellen Maschine gekämpft habe (und mehr Zeit damit hatte, selbstsignierte Zertifikate zu erstellen), habe ich es einfach zu schätzen gelernt rkt --insecure-options=image,tls,http .

Es ist verrückt, dass dies keine Client-Einstellung ist. Offensichtlich sollte es nicht standardmäßig aktiviert sein, da dies zu unsicherem Üben führen würde. Das Setzen der Einstellung auf den Daemon macht es jedoch für Debugging-Zwecke oder in lokalen Entwicklungsumgebungen sehr unpraktisch.

Mein aktueller Anwendungsfall: Ausführen einer Entwicklungsumgebung mit Docker Compose. Die Umgebung benötigt eine lokale Docker-Registry. Es soll vollständig auf einer lokalen VM ausgeführt werden.

Der Docker-Weg: Erklären, wie man docker-machine so konfiguriert, dass eine unsichere Registrierung auf jedem Entwickler-Rechner aktiviert wird.

Die Hacky-Lösung: socat läuft in jedem Container, der die Registrierung verwenden muss, und leitet an localhost weiter.

Macht es nicht gerade einfach...

+1

Wirklich schade für --unsecure, keine Client-Konfiguration zu sein!
Das verursacht auch bei uns viel Schmerz, ganz ähnlich wie bei vielen der obigen Erklärungen.
Bitte setzen Sie --insecure-registry=0.0.0.0/0 standardmäßig, um eine Möglichkeit zur Übergabe an den docker-Befehl sowie an docker-compose-Konfigurationen bereitzustellen.

+1

+1

Ist es wieder Zeit für die jährliche +1 Pity Party?

Am 13. Dezember 2016 um 1:00 Uhr schrieb 沙包妖梦[email protected] :

+1

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder schalten Sie den Thread stumm.

Wenn die Image-Layer signiert sind, ist die Verwendung von CA PKI aus Sicherheitsgründen nicht erforderlich. Siehe auch wie apt/yum funktioniert. Darüber hinaus macht die Verwendung von SSL in einem LAN wenig Sinn, und in einer Cloud-Umgebung bedeutet dies, dass Sie - abgesehen von den Zertifikaten selbst - eine gute Zufallsquelle bereitstellen müssen (siehe auch: https://lukehinds.github.io/2015-03 -03-Entropie-in-der-Cloud/).

Lange Rede, kurzer Sinn: Wenn es unnötig ist, zwingen Sie es den Benutzern nicht auf.

Ich habe gerade die Nummer 29736 geöffnet, die verwandt ist.

+1, wenn ein clientseitiges --insecure-registry Flag keine Option ist, sollte es eine Möglichkeit geben, ein vertrauenswürdiges Zertifikat anzugeben, das für docker pull und docker push . Nicht jeder hat Zugriff auf Vertrauenszertifikate auf Betriebssystemebene oder Zugriff, um mit dem Docker-Daemon herumzuspielen.

Gehostete CI-Server (die zum Erstellen von Docker-Images und zum Pushen in eine private Registrierung verwendet werden) sind ein gutes Beispiel dafür, wenn Sie möglicherweise nicht über diese Zugriffsebene verfügen.

+1

@ajhodges https://docs.docker.com/registry/insecure/#using -self-signed-certificates

@tiborvass
Funktioniert nur, wenn Sie sudo-Zugriff haben...

+1 gute Möglichkeit, Entwickler davon abzuhalten, Docker zu verwenden

+1, ich möchte auch --insecure-registry für docker login .

Ich sehe dies nicht einmal als Sicherheitsproblem, da Sie es bewusst tun. Und wenn jemand, der nicht autorisiert ist, Root-Zugriff erhält, bietet dies auch keine Sicherheit. Welchen Wert hat diese Einschränkung eigentlich?

Wenn Sie böse Absichten hatten, könnten Sie einfach Ihr bösartiges Docker-Image auf den vertrauenswürdigen DockerHub hochladen.

+1 und ehrlich gesagt verwirrt das den Verstand

+1 zum Schmerzzug.

Plus F*cking One!

Gibt es dafür eine PR offen?

Nicht AFAIK. Die obigen Links werden generiert, weil ein Teil meines eigenen Codes auf dieses Problem verweist. Ich werde diese Referenz für eine Weile ziehen, um den Spam hier zu beruhigen.

+1 auch...

+1

+1 , ist es sehr unpraktisch, Einstellungen zu deamon.json hinzuzufügen und Docker neu zu starten.

Unterschiedliche Maschinen haben unterschiedliche Betriebssysteme. Einige installieren Docker von yum 、 apt-get , und einige verwenden direkt binary . Also muss ich das erkennen und dockerd richtig neustarten .... das ist eine Katastrophe

Ich betone nur, dass Docker das Flag --insecure-registry ziehen muss!

Es ist erst drei Jahre her - lasst uns jetzt die Hoffnung nicht verlieren

stoßen 🤣

+1

+1

Das Argument, dass dies die Benutzer dazu ermutigt, ihre Registrierungen als sicher zu bezeichnen, ist nicht nur anmaßend, es fehlt auch ein wesentlicher Punkt. Es versetzt den Betrieb in die Lage, in der viele Leute Zugriff auf das Root-Konto haben müssen, um ihre Betriebsarbeit zu erledigen, in der Docker-Registrys viel umziehen.
Diese Kopplung erzeugt aus Sicht der Betriebssicherheit ein größeres Sicherheitsrisiko.

Zweitens ist in einem privaten Netzwerk (z. refresh) überall dort, wo eine sichere Docker-Registry verwendet wird.

Zumindest sollte der Docker-Daemon so konfiguriert werden können, dass er die Übergabe unsicherer Registrierungsparameter verschoben - in die Hände des Administrators und außerhalb von Docker selbst.

FWIW Ich würde mich über einen Befehl zum "Hinzufügen einiger Registrierungen zur Liste der unsicheren Registrierungen" freuen, da das Patchen von Json-Konfigurationen aus Shell-Skripten ein großer Schmerzpunkt ist.

+1

:+1: +1

+1

+1

+1

+1

Viele der geforderten Implementierungen davon würden es Unternehmen, die Docker verwenden, unmöglich machen, SOC-Compliance-Anforderungen usw. einzuhalten.

Es sollte eine Lösung dafür geben, aber ich glaube nicht, dass es eine einfache Lösung gibt, die keine drastischere architektonische Änderung der Speicherung und Ausführung von Bildern darstellt.

Trotzdem sollte das passieren.

Ich bin nicht mehr an der Docker-Entwicklung beteiligt, daher werde ich mich aus den Erwähnungen entfernen. Viel Glück ^_^

Die SOC-Anforderung ist ein guter Punkt. In diesem Fall sollte diese Funktion mit einer Konfigurationsoption AKTIVIERT werden, die der systemweiten Docker-Konfiguration hinzugefügt wird. Auf diese Weise können die SOC-Anforderungen beibehalten werden. Etwas wie "ALLOW_INSECURE_REGISTY_OPTION", das das Flag --insecure-registry in der Docker-Befehlszeile aktiviert.

Für die SOC-Konformität darf die Option nicht aktiviert sein.

+1

Es ist erst drei Jahre her - lasst uns jetzt die Hoffnung nicht verlieren

5.

Es ist sehr unwahrscheinlich, dass dieser Vorschlag (in seiner jetzigen Form) umgesetzt wird, da verschiedene
Gründe, darunter;

• es behält die Person, die den Docker-Daemon verwaltet, die Verantwortung für welche Verbindungen
  der Daemon darf machen. Beachten Sie, dass diese Option "live neu geladen" werden kann,
  der Daemon muss also nicht neu gestartet werden, um die Konfiguration zu ändern.
• jeder Befehl oder Codepfad, der potenziell mit einer Registrierung interagiert, hat
  Geändert werden; nicht nur docker pull , sondern auch docker build , docker run ,
  docker plugin , docker service und docker stack sowie
  Orchestratoren wie swarmkit, die Bilder von Worker-Knoten abrufen.
• SOC-Konformität (wie oben erwähnt)

Zumindest sollte der Docker-Daemon so konfiguriert werden können, dass er unsicher ist
Registrierungsparameter übergeben werden. Das verschiebt das Sicherheitsdesign in die richtige
Platz - in den Händen des Administrators und außerhalb von Docker selbst.

Ich denke, der Administrator wäre in diesem Fall die Person/das Team, das/das verwaltet
Hosts, auf denen der Docker-Daemon ausgeführt wird, nicht der Benutzer, der sich mit der Fernbedienung verbindet
API. Aus diesem Grund handelt es sich bei dieser Konfiguration um eine Daemon-Konfiguration.

Das Patchen von Json-Konfigurationen aus Shell-Skripten ist ein großer Schwachpunkt.

Das ist ein fairer Punkt, aber orthogonal zu dieser Diskussion. Es ist nicht unmöglich_
die JSON-Konfiguration zu patchen, stimmte aber zu, dass es komplizierter sein kann als andere
Dateiformate. Beachten Sie, dass diese Konfiguration auch so eingestellt werden kann, wie durch Flags on
der Daemon, der es Ihnen ermöglicht, eine systemd-Drop-In-Unit-Datei zur Neukonfiguration zu verwenden
der Dämon.

Etwas wie "ALLOW_INSECURE_REGISTY_OPTION", das das Flag --insecure-registry in der Docker-Befehlszeile aktiviert.

Wenn Sie unsichere Pulls aus einer Registrierung zulassen möchten (was das Äquivalent wäre)
das Hinzufügen eines --insecure-registry Flags), können Sie "das Internet" als unsicher zulassen
Registrierung; Folgendes sollte es ermöglichen, dass jede IPv4-Adresse als unsichere Registrierung verwendet wird,
(also auf Nicht-TLS-Verbindungen zurückgreifen);

Durch die /etc/docker/daemon.json Konfigurationsdatei;

{"insecure-registries": ["0.0.0.0/1","128.0.0.0/2","192.0.0.0/3","224.0.0.0/4"]}

Oder indem Sie die Optionen als Flags an den Daemon übergeben (der in einem systemd
Datei überschreiben);

dockerd \
    --insecure-registry=0.0.0.0/1 \
    --insecure-registry=128.0.0.0/2 \
    --insecure-registry=192.0.0.0/3 \
    --insecure-registry=224.0.0.0/4