Moby: --insecure-registry devrait être sur "docker pull"

Nous gérons des registres Docker internes non sécurisés dans tous les environnements CI et de production. Je dois dire qu'il serait très utile de simplement permettre l'accès à tous les registres non sécurisés sans avoir à les lister un par un. Nous avons plusieurs registres dans chaque environnement pour la haute disponibilité. Ce changement a rendu les choses beaucoup plus compliquées pour nous. Je vais ouvrir un autre ticket de problèmes spécifiquement pour résoudre ce problème, car ce problème consiste davantage à déplacer l'option vers le pull plutôt que sur le démon.

Et il y a un petit problème de poule et d'œuf lorsque vous n'utilisez pas un port fixe pour exécuter le registre.

Étant donné que vous ne savez pas à l'avance quel port sera attribué par docker, vous ne pouvez pas vraiment démarrer la démo avec un indicateur qui le référence.

:+1:

donc je suppose que prendre en charge --insecure sur la ligne de commande docker pull , désactiver de force les contrôles de sécurité, évidemment pour la commande _this_ pull, résoudrait également votre problème @proppy et @octalthorpe, n'est-ce pas ? car exécuter avec ce drapeau ne vérifierait aucune liste

@abourget il doit également être pris en charge dans l'API distante.

Actuellement, docker-py expose un indicateur insecure_registry sur la fonction pull , mais il n'est utilisé que pour résoudre le point de terminaison : https://github.com/docker/docker-py/blob/master/ docker/client.py#L794

Le coupable semble être https://github.com/docker/docker/commit/6a1ff022b0744213ed588d9c16dbb13ce055eda6

Mais je n'ai pas pu trouver le PR correspondant ou les problèmes où ce changement a été discuté.

@tiborvass des idées ?

@proppy - Cela a été traité comme une vulnérabilité de sécurité sous embargo et n'a pas été discuté dans une RP publique. L'équipe de base avait une visibilité et un vote sur la question.

Je dois réfléchir aux implications d'un tel changement pour localhost/127.0.0.1, mais je n'y suis pas particulièrement intéressé. C'est une configuration non standard et peu courante et la solution est bien documentée.

@ewindisch d'autre part, il y a déjà beaucoup de démons docker en cours d'exécution, avec un conteneur de registre exécuté sur localhost .

Si littéralement tous ces utilisateurs doivent passer --insecure-registry localhost:5000 , vous pourriez aussi bien en faire la valeur par défaut.

@ewindisch Avez-vous de la documentation ou des conseils sur ce qui constitue une vulnérabilité de classe embargo ? Ce n'est pas un RCE distant et non authentifié. Le danger ici ne semble pas assez aigu pour justifier un changement décisif dans une version ponctuelle sans avertissement.

@mmdriley - la définition selon Mitre/NST s'applique généralement. Dans ce cas, une attaque man-in-the-middle est viable, ce qui permet l'exécution de code arbitraire non fiable sur les systèmes affectés, donc oui, nous classons cela comme RCE. Cela signifie que si vous utilisiez Docker pour extraire des images sur un ordinateur portable dans un café, par exemple, un autre utilisateur de ce point d'accès WiFi pourrait potentiellement exécuter des applications arbitraires fournies par un attaquant. Ils pourraient également potentiellement accéder à votre compte DockerHub ou à d'autres registres auxquels vous vous authentifieriez.

EDIT : ajout d'un lien pour la description CVE : https://groups.google.com/d/msg/docker-user/oYm0i3xShJU/0QbAw9eN9qkJ

Oui, j'avais tort de dire que ce n'était pas RCE. C'est un mauvais bug, et un excellent témoignage de la raison pour laquelle la signature d'images robuste est une excellente idée. Cependant, l'exploitation n'est pas anodine : elle nécessite qu'un attaquant actif traîne chez Starbucks en espérant que quelqu'un à proximité utilisera Docker sur un WiFi non sécurisé. Cela ne va pas être militarisé du jour au lendemain – et ne mérite donc pas un changement rétrocompatible sans avertissement.

Comme cela a été suggéré ci-dessus, il existait des moyens évidents d'améliorer immédiatement la sécurité sans rompre la compatibilité. Par exemple, la désactivation du repli HTTPS pour index.docker.io et la poignée d'autres registres publics populaires aurait effectivement résolu le problème pour la plupart des utilisateurs. L'ajout d'un avertissement à la sortie de la console indiquant que le repli HTTP se produisait aurait atténué le cas interactif. Le repli HTTP serait marqué comme obsolète et supprimé dans, disons, la version du mois prochain. Enfin, localhost et ::1 ne sont évidemment pas vulnérables.

Encore une fois, je n'aurais pas dû minimiser l'étendue de la vulnérabilité, mais je crains que le processus de réponse et le correctif n'aient pas mis suffisamment de valeur pour ne pas casser les clients.

Nous créons/détruisons actuellement des registres Docker dynamiquement dans un environnement qui n'a pas de nom de domaine complet disponible pour bon nombre de ces instances. La prise en charge d'une option --insecure-repository pour les demandes liées au registre (sur l'API distante) supprimerait les complications importantes que ce correctif de sécurité a créées pour nous.

Nous avons un problème similaire avec Docker 1.3.1. Nous utilisons le registre Docker local (privé) à l'adresse http://docker :5000/. Jusqu'à Docker 1.3.0, cela fonctionnait très bien. Avec Docker version 1.3.1, cela ne fonctionne plus car le client Docker suppose automatiquement que le registre est accessible sur HTTPS. Mais nous n'utilisons pas du tout HTTPS.

Ce serait bien d'implémenter un mécanisme de secours qui utilise HTTP si un serveur Docker Registry n'est pas accessible via HTTPS.

@kruxik si vous utilisez --insecure-registry docker:5000 lors du démarrage du démon, il se repliera sur HTTP.

@tiborvass merci pour la suggestion. Vous avez raison. Mais si vous avez beaucoup de développeurs avec leurs stations de travail et ordinateurs portables, définir --insecure-registry sur chaque station est une manière peu pratique. Au moins le laisser comme paramètre facultatif pour les opérations pull/push nous suffirait ;)

+1

Cela a fonctionné pour nous avec 1.3.0, mais avec 1.3.1

version docker
....
Version du serveur : 1.3.1
....
docker push 10.121.4.236:5000/debian7/consul
-> ....Si ce registre privé ne prend en charge que HTTP ou HTTPS avec un certificat CA inconnu, veuillez ajouter --insecure-registry 10.121.4.236:5000 aux arguments du démon. Dans le cas du HTTPS, si vous avez accès au certificat CA du registre, pas besoin de flag ; placez simplement le certificat CA à

Rétrograder
Version du serveur : 1.3.0
docker push 10.121.4.236:5000/debian7/consul
-> les conteneurs se téléchargent sans problème.

Pour les autres ayant des problèmes avec les versions 1.3.0 à 1.3.1, j'ai dû apporter les modifications suivantes pour OS X avec boot2docker :

$ 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

alors vous _should_ être capable de faire une traction de docker.

Si vous utilisez fig, vous avez également besoin de Fig 1.0.1 et procédez comme suit :

$ fig up --allow-insecure-ssl

@mhamrah Merci ! J'ai passé des heures à essayer de résoudre ce problème...

+1 pour supposer que localhost est sécurisé. Est-ce que quelqu'un est vraiment contre ?

Oui, supposer que localhost est sécurisé aiderait beaucoup. J'utilise vagrant pour ma boîte docker, donc la mise à jour du script d'initialisation à chaque fois que je détruis ou affiche une boîte est tout simplement inefficace. Je suppose que je vais maintenant devoir marier ma boîte docker pour pouvoir modifier l'init sur le vagabond.

utiliser également un indicateur --insecure sur le pull et le push serait bien pour que je puisse utiliser l'IP de la boîte vagrant si nécessaire.

@thocking : le supposant que localhost est sécurisé : veuillez consulter https://github.com/docker/docker/issues/8898

Pour être honnête, je me demandais aussi pourquoi mes Jenkins Containerbuilds automatisés n'ont pas réussi à pousser...
(C'est bien d'avoir un test avant de le mettre en production).
Je dois vérifier si cette "fonctionnalité" a vraiment été annoncée - sinon je serai plus paranoïaque sur des changements massifs si extrêmes sur le comportement des démons.

Ce qui me manque dans cette discussion :
Pourquoi dois-je même dire au démon d'utiliser le mode sécurisé / non sécurisé "par défaut" pour chaque hôte ?

Ne devrait-il pas être plus productif de configurer le registre avec ce comportement par défaut ?
Donc, selon la configuration, si aucun paramètre --secure ou --insecure n'est donné, le démon doit demander
si un moyen sécurisé est possible et sinon que le repli vers non sécurisé a été utilisé.

L'une des principales choses de docker est qu'il est complètement facile à utiliser et à configurer un environnement complet. s'il vous plaît ne tuez pas cet effet WOW avec de telles "libérations/décisions"...

juste mes 2 cents...

Problèmes similaires ici à ceux ci-dessus, y compris @jwthomp. J'ai passé plus de 10 heures à essayer de résoudre ce problème et, entre-temps, je suis passé à docker 1.3.0.

J'exécute le registre docker sous Marathon et le registre docker "prend actuellement en charge SSL en exécutant nginx en tant qu'interface" (voir https://github.com/docker/docker-registry/issues/697 ) mais utiliser nginx en tant qu'interface est compliqué par Marathon exécutant le registre docker sur divers hôtes/ports esclaves.

Je pourrais activer SSL directement dans le registre (à l'aide de GUNICORN_OPTS), mais il ne parle _seulement_ que SSL et ne peut pas passer les contrôles de santé Marathon.

J'ai modifié le système de configuration de Bamboo HAProxy pour configurer également HAProxy en tant qu'interface https vers tous les services de la même manière que nginx l'aurait été, mais j'ai toujours des problèmes avec docker pour valider le certificat sur mon registre privé, donc ce n'est toujours pas le cas. moi en ce moment.

C'est très bien de se protéger contre le RCE, mais il faut aussi une certaine rétrocompatibilité. Au moins un indicateur pour le démon docker pour spécifier tous les registres comme non sécurisés. Il devrait y avoir un moyen de spécifier http ou https dans le nom de registre dans chaque commande docker pull. Pour le moment, 1.3.1 semble être un gros piège pour quiconque utilise un registre privé.

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

Joli.
Le vendredi 14 novembre 2014 à 10h42 Ilya Radchenko [email protected]
a écrit:

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

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/docker/docker/issues/8887#issuecomment -63082089.

@mhamrah Je n'ai pas eu à supprimer les clés ssh, etc. J'ai juste ajouté la ligne nécessaire dans /var/lib/boot2docker/profile et redémarré docker. Merci pour le conseil!

Frais. J'ai même eu du mal à entrer, je présume à cause d'une version
discordance entre les iso de docker. En fait, je suis passé à l'utilisation de vagrant +
coreos pour la prise en charge de docker, et cela fonctionne bien. Vous avez juste besoin de définir
DOCKER_HOST, que boot2docker fait automatiquement.

Le jeu. 20 novembre 2014 à 01:52:21 Kayvan Sylvan [email protected]
a écrit:

@mhamrah https://github.com/mhamrah je n'ai pas eu à faire la suppression de
les clés ssh, etc. Je viens d'ajouter la ligne nécessaire dans
/var/lib/boot2docker/profile et docker redémarré. Merci pour le conseil!

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/docker/docker/issues/8887#issuecomment-63768043 .

Désolé les gars, je voulais répondre plus tôt.

Comme @ewindisch l'a déjà dit, nous ne voulons pas encourager ce comportement côté client. La douleur induite par l'exigence de l'indicateur en tant qu'indicateur démon est que les gens configurent réellement TLS sur leur registre. Sinon, il n'y a pas d'incitation. Merci pour votre compréhension.

Il existe une image "officielle" basée sur les dockers du registre des dockers sur le registre officiel des dockers. Il est recommandé d'utiliser sans TLS.

Si Docker souhaite que les utilisateurs configurent TLS sur leur registre, cela n'aurait-il pas de sens d'équilibrer la "douleur induite" avec une "réduction de la douleur" égale et opposée en fournissant une image docker officielle qui fournit par défaut TLS ?

@tiborvass . Vous ignorez le cas de développement interne derrière le pare-feu. Alors maintenant, je dois soit configurer un proxy inverse avec SSL activé devant mon registre (il n'y a tout simplement aucune raison de le faire) ou je dois aller à chacun de mes développeurs et modifier les arguments du démon en cours d'exécution à l'intérieur de boot2docker. Cela n'a aucun sens. Il existe de nombreux environnements de développement qui offrent une sécurité configurable dans laquelle la sécurité est souvent désactivée pour les environnements de développement. Je suis surpris de vous voir clore ce dossier alors qu'il y a eu autant de votes pour une solution.

Qu'en est-il de la liste blanche de toutes les adresses IP privées ? Terrain d'entente?

Ou faire en sorte que le nom du protocole, 'http' ou 'https' fasse partie du nom de l'image pour pull.

@tiborvass @sroebuck et @blevine font valoir de bons arguments. Cela deviendra de plus en plus le scénario pour les magasins construisant des conteneurs en interne, et la fureur de briser le flux de travail précédent augmentera également. Nous comprenons tous le côté sécurité de cela, et peut-être que pull n'est pas le bon endroit pour le résoudre, mais tant que l'image officielle du registre ne fournit pas un moyen simple et prêt à l'emploi de gérer ce changement, il devrait être considéré comme un problème UX assez important à résoudre.

Salut @tiborvass ! Ce problème nous ronge également en ce moment. Je préfère l' approche de

@blevine note qu'à partir de la 1.3.2 localhost est sur liste blanche par défaut, voir : https://github.com/docker/docker/pull/9124

Vous pouvez faire en sorte que le registre écoute sur localhost en passant : -p 127.0.0.0:5000:5000 à docker run

@proppy , je ne sais pas trop en quoi l'écoute sur localhost m'aide.

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

Ou devrait-elle devenir une URL réelle ? Je ne connais rien au protocole de registre mais il ne semble pas incompatible d'étendre la syntaxe actuelle pour spécifier une URL appropriée.

@blevine, cela signifie que vous pouvez configurer un registre de mise en miroir local.

Arg, maintenant je dois décoder en base64 ma configuration cloud pour coreos pour que mes machines démarrent

@tiborvass Wow, c'est vraiment malheureux. :(

Nous avons des clusters de développement que nous faisons monter et descendre à la volée et une partie de la façon dont nous gérons ces clusters est de créer un registre pour ce cluster. Un cluster peut être composé de plusieurs nœuds physiques ou machines virtuelles, et il peut également se trouver sur un ordinateur de bureau ou un ordinateur portable de développeur (bien que nous ne puissions généralement pas lancer une pile complète). Chaque cluster est une pile et un environnement de développement entièrement autonomes. Nous avons également des outils de ligne de commande basés sur Docker qui permettent à un développeur d'interagir avec n'importe quelle configuration de cluster de développement dans l'entreprise.

Dans ce type d'environnement complexe et dynamique, faire de TLS sur un registre une exigence est une tâche gigantesque. Devoir modifier le démarrage du démon docker à chaque fois que nous ajoutons un nouveau réseau sur lequel un registre pourrait se trouver est également pénible.

Ne vous méprenez pas, j'apprécie l'idée derrière le fait de vouloir prendre en charge TLS exclusivement, mais je vous encourage à considérer qu'il existe des cas valides où l'environnement prend en charge en toute sécurité la suppression de la complexité de TLS pour la réduction de la douleur et l'infrastructure nécessaire pour prendre en charge ce.

@tiborvass +1. +1000. Cela a généré une complexité absolument inutile pour
nous à un workflow de développement hautement dynamique. La barrière à l'entrée a été
soulevé de manière significative ici pour quelque chose qui doit seulement s'appliquer dans un
contexte de fabrication. Veuillez mettre fin à notre douleur.

Le mardi 9 décembre 2014, Jeff Thompson [email protected]
a écrit:

@tiborvass https://github.com/tiborvass Wow, c'est l'un de ceux
table virtuelle retournement moments tristement. :(

Nous avons des clusters de développement que nous faisons monter et descendre à la volée et
de la façon dont nous gérons ces clusters est de créer un registre pour ce cluster. UNE
le cluster peut être composé de plusieurs nœuds physiques ou vms, et il peut également se trouver sur un
ordinateur de bureau ou ordinateur portable des développeurs (bien que nous ne puissions généralement pas lancer un
un paquet entier). Chaque cluster est une pile et un développement entièrement autonomes
environnement. Nous avons également des outils de ligne de commande basés sur docker qui permettent un
développeur pour interagir avec n'importe quelle configuration de cluster de développement dans l'entreprise.

Dans ce genre d'environnement complexe et dynamique, faire TLS sur un registre
une exigence est une douleur gigantesque. Devoir modifier le démarrage du démon docker
chaque fois que nous installons, nous ajoutons un nouveau réseau sur lequel un registre pourrait être
également une douleur.

Ne vous méprenez pas, j'apprécie l'idée derrière vouloir soutenir
TLS, cependant, il existe des cas où l'environnement prend en charge en toute sécurité la suppression
la complexité de TLS pour la réduction de la douleur et l'infrastructure nécessaire
pour le soutenir.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/docker/docker/issues/8887#issuecomment -66367681.

@justinclayton @jwthomp @mattwilliamson @nickandrew @blevine

--insecure-registry 0.0.0.0/8 résout-il pas votre problème ? De cette façon, vous pouvez toujours utiliser HTTP.

Cette notation CIDR peut être utilisée de manière plus granulaire pour activer les configurations "derrière le pare-feu" en spécifiant des plages telles que "--insecure-registry 172.16.0.0/12". Je ne conseille pas du tout d'utiliser cette option, mais je recommande aux utilisateurs qui choisissent cette option d'utiliser une plage plus sélective (comme leur espace IP) plutôt que toutes les adresses possibles avec 0.0.0.0/8.

Le démon docker est intégré à coreos, je dois donc en quelque sorte ajouter ces drapeaux au démarrage à travers le cluster. Je pense qu'il est beaucoup plus flexible de l'avoir sur la commande pull pour les environnements où vous ne pouvez pas contrôler le démon docker lui-même.

C'est l'équivalent de nous dire de changer un fichier php.ini pour un hôte php partagé.

Le 9 décembre 2014, à 22h18, Tibor Vass [email protected] a écrit :

@justinclayton @jwthomp @mattwilliamson @nickandrew @blevine

--insecure-registry 0.0.0.0/8 ne résout-il pas votre problème ? De cette façon, vous pouvez toujours utiliser HTTP.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub.

Les indicateurs d' exécution

Des exemples de modification de la configuration de Docker se trouvent sur le site Web de CoreOS. On pourrait facilement modifier les instructions pour ajouter un indicateur de débogage pour spécifier à la place un indicateur de registre non sécurisé.

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

@tiborvass, l'ensemble de l'écosystème de configuration doit prendre en charge cela pour fonctionner facilement hors de la boîte. Les gens ne s'attendent pas à apporter des personnalisations non standard au démarrage du démon partout où ils pourraient tirer (boot2docker, coreos, tout ce qui est installé avec les modules chef/puppet, etc.) lorsqu'ils passent à l'étape de configuration de leur propre registre interne. L'image officielle du conteneur de registre elle-même _ne fonctionne plus_ lors de l'utilisation des étapes marquées « recommandées » dans le fichier readme. En fait, le fichier readme ne fait aucune mention de TLS, et sa configuration est un processus non trivial. De plus, comme @mattwilliamson l'a brièvement mentionné ci-dessus, il existe une myriade de cas, comme des environnements de construction partagés, où une personne utilisant le démon pour extraire une image n'est pas la même que la personne qui configure le démon.

En fin de compte, en faire un argument côté client est clairement la solution la moins perturbatrice et, plus important encore, la solution la moins normative. Docker est déjà devenu une primitive dans des dizaines, voire des centaines d'autres projets et flux de travail, et en tant que tel, il ne devrait vraiment pas dicter les modèles d'utilisation à cette échelle. Ce n'est pas parce que Git offre une option de configuration d'exécution simple pour désactiver http.sslverify que Linus Torvalds encourage les gens à ne pas sécuriser leurs données sensibles dans des contextes où il est important de le faire.

L'analogie git est un bon exemple de la façon dont cela devrait fonctionner. Git ne vous oblige pas à utiliser TLS, et c'est à l'utilisateur de décider lors de la configuration d'un hôte quel niveau il souhaite prendre en charge. C'est également à l'utilisateur de décider du niveau de sécurité dont il a besoin (ou qu'il souhaite contourner). La configuration est une étape simple, soit globalement, soit par référentiel. Bien que Docker ne nous oblige pas à utiliser TLS, en rendant l'alternative non triviale, il ne fournit aucune autre option raisonnable.

La notation CIDR permet sans doute une approche de "marteau lourd", et AFAIK, ne correspond pas aux noms DNS, donc même si je masque un 10.0.0.0/16, tirant some.private-registry.com dans un 10.0/16 won' t fonctionner. Plus important encore, la configuration n'est pas triviale.

Docker prospère dans sa simplicité pour la conteneurisation et abaisse considérablement la barrière pour le déploiement d'applications dans une variété d'environnements. Nous connaissons tous les avantages. La plupart des développeurs ne peuvent pas répondre à de simples questions de notation CIDR, le fichier de configuration docker peut se trouver dans des endroits non standard (les emplacements boot2docker et CoreOS sont tous deux différents des autres distributions), et il est assez facile de gâcher ces fichiers de configuration avec des boucles de rétroaction difficiles pour Succès. Je dois suivre syslog? Oh attends je suis sur RHEL et c'est des messages ?

Un nouveau développeur peut facilement copier et coller un extrait de docker pull , mais les faire ssh dans un hôte boot2docker, exécuter vi, éditer un fichier de configuration, puis suivre un syslog pour les erreurs... pas tellement. Et oh oui, vous avez oublié de redémarrer le démon docker.

Voici ce que j'aimerais voir :

• Paramètres du démon Docker appliqués via la commande docker
• Paramètres d'extraction de Docker pour les remplacements TLS, spécifiés via la commande docker
• Paramètres d'extraction de Docker conservés dans les commandes pour des registres spécifiques

Oui, mais amazon ne vous permet pas de modifier une configuration autoscscale. Je vais devoir en faire une copie ou en faire une toute nouvelle.

Le 9 décembre 2014, à 23h55, Eric Windisch [email protected] a écrit :

Les indicateurs d'exécution sont configurables avec CoreOS. Vous pouvez modifier le fichier de configuration systemd pour Docker. Pour configurer cela pour un cluster, vous pouvez utiliser cloud-config.

Des exemples de modification de la configuration de Docker se trouvent sur le site Web de CoreOS. On pourrait facilement modifier les instructions pour ajouter un indicateur de débogage pour spécifier à la place un indicateur de registre non sécurisé.

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

-
Répondez directement à cet e-mail ou consultez-le sur GitHub.

Je dois actuellement contourner ce problème dans l'environnement de développement de mon entreprise en exécutant cette commande minutieusement recherchée à chaque fois que je fais "boot2docker up"

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"'

Quelle douleur. L'adoption de docker au sein de mon entreprise de plus de 400 personnes est bloquée en raison de ce problème. Nous n'avons absolument aucune utilité pour TLS dans notre environnement de développement interne où tout est contrôlé. Nous applaudissons son utilisation pour les référentiels de hub publics, et pensons que le forcer ailleurs dans tous les cas est une énorme erreur.

@CleanCut très bien mis. J'ai été vraiment déçu que la 1.4.0 soit venue et est partie et que ce problème reste ouvert.

@CleanCut génial - Ce que je voudrais dans boot2docker, c'est qu'il ajoute plus d'informations à la charge utile initiale de boot2docker init , qui le ferait ensuite pour vous.

ne résout pas les problèmes spécifiques non basés sur vm-boot2docker, mais --insecure-registry n'est pas la seule personnalisation spécifique au site que les utilisateurs b2d souhaitent.

pouvez-vous faire une pull request ou un problème pour cela dans le référentiel boo2docker s'il vous plaît ?

Élève vraiment la barrière pour que quelqu'un utilise un projet applaudi pour abaisser les barrières.

Le 13 décembre 2014, à 02h10, Justin Clayton [email protected] a écrit :

@CleanCut très bien mis. J'ai été vraiment déçu que la 1.4.0 soit venue et est partie et que ce problème reste ouvert.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub.

@SvenDowideit Chose sûre. C'est ici

Il semble qu'il y ait un consensus dans ce fil pour dire que ce n'est pas un problème résolu ; pourrions-nous s'il vous plaît rouvrir ce problème?

Oui s'il vous plaît!
Le 2014-12-15 15:05, "Justin Clayton" [email protected] a écrit :

Il semble qu'il y ait un consensus dans ce fil pour dire que ce n'est pas résolu
problème; pourrions-nous s'il vous plaît rouvrir ce problème?

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/docker/docker/issues/8887#issuecomment-67055878 .

+1. Je n'ai rien à ajouter, mais je veux simplement exprimer ma frustration face à cette décision. Comme tout le monde, j'exécute un registre sur un réseau local où la sécurité est gérée ad nauseam ailleurs. J'ai des dizaines de conteneurs docker en cours d'exécution qui doivent maintenant être renvoyés pour ajouter le drapeau «bien documenté».

@bfirsh - c'est l'un de ces exemples où un fichier de configuration du démon Docker et un kill -HUP <dockerdaemonpid> seraient géniaux - le déclencher pour relire le cfg, sans avoir besoin de le redémarrer - évitant ainsi le redémarrage du conteneur

@SvenDowideit +1 pour la fonction de rechargement, il est vraiment ennuyeux de redémarrer le serveur par une simple configuration.

+1

Pardonnez-moi si je ne comprends pas correctement les choses, mais il semble que ce problème soit à l'origine de mon propre scénario (semblable à celui décrit par @blevine où mon entreprise dispose d'un proxy de réécriture de certificats qui m'empêche de même parler au registre public Docker Hub). Je sais qu'à terme je souhaiterai créer mon propre registre privé, mais je n'en suis qu'à la phase d'apprentissage, où je ne sais pas encore si j'adopterai Docker. C'est un cauchemar UX pour quelqu'un qui en est aux premiers stades de l'adoption.

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

+1 pour rouvrir cette discussion, car il semble que la communauté ne soit pas vraiment satisfaite de la solution actuelle.

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

juste essayer de toucher cela sous tous les angles jusqu'à ce que nous entendions une réponse définitive sur ce sujet.

+1, il est actuellement difficile de le configurer et de le faire fonctionner.

@mhamrah fait d'excellents points. Ne forcez pas les choses, laissez les utilisateurs décider et configurer selon leurs propres besoins.

Les registres qui utilisent des certificats auto-signés sont également un problème, en particulier
dans un contexte de développeur utilisant boot2docker qui est passé à un fichier en lecture seule
système. Cela nécessite une étape de configuration supplémentaire et différente pour
amorcer la machine virtuelle en cours d'exécution.

Je crois que tous ceux qui sont postés sur ce fil voient la valeur et les avantages
de docker, l'utilisent quotidiennement, essaient de le promouvoir dans leur
organisations, mais connaissent un problème douloureux et inutile qui
entrave l'adoption.

Pour autant que nous le sachions tous, Docker est encore inconnu de beaucoup de personnes dans la technologie.
surtout au sein de l'entreprise. La documentation aide, mais nous sommes toujours
sauter à travers des cerceaux, et c'est un gros bloqueur avec un négatif global
effet.
Le dimanche 25 janvier 2015 à 17h54, Jay Taylor [email protected] a écrit :

+1, il est actuellement difficile de le configurer et de le faire fonctionner.

@mhamrah https://github.com/mhamrah fait d'excellents arguments. Ne forcez pas
choses, laissez l'utilisateur décider et configurer pour ses propres besoins.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/docker/docker/issues/8887#issuecomment-71398193 .

+1 bon pour essayer rapidement des choses

:+1:

:+1:

Super décevant que nous ne puissions toujours pas extraire de registres non sécurisés sans passer un drapeau au démon docker. C'est juste un autre problème pour chaque nouvelle machine que nous déployons.

+1

Quelques idées:

1. pourrions-nous avoir des caractères génériques de nom d'hôte ? par exemple --insecure-registry=*.internal
2. les certificats auto-signés pourraient-ils être traités différemment de http ?
3. lié à 2, docker pourrait-il faire quelque chose de similaire à SSH et inviter l'utilisateur à accepter un certificat auto-signé chaque fois qu'il en voit un nouveau/se plaindre bruyamment s'il y en a un qui ne correspond pas ?

Et pendant que je fais des suggestions, pourquoi ne pas traiter localhost comme toujours sécurisé ? (comme le fait Chrome)

Edit : ah, je vois que c'est déjà le cas.

+1000 sur ceci.. et +1 sur la fonction de rechargement de la configuration, c'est ce qui rend cela deux fois plus mauvais. Je suis resté avec la v1.2 parce que je pensais qu'un responsable se rendrait compte à quel point l'indicateur --insecure-registry sur le démon est ennuyeux pour le déploiement et le corrigerait, mais d'une manière ou d'une autre, les versions mineures continuent de l'ignorer.

Par exemple, si je devais changer l'adresse IP de mon registre privé pour une raison quelconque, je devrais redémarrer chaque démon docker sur chaque machine virtuelle - simplement parce que mon registre a changé !? Ces 2 choses ne devraient jamais être couplées aussi étroitement. Et dire aux gens d'ajouter simplement 0.0.0.0/8 va à l'encontre de tout l'objectif de la mise en œuvre de la sécurité en premier lieu.

L'ajout de ce drapeau aux commandes push/pull semble si évident en tant que solution de repli pour le drapeau du démon, veuillez m'expliquer pourquoi ils le combattent toujours mais en ajoutant des fonctionnalités "agréables à avoir" en attendant.

Le commentaire de @agquick est juste , en particulier en ce qui concerne les fonctionnalités "agréables à avoir".

Réalisant qu'il s'agit d'une douleur continue pour un nombre substantiel d'utilisateurs, nous reconsidérons l'ajout de --insecure à pull . @ewindisch et moi allons travailler sur un PR que nous

Toutes nos excuses pour la longue attente et merci d'avoir exprimé vos opinions et d'avoir signalé vos points faibles.

@tiborvass Je peux imaginer qu'il y a un nombre tout aussi important d'utilisateurs qui _ne_ veulent pas autoriser les extractions à partir de registres non sécurisés. Je me rends compte que Docker n'a actuellement pas de contrôle précis sur les autorisations/configurations, mais s'il y a une chance de pouvoir "verrouiller" cela, je pense que ce serait une bonne idée.

Oh mon faire ainsi ! J'étais sur le point de le mettre en œuvre moi-même.

Envoyé depuis mon téléphone intelligent BlackBerry 10 sur le réseau Bell.
De : Sebastiaan van Stijn
Envoyé : lundi 23 février 2015 16h53
À : docker/docker
Répondre à : docker/docker
Cc : Kristopher Cieplak
Objet : Re : [docker] --insecure-registry devrait être sur "docker pull" (#8887)

@tibor vasshttps://github.com/tiborvass Je peux imaginer qu'il y a un nombre tout aussi important d'utilisateurs qui ne veulent pas autoriser les extractions à partir de registres non sécurisés. Je me rends compte que Docker n'a actuellement pas de contrôle précis sur les autorisations/configurations, mais s'il y a une chance de pouvoir "verrouiller" cela, je pense que ce serait une bonne idée.

-
Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps: //github.com/docker/docker/issues/8887#issuecomment-75644600.

@thaJeztah J'essaie de comprendre à quel cas d'utilisation vous pensez, cela signifie que nous ne pouvons pas avoir un indicateur --insecure-registry vers docker pull .

• si un utilisateur ne veut pas être accidentellement MITMed sur un registre sécurisé, il peut simplement éviter de passer --insecure-registry
• si un utilisateur veut imposer aux utilisateurs que toutes les images proviennent de registres sécurisés (c'est-à-dire un scénario « d'entreprise »), ils ne peuvent en fait pas appliquer cela du tout pour le moment de toute façon !

Alors, pourriez-vous préciser ce que docker pull --insecure-registry inhibe ?

Pour élaborer sur mon deuxième point, je ne vois pas comment vous verriez cela sans repenser une partie importante du fonctionnement de Docker ! En mettant de côté la possibilité de docker load une archive tar que vous pourriez obtenir en écrivant votre propre extracteur de registre, et en utilisant docker run -v pour escalader les privilèges et ajouter quelque chose aux arguments du démon, il existe un moyen très simple de contourner tout 'mise en vigueur':

$ 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

si un utilisateur veut imposer aux utilisateurs que toutes les images proviennent de registres sécurisés (c'est-à-dire un scénario « d'entreprise »), ils ne peuvent en fait pas appliquer cela du tout pour le moment de toute façon !

C'est le scénario, oui.

Pour développer mon deuxième point, je ne vois pas comment vous verriez cela sans repenser une partie importante du fonctionnement de docker

Je comprends parfaitement que (en ce moment) il n'y a aucun moyen de le verrouiller. Les utilisateurs ayant accès à docker.sock ont effectivement un accès root, ils peuvent donc changer tout ce qu'ils veulent. En outre, ils seraient toujours en mesure de modifier l'indicateur de démon et de redémarrer le démon.

Cependant, cela _donne_ un signal clair à l'utilisateur si docker pull --insecure-registry .. donne une erreur ("Les registres non sécurisés sont désactivés"), qui _informerait_ les utilisateurs que ce n'est pas souhaité, par exemple, lorsqu'ils essaient un exemple qu'ils ont trouvé quelque part.

Alors, cela couvrirait-il tous les cas? Non. Est-ce que ça ferait mal, je ne pense pas non plus.

Personnellement, je pense que cela ferait plus de mal que de bien, simplement parce que cela induit les gens en erreur en pensant « oh regardez, docker applique cela » alors qu'en réalité c'est une protection très superficielle. Je pourrais continuer, mais au final je pense que c'est une question de goût.

Si vous cherchez à savoir à quel point cela pourrait faire mal, faites simplement défiler vers le haut. Il existe une myriade de problèmes UX avec cette approche qui créent des obstacles à l'adoption, et ils sont tous détaillés ci-dessus.

Je vois les problèmes principalement avec docker incapable de redémarrer sans tuer le sous-marin
conteneurs. qui rendent la configuration/reconfiguration beaucoup plus difficile.

Le mer. 15 avril 2015 à 20h11, Jan Krueger [email protected]
a écrit:

+1

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/docker/docker/issues/8887#issuecomment -93362359.

Je suis assez déçu qu'il n'y ait pas encore eu de mesures prises sur ce problème. Cela cause évidemment de la douleur à un certain nombre de personnes.

C'est évidemment ennuyeux pour un grand nombre de personnes, cela bloque activement mon travail en ce moment. Devoir redémarrer le démon Docker pour permettre l'extraction à partir d'un registre non sécurisé va d'ennuyeux à carrément impossible selon la situation dans laquelle vous vous trouvez.

L'argument principal pour ne pas le faire semble être que l'administrateur système devrait pouvoir verrouiller le système et s'assurer que seules les images des dépôts sécurisés peuvent être extraites. Ce cas d'utilisation est bien réel, mais je pense que c'est un mauvais défaut. Il semble beaucoup plus raisonnable d'avoir un indicateur qui peut être passé au démon au démarrage comme --no-insecure qui désactive l'utilisation de --insecure-registry dans pull . De cette façon, un administrateur peut verrouiller les choses s'il le souhaite vraiment.

Pour ceux qui souhaitent vivement ce comportement, je propose la solution de contournement suivante. Je comprends que ce ne sera pas viable pour tous les utilisateurs car il n'utilise pas l'API Docker pour les tirages. C'est aussi un peu lent...

Voir mon projet 'docker-pull' : https://github.com/ewindisch/docker-pull

Vous l'utiliseriez comme tel :

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

Il est également possible d'autoriser tous les registres comme non sécurisés :

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

Je rappellerai qu'il est _toujours_ fortement déconseillé de faire cela.

@ewindisch astucieux hack.

Une autre très bonne solution consiste à utiliser un tunnel TCP :

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

Ce sont deux solutions de contournement fantastiques!

Moi aussi j'aimerais voir la valeur par défaut inversée.

Le 15 avril 2015, à 18h14, Joe Doliner [email protected] a écrit :

Je suis assez déçu qu'il n'y ait pas encore eu de mesures prises sur ce problème. Cela cause évidemment de la douleur à un certain nombre de personnes.

C'est évidemment ennuyeux pour un grand nombre de personnes, cela bloque activement mon travail en ce moment. Devoir redémarrer le démon Docker pour permettre l'extraction à partir d'un registre non sécurisé va d'ennuyeux à carrément impossible selon la situation dans laquelle vous vous trouvez.

L'argument principal pour ne pas le faire semble être que l'administrateur système devrait pouvoir verrouiller le système et s'assurer que seules les images des dépôts sécurisés peuvent être extraites. Ce cas d'utilisation est bien réel, mais je pense que c'est un mauvais défaut. Il semble beaucoup plus raisonnable d'avoir un indicateur qui peut être passé au démon au démarrage comme --no-insecure qui désactive l'utilisation de --insecure-registry dans pull. De cette façon, un administrateur peut verrouiller les choses s'il le souhaite vraiment.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub.

donc cela est rouvert et l'état actuel après 4 mois n'est rien et comme solution de contournement, utilisez un tas de hacks? :-/ Y a-t-il une discussion à ce sujet ailleurs ou est-ce simplement mort?

Et oui, +1

+1

+1

Je tiens à souligner que j'ai compté les instances de "+1" sur cette page, et le nombre s'élève à 31 jusqu'à présent. C'est sans compter les autres commentaires de soutien qui n'incluent pas réellement cette chaîne exacte.

Le problème ici est que l'activation de --insecure sur pull enlève le contrôle à l'administrateur système, auquel il appartient.
La sécurité est difficile, et apporter des modifications pour assouplir la sécurité n'est pas une petite décision.
De plus, les personnes parfaitement satisfaites de la configuration actuelle ne viendront pas ici et -1 non plus.
D'autre part...
Il est trivial de reconfigurer le démon pour activer les extractions non sécurisées à partir d'un registre.
Il est également trivial de configurer des certificats auto-signés et de ne même pas avoir à reconfigurer Docker.

"Sysadmin" est un cas d'utilisation pour docker, mais je "développeur" et "non-sysadmin" sont des cas d'utilisation également valables. Pour un développeur, fournir une option --insecure réduit les frictions dans le flux de travail.

Peut-être pourrions-nous avoir le meilleur des deux mondes en fournissant une option que les administrateurs système pourraient spécifier pour _refuser_ l'utilisation d'une option --insecure . De cette façon, les administrateurs système ont toujours un contrôle total, mais les cas non-administrateurs n'ont pas à gérer la douleur du flux de travail.

Ce qui est trivial pour un administrateur système peut être étonnamment lourd pour les non-administrateurs système. J'ai dû aider près de deux douzaines de développeurs à effectuer (et à refaire) ce changement de configuration sur 5 systèmes d'exploitation différents utilisés dans notre groupe de développement. Je maintiens en fait un script pour automatiser le changement de configuration pour nos environnements.

Nos administrateurs système ne configureront actuellement pas de certificats auto-signés pour notre registre, que ce soit trivial ou non.

De toute façon, même si cela ne change pas, les gens finiront par s'y adapter. Je suppose que la douleur à laquelle je fais face disparaîtra la prochaine fois que nos administrateurs système effectueront la maintenance du registre, car à ce stade, nous devrions être en mesure d'installer de véritables certificats SSL. C'est peut-être tout l'intérêt. Rendez-le plus facile à prendre le chemin sécurisé que le chemin non sécurisé à l'avenir.

:+1: @CleanCut , et tout le monde a tout dit. Je ne travaille qu'avec le cas du développeur et la reconfiguration du démon docker n'est qu'une perte de temps pour nous.

Si vous avez accès au socket docker aujourd'hui, vous _êtes_ un administrateur système. Tu es
root déjà, vous avez "docker load" et avez déjà des solutions de contournement à faire
tirages de registre non sécurisés. L'ajout de l'option image au client ne serait pas
moins sûr que le statu quo.

Il y a cependant quelque chose à dire sur l'augmentation intentionnelle de la
friction pour les développeurs essayant de faire la mauvaise chose dans d'autres pour attirer
les faire faire le bon.
Le 18 juin 2015 à 12h41, "Brian Goff" [email protected] a écrit :

Le problème ici est que l'activation de --insecure on pull enlève le contrôle
de l'administrateur système, auquel il appartient.
La sécurité est difficile, et apporter des modifications pour assouplir la sécurité n'est pas une mince affaire
décision.
De plus, les personnes qui sont parfaitement satisfaites de la configuration actuelle ne vont pas
pour venir ici et -1 ce soit.
D'autre part...
Il est trivial de reconfigurer le démon pour permettre des tirages non sécurisés à partir d'un
enregistrement.
Il est également trivial de configurer des certificats auto-signés et de ne même pas avoir à
reconfigurer le docker.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/docker/docker/issues/8887#issuecomment -113213172.

@ewindisch @tiborvass relisant, je vois https://github.com/docker/docker/issues/8887#issuecomment -75638745;

Réalisant que c'est une douleur continue pour un nombre substantiel d'utilisateurs, nous reconsidérons l'ajout de --insecure à tirer. @ewindisch et moi allons travailler sur un PR que nous
Toutes nos excuses pour la longue attente et merci d'avoir exprimé vos opinions et d'avoir signalé vos points faibles.

Est-ce toujours la position actuelle? (Je ne pense pas qu'un PR ait été créé)

+1

Cela continue de me déranger et de m'agacer au quotidien.

:( triste tête conique.

--inscure prend tout son sens à partir d'un POV de développeur. C'est à la personne qui implémente docker dans son environnement de le sécuriser.

+1

:+1:

_SONDAGE UTILISATEUR_

_La meilleure façon d'être averti lorsqu'il y a des changements dans cette discussion est de cliquer sur le bouton S'abonner en haut à droite._

Les personnes énumérées ci-dessous ont apprécié votre discussion significative avec un +1 aléatoire :

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

+1

+1

+1

Nous utilisons un registre interne dans un réseau fermé, ce qui nous faciliterait le déploiement.

+1

Si ce problème est toujours ouvert d'ici Halloween, je pense que tous les +1 devraient avoir une fête d'anniversaire d'un an pour se noyer dans nos chagrins de docker.

+1 pour la fête du chagrin !

Le 14 septembre 2015, à 13h32, Gordon [email protected] a écrit :

SONDAGE UTILISATEUR

Le meilleur moyen d'être averti lorsqu'il y a des changements dans cette discussion est de cliquer sur le bouton S'abonner en haut à droite.

Les personnes énumérées ci-dessous ont apprécié votre discussion significative avec un +1 aléatoire :

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

-
Répondez directement à cet e-mail ou consultez-le sur GitHub.

+1

+1 pour la fête du chagrin

Cher propriétaire du bot qui dit aux gens d'arrêter d'utiliser "+1":
nous utilisons +1 pour le régler et il n'y a pas grand-chose de plus à dire.

+1

+1

Il existe quelques solutions de contournement, notamment l'utilisation de tunnels SSH, mais cela nécessite des comptes ssh sur l'hôte de registre. La solution de contournement suivante n'en a pas besoin.

Exécutez le redirecteur de port de registre, comme suit :

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

Et puis extrayez ou poussez les images de votre registre local :

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

@rsmoorthy C'est fantastique. Merci de démontrer succinctement la futilité de cette restriction actuelle.

Docker, veuillez ré-inclure cette batterie en particulier.

+1

Je dois dire qu'encourager avec force la sécurité de l'utilisateur a sérieusement influencé mes réflexions sur l'utilisation de docker. Je comprends parfaitement que nous pouvons ajouter le drapeau --insecure-registry au démon au démarrage, et je n'entrerai pas dans toutes les raisons qui ne fonctionnent pas tout le temps, ou qui peuvent être impossibles.

J'ai une question pour les développeurs Docker, pensez-vous vraiment que vous savez ce qui est le mieux pour l'utilisateur final ? Pour ma part, je n'ai pas du tout besoin de SSL sur mes registres, car le réseau sur lequel ils fonctionnent est déjà entièrement crypté. Alors pourquoi diable chiffrerais-je le trafic crypté, est-ce que cela fait vraiment autre chose que d'ajouter des frais généraux et des pièces mobiles à un système déjà complexe et massif ?

Existe-t-il également des cas d'utilisation où les gens utilisent un registre privé sur Internet ? Que fait-on de l'authentification dans ce sens ? Ne pourrait-on pas simplement tirer une image vers le bas puis la déchirer ? Au lieu d'essayer de l'intercepter en route vers un autre ordinateur ?

TL;DR +1

+1

@Supernomad bien dit.

Voyez-le du côté de docker : c'est un problème qu'il vaut mieux ne jamais mettre en œuvre officiellement, mais avec de nombreuses solutions de contournement possibles pour soulager la douleur. Certains utilisateurs crier fort est toujours moins douloureux que le docker marketing de la concurrence qualifiant «d'insécurisé volontairement» et endommageant à jamais sa réputation.
Cela dit, +1.

@tiborvass @ewindisch Ce numéro date de plus d'un an. Cela fait plus de 8 mois que vous avez dit qu'il devait être réévalué. L'avez-vous évalué ? Si oui, qu'est-ce qui a été décidé ? Ne laissez pas un frère pendre ! :-)

Depuis que ce problème a été initialement ouvert, fermé et rouvert, la communauté a proposé de nombreuses façons de le résoudre elle-même, principalement pour démontrer la futilité de ce paramètre par défaut :

• 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

Sans oublier que CoreOS est désormais livré avec --insecure-registry 0.0.0.0/0 par défaut. Ces exemples montrent clairement que l'idée qu'il existe des lignes de séparation des préoccupations entre « l'administrateur système » et le « développeur » est désormais largement arbitraire et fallacieuse en 2015. En fait, l'idée même de conteneurs (dont Docker est leur chef évangéliste) a considérablement accéléré cette tendance à s'éloigner des opérations traditionnelles qui prennent toujours la peine d'appeler quiconque « administrateur système » en premier lieu.

Quoi qu'il en soit, j'adorerais voir cela se fermer pour de bon, d'une manière ou d'une autre.

+1

+1

+1

Pourquoi devrais-je faire confiance à Docker Registry avec ma clé privée SSL ?

Pour les autres utilisateurs de CoreOS laissés pour compte par cette ingérence,
https://coreos.com/os/docs/latest/registry-authentication.html#using -a-registry-without-ssl-configured

@politician n'aurait pas pu mieux le dire moi-même. Il semble très certainement que docker ignore simplement le fait qu'une grande partie de ses utilisateurs sont pour le moins insatisfaits.

Le fait est que je suis en train de migrer complètement loin de docker et je ne pourrais pas être plus heureux de cette décision. J'utilise actuellement git et lxc et non seulement il est plus rapide que docker, mais il me permet en fait de faire ce qui est le mieux pour mon entreprise et non ce qu'une autre entreprise pense, bien que complètement et totalement incorrectement, est le mieux pour moi.

Je suggère fortement de jeter un œil aux alternatives qui sont honnêtement meilleures que docker, telles que rocket, raw lxc, qemu (pas les mêmes mais toujours meilleures) pour n'en nommer que quelques-unes.

Je suggérerai fortement ce plan d'action à tous ceux que je connais qui envisagent désormais des conteneurs. À tout le moins jusqu'à ce que les gens de docker se rendent compte qu'ils n'ont aucune idée, et j'insiste _absolument_ aucune idée, de ce qui est le mieux pour l'utilisateur final en termes de sécurité.

J'ai abandonné et acheté un certificat SSL dédié bon marché. La dépendance de Docker CLI sur le système CA est tout simplement trop forte - les certificats auto-signés ne sont pas seulement frustrants pour le fonctionnement, ils ne fonctionnent tout simplement pas.

• docker-machine supprime votre override ca.crt entre down/up
• aucune de vos images de base n'inclut les outils de création de certificats comme le drone pour CI impossible
• docker CLI utilise un dossier non standard pour les certificats, c'est donc quelque chose d'autre à retenir.
• même si vous le faites fonctionner 18 heures plus tard, vous aurez toujours le sentiment persistant que quelque chose d'autre est cassé

Conclusion : Docker inflige une pénalité continue à votre équipe d'opérations lorsqu'elle tente d'utiliser un certificat auto-signé.

C'est d'autant plus frustrant que curl -k existe depuis l'éternité.

+1

C'est assez triste, qu'ils s'en foutent. Si un développeur veut juste jouer avec docker et héberger son propre environnement, normalement, vous ne voulez pas vous embêter avec les certificats SSL et autres. De plus, si vous avez votre propre serveur à la maison qui est loin d'être public, vous n'avez tout simplement pas besoin de SSL.

@buehler, vous pouvez ajouter l'option --insecure-registry aux paramètres de votre démon ou à votre fichier de configuration daemon.json ; alors vous n'avez besoin de le configurer qu'une seule fois et de tirer sans avoir à spécifier le drapeau

Juste une mise à jour de notre part : nous avons depuis supprimé le registre de notre infrastructure et sommes revenus à l'utilisation de notre fourchette personnalisée de dogestry avec la prise en charge du stockage Azure Blob . Nous avons découvert que Docker Registry dupliquait des couches et que nos machines manquaient d'espace disque, ce qui entraînait des pannes. Le registre s'est avéré être une impasse qui nous faisait perdre du temps.

@buehler juste pour concrétiser la proposition de @thaJeztah , ajoutez cette ligne à la configuration :

--insecure-registry 0.0.0.0/0

Vous pourrez accéder au registre de votre choix. Fonctionne bien pour tester des trucs.

@politician la duplication se produit si les images sont étiquetées avec différents référentiels. L'absence de suppression des blobs est un problème beaucoup plus important.

@thaJeztah si c'est si facile à faire, mais que 80% (nombre certes arbitraire) des utilisateurs doivent le faire, alors s'il vous plaît, faites-en la valeur par défaut.

@justinclayton non ; la définition de cette option dit essentiellement "ignorer tout problème de communication sécurisée avec le registre", donc autoriser les attaques de l'homme du milieu "prêts à l'emploi", ou même le démon se repliant sur non-TLS "http://" . Docker l'a déjà défini comme valeur par défaut pour les registres de la plage 127.x.x.x .

Si vous avez un registre local et que vous ne souhaitez pas générer de certificat pour celui-ci, l'ajout d'un --insecure-registry à vos options de démon prend moins d'une minute. Cependant, cela devrait être une action délibérée, pas quelque chose qui est défini par défaut.

@thaJeztah Je comprends votre argument, mais cela ne peut pas être la fin. Il existe un écart important dans l'expérience utilisateur pour les nouveaux développeurs en raison du fait que cela se trouve du côté des démons. Le scénario _majoritaire_ où cela est pénible est un nouveau développeur qui suit les instructions sur docker.com pour télécharger et exécuter le programme d'installation de Docker Toolbox sur son Mac. À la fin, ils essaient immédiatement d'exécuter docker pull <internally-signed-registry>/foo et sont accueillis par une erreur. C'est le vrai problème. Cela signifie peut-être que ce problème devrait être renommé ?

Il existe de nombreuses autres façons de résoudre ce problème ; Je suis sûr que la communauté et l'entreprise pourraient s'entendre sur l'un d'entre eux :

• Le nom actuel de ce problème est '--insecure-registry should be on "docker pull"'. Comme ce problème est toujours ouvert, je dois supposer que cette option est toujours à l'étude.
• Si une solution à commande unique était fournie (et documentée) qui était simple pour les utilisateurs débutants, cela résoudrait ce problème.
• Dans notre cas, le registre _est_ sécurisé. Il utilise un certificat signé par notre autorité de certification interne comme tout le reste dans notre environnement de construction. C'est une sécurité suffisante. Si le démon était en mesure d'honorer le magasin de certificats de MacOS, cela ferait également disparaître ce casse-tête.
• S'ils étaient invités à ajouter le certificat ou à effectuer cette configuration sur le docker-machine pendant le processus d'installation de Toolbox, ce serait probablement bien aussi.

Veuillez informer les 70+ participants de ce numéro de la direction que vous comptez prendre avec cela, ou bien veuillez simplement fermer le problème afin que nous ne restions pas en suspens. Merci.

@thaJeztah
Il n'y a aucun moyen d'ajouter un seul --insecure-registry aux options de démon sans redémarrer tous les conteneurs en cours d'exécution. C'est l'un des principaux problèmes. Nous ne pouvons pas recharger la configuration sans redémarrer (le problème dure depuis 2013), nous ne pouvons pas extraire d'images d'autres registres non sécurisés sans ajouter d'option au démon et redémarrer également. Et de nos jours, nous n'avons toujours pas de feuille de route claire pour résoudre ce problème.

@apakhomov suppose qu'il pourrait être ajouté à la liste des modifications de configuration pouvant être mises à jour sans redémarrer https://docs.docker.com/engine/reference/commandline/daemon/#configuration -reloading. Pouvez-vous ouvrir un autre numéro pour cela ?

+1.

Certains fournisseurs de PaaS ne donnent pas accès au démon et exploitent un réseau privé pour l'utilisateur (Jelastic par exemple).

est-il possible d'ajouter plusieurs registres non sécurisés à docker ?
quelque chose comme --insecure-registry xxxx:xxxx --insecure-registry zzzz:zzzz

@kkorada --insecure-registry=0.0.0.0/0 fera que Docker se comporte comme avant.

@kkorada oui, vous pouvez spécifier plusieurs registres (le drapeau est --insecure-registry=[] - les crochets indiquent qu'il peut être spécifié plusieurs fois).

Aussi pour docker 1.12, nous allons rendre cette option configurable dans le fichier de configuration daemon.json , sans redémarrer le démon. Voir la demande de tirage ouverte ici : https://github.com/docker/docker/pull/22337

merci @mingfang et @thaJeztah

Comme @mhamrah et @justinclayton l'ont suggéré , je recommanderais également une solution utilisant ssh en plus de TLS, similaire à la façon dont Git permet l'accès à un référentiel utilisant à la fois ssh et TLS. Cela pourrait utiliser la solution de contournement ssh répertoriée par @justinclayton .

Bien que je n'aie aucune donnée pour étayer ma demande, je suppose qu'il y a beaucoup plus de registres privés fonctionnant derrière des pare-feu qu'il n'y a de registres fonctionnant sur l'Internet ouvert. Dans ce cas, ssh est plus facile à configurer et aussi, sinon plus, sécurisé que TLS.

De plus, après m'être battu pendant des jours avec docker push et mon registre local privé s'exécutant dans une machine virtuelle interne suffisamment sécurisée (et plus de temps à lutter pour créer des certificats auto-signés), je viens d'apprécier vraiment rkt --insecure-options=image,tls,http .

C'est fou que ce ne soit pas un paramètre client. Évidemment, il ne devrait pas être activé par défaut car cela encouragerait une pratique non sécurisée. Mettre le paramètre sur le démon le rend cependant très peu pratique à des fins de débogage ou dans des environnements de développement locaux.

Mon cas d'utilisation actuel : exécuter un environnement de développement avec docker compose. L'environnement a besoin d'un registre Docker local. Il est destiné à s'exécuter entièrement sur une machine virtuelle locale.

La méthode docker : expliquer comment configurer docker-machine pour activer un registre non sécurisé sur chaque machine de développeur, les obligeant éventuellement à recréer leur docker-machine s'ils en ont déjà un ou à modifier la configuration à la main.

La solution hacky : socat s'exécutant dans chaque conteneur qui doit utiliser le registre, redirigeant vers localhost.

Pas vraiment pour faciliter les choses...

+1

Vraiment dommage que --insecure ne soit pas une configuration client !
Cela crée beaucoup de douleur pour nous aussi très similaire à la plupart des explications ci-dessus.
Veuillez définir --insecure-registry=0.0.0.0/0 par défaut pour fournir un moyen de le transmettre à la commande docker ainsi qu'aux configurations docker-compose.

+1

+1

Est-il encore temps pour la +1 Pity Party annuelle ?

Le 13 décembre 2016 à 1 h 00, 沙包妖梦[email protected] a écrit :

+1

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub ou coupez le fil de discussion.

Si les couches d'images sont signées, il n'est pas nécessaire d'utiliser CA PKI pour la sécurité. Voir aussi comment fonctionne apt/yum. De plus, l'utilisation de SSL dans un réseau local n'a pas de sens, et dans un environnement cloud, cela signifie que vous devez fournir - en plus des certificats eux-mêmes - une bonne source aléatoire (voir également : https://lukehinds.github.io/2015-03 -03-Entropy-in-the-cloud/).

Pour faire court : si c'est inutile, ne l'imposez pas aux utilisateurs.

Je viens d'ouvrir #29736 qui est lié.

+1, si avoir un indicateur --insecure-registry côté client n'est pas une option, il devrait y avoir un moyen de spécifier un certificat de confiance à utiliser pour docker pull et docker push . Tout le monde n'a pas accès aux certificats de confiance au niveau du système d'exploitation ou à l'accès pour jouer avec le démon Docker.

Les serveurs CI hébergés (qui sont utilisés pour créer des images Docker et pousser vers un registre privé) sont un excellent exemple de cas où vous pourriez ne pas avoir ce niveau d'accès.

+1

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

@tiborvass
Ne fonctionne que si vous avez un accès sudo...

+1 bon moyen de décourager les développeurs d'utiliser docker

+1, j'aimerais voir --insecure-registry pour docker login aussi.

Je ne vois même pas cela comme un problème de sécurité, puisque vous le faites consciemment. Et si une personne non autorisée obtient un accès root, cela ne fournira aucune sécurité non plus. Quel mérite cette restriction a-t-elle réellement ?

Si vous aviez de mauvaises intentions, vous pouvez simplement télécharger votre image docker malveillante sur le DockerHub, qui est fiable.

+1 et franchement c'est ahurissant

+1 au train de la douleur.

Plus un putain de !

Y a-t-il un PR ouvert pour cela?

Pas autant que je sache. Les liens ci-dessus sont générés car certains de mes propres codes font référence à ce problème. Je vais tirer cette référence pendant un moment pour calmer le spam ici.

+1 aussi...

+1

+1 , il est très gênant d'ajouter des paramètres à deamon.json et de redémarrer docker.

Différentes machines ont des systèmes d'exploitation différents. Certains installent docker à partir de yum 、 apt-get , et d'autres directement en utilisant binary . Je dois donc le détecter et redémarrer correctement dockerd....c'est une catastrophe

J'insiste juste sur le fait que docker pull a besoin d' --insecure-registry drapeau

Cela ne fait que trois ans - ne perdons pas espoir maintenant

bosse

+1

+1

L'argument selon lequel cela encourage les utilisateurs à définir leurs registres comme sécurisés n'est pas seulement présomptueux, il manque également un point clé. Cela place les opérations dans une position où de nombreuses personnes doivent avoir accès au compte root pour effectuer leurs opérations, où les registres dockers se déplacent beaucoup.
Ce couplage, du point de vue de la sécurité opérationnelle, crée un plus grand risque de sécurité.

Deuxièmement, dans un réseau privé (comme dans une application hébergée dans le cloud à plusieurs niveaux), la sécurisation des registres n'est pas nécessaire, et complique encore les implémentations technologiques qui reposent sur le dessus, nécessitant des couches de gestion de la sécurité (pour gérer l'authentification Docker automatisée/ refresh) partout où un registre Docker sécurisé est utilisé.

À tout le moins, le démon docker doit être configurable pour AUTORISER la transmission des paramètres de registre non sécurisés. Cela déplace la conception de la sécurité au bon endroit - entre les mains de l'administrateur et en dehors de docker lui-même.

FWIW Je serais satisfait d'une commande pour "ajouter un registre à la liste des registres non sécurisés", car la correction des configurations json à partir des scripts shell est un problème majeur.

+1

:+1: +1

+1

+1

+1

+1

La plupart des implémentations demandées empêcheraient les entreprises utilisant Docker de se conformer aux exigences de conformité SOC, etc.

Il devrait y avoir une solution à cela, mais je ne pense pas qu'il existe une solution simple qui ne soit pas un changement architectural plus radical dans la façon dont les images sont stockées et exécutées.

Pourtant, cela devrait arriver.

Je ne suis plus impliqué dans le développement de Docker, je vais donc me retirer des mentions. Bonne chance à tous ^_^

L'exigence SOC est un bon point. Dans ce cas, cette fonctionnalité doit être ACTIVÉE avec une option de configuration à ajouter à la configuration du docker à l'échelle du système. De cette façon, les exigences SOC peuvent être conservées. Quelque chose comme "ALLOW_INSECURE_REGISTY_OPTION" qui active l'indicateur --insecure-registry sur la ligne de commande docker.

Pour la conformité SOC, l'option ne doit pas être activée.

+1

Cela ne fait que trois ans - ne perdons pas espoir maintenant

5.

Cette proposition (sous sa forme actuelle) est très peu susceptible d'être mise en œuvre, pour divers
raisons, parmi lesquelles;

• il garde la personne qui gère le démon docker responsable de quelles connexions
  le démon est autorisé à faire. notez que cette option peut être "live reloaded",
  il n'est donc pas nécessaire de redémarrer le démon pour modifier la configuration.
• chaque commande ou chemin de code qui interagit potentiellement avec un registre aura
  à modifier ; pas seulement docker pull , mais aussi docker build , docker run ,
  docker plugin , docker service et docker stack , ainsi que
  des orchestrateurs tels que swarmkit, qui extraient des images des nœuds de travail.
• Conformité SOC (comme mentionné ci-dessus)

À tout le moins, le démon docker doit être configurable pour AUTORISER l'insécurité
paramètre de registre à transmettre. Cela déplace la conception de sécurité vers le bon
place - entre les mains de l'administrateur, et en dehors de docker lui-même.

Je pense que l'administrateur dans ce cas serait la personne/l'équipe qui gère le
hôtes sur lesquels le démon docker s'exécute, pas l'utilisateur qui se connecte à la télécommande
API. C'est la raison pour laquelle cette configuration est une configuration démon.

patcher les configurations json à partir de scripts shell est un problème majeur.

C'est un point juste, mais orthogonal à cette discussion. Ce n'est pas impossible_
pour patcher la config JSON, mais a convenu que cela peut être plus compliqué que d'autres
format de fichier. Notez que cette configuration peut également être définie via des indicateurs sur
le démon, qui vous permet d'utiliser un fichier d'unité drop-in systemd pour reconfigurer
le démon.

Quelque chose comme "ALLOW_INSECURE_REGISTY_OPTION" qui active l'indicateur --insecure-registry sur la ligne de commande docker.

Si vous souhaitez autoriser les extractions non sécurisées à partir de n'importe quel registre (ce qui serait l'équivalent
d'ajouter un indicateur --insecure-registry ), vous pouvez autoriser "Internet" comme non sécurisé
enregistrement; ce qui suit devrait permettre à n'importe quelle adresse IPv4 d'être utilisée comme registre non sécurisé,
(donc rabattre sur des connexions non TLS) ;

Via le fichier de configuration /etc/docker/daemon.json ;

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

Ou en passant les options sous forme d'indicateurs sur le démon (qui pourraient être définis dans un systemd
fichier de remplacement);

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