Moby: --insecure-registry debe estar en "docker pull"

Ejecutamos registros de Docker internos no seguros en todos los entornos de producción y CI. Debo decir que sería muy útil simplemente habilitar el acceso a todos los registros inseguros sin tener que enumerarlos uno por uno. Tenemos varios registros en cada entorno para HA. Este cambio nos ha complicado mucho las cosas. Voy a abrir otro ticket de problemas específicamente para abordar eso, ya que este problema es más para mover la opción al pull que al demonio.

Y hay un pequeño problema de la gallina y el huevo cuando no usa un puerto fijo para ejecutar el registro.

Como no sabe qué puerto asignará la ventana acoplable de antemano, realmente no puede iniciar la demostración con una bandera que haga referencia a él.

: +1:

así que supongo que admitir --insecure en la línea de comando docker pull , deshabilitar a la fuerza los controles de seguridad, obviamente para este comando de extracción, también resolvería su problema @proppy y @octalthorpe, ¿verdad? ya que correr con esta bandera no comprobaría las listas en absoluto

@abourget también debe ser compatible con la API remota.

Actualmente, docker-py expone una bandera insecure_registry en la función pull , pero solo se usa para resolver el punto final: https://github.com/docker/docker-py/blob/master/ docker / client.py # L794

El culpable parece ser https://github.com/docker/docker/commit/6a1ff022b0744213ed588d9c16dbb13ce055eda6

Pero no pude encontrar las relaciones públicas correspondientes o los temas en los que se discutió ese cambio.

@tiborvass alguna idea?

@proppy : esto se manejó como una vulnerabilidad de seguridad embargada y no se discutió en un PR público. El equipo central tuvo visibilidad y voto sobre el tema.

Necesito contemplar las implicaciones de tal cambio para localhost / 127.0.0.1, pero no estoy particularmente interesado en eso. Es una configuración poco común y no estándar y la solución está bien documentada.

@ewindisch, por otro lado, ya se está ejecutando una gran cantidad de demonios de docker, con un contenedor de registro que se ejecuta en localhost .

Si, literalmente, todos esos usuarios necesitarán pasar --insecure-registry localhost:5000 , también puede convertirlo en el valor predeterminado.

@ewindisch ¿Tienen documentación u orientación sobre lo que constituye una vulnerabilidad de clase de embargo? Este no es un RCE remoto no autenticado. El peligro aquí no parece lo suficientemente agudo como para justificar un cambio rotundo en un lanzamiento puntual sin previo aviso.

@mmdriley : generalmente se aplica la definición según Mitre / NST. En este caso, es viable un ataque man-in-the-middle que permite la ejecución de código arbitrario no confiable en los sistemas afectados, así que sí, lo clasificamos como un RCE. Esto significa que si usara Docker para extraer imágenes en una computadora portátil en un café, por ejemplo, otro usuario de ese punto de acceso WiFi podría ejecutar aplicaciones arbitrarias proporcionadas por un atacante. También podrían obtener acceso a su cuenta de DockerHub u otros registros en los que se autenticaría.

EDITAR: agregar enlace para la descripción de CVE: https://groups.google.com/d/msg/docker-user/oYm0i3xShJU/0QbAw9eN9qkJ

Sí, me equivoqué al decir que esto no era RCE. Es un error grave y un gran testimonio de por qué la firma robusta de imágenes es una gran idea. Sin embargo, la explotación no es trivial: requiere que un atacante activo pase el rato en Starbucks con la esperanza de que alguien cercano use Docker a través de WiFi inseguro. Esto no se convertirá en un arma de la noche a la mañana y, por lo tanto, no merece un cambio incompatible con versiones anteriores sin advertencia.

Como se sugirió anteriormente, había formas obvias de mejorar la seguridad de inmediato sin romper la compatibilidad. Por ejemplo, deshabilitar el respaldo HTTPS para index.docker.io y un puñado de otros registros públicos populares habría resuelto eficazmente el problema para la mayoría de los usuarios. Agregar una advertencia a la salida de la consola de que se estaba produciendo una reserva HTTP habría mitigado el caso interactivo. El respaldo de HTTP se marcaría en desuso y se eliminaría, digamos, en el lanzamiento del próximo mes. Finalmente, localhost y :: 1 obviamente no son vulnerables.

Una vez más, no debería haber descartado el alcance de la vulnerabilidad, pero me preocupa que el proceso de respuesta y la solución no hayan valido lo suficiente para no perjudicar a los clientes.

Actualmente estamos creando / destruyendo registros de Docker de forma dinámica en un entorno que no tiene FQDN disponible para muchas de estas instancias. Admitir una opción --insecure-repository para solicitudes relacionadas con el registro (a través de una API remota) eliminaría las complicaciones importantes que esta solución de seguridad ha creado para nosotros.

Tenemos un problema similar con Docker 1.3.1. Usamos el registro Docker local (privado) en la dirección http: // docker : 5000 /. Hasta Docker 1.3.0 funcionó bien. Con la versión 1.3.1 de Docker, ya no funciona porque el cliente de Docker asume automáticamente que se puede acceder al Registro en HTTPS. Pero no usamos HTTPS en absoluto.

Sería bueno implementar un mecanismo de respaldo que use HTTP si no se puede acceder a los servidores de Docker Registry a través de HTTPS.

@kruxik, si usa --insecure-registry docker:5000 al iniciar el demonio, recurrirá a HTTP.

@tiborvass gracias por la sugerencia. Estás en lo correcto. Pero si tiene muchos desarrolladores con sus estaciones de trabajo y computadoras portátiles, configurar --insecure-registry en cada estación es una forma poco práctica. Al menos déjelo como parámetro opcional para las operaciones pull / push sería suficiente para nosotros;)

+1

Esto funcionó para nosotros con 1.3.0, pero con 1.3.1

versión docker
....
Versión del servidor: 1.3.1
....
docker push 10.121.4.236:5000/debian7/consul
-> .... Si este registro privado solo admite HTTP o HTTPS con un certificado de CA desconocido, agregue --insecure-registry 10.121.4.236:5000 a los argumentos del demonio. En el caso de HTTPS, si tiene acceso al certificado de CA del registro, no necesita la bandera; simplemente coloque el certificado CA en

Degradar
Versión del servidor: 1.3.0
docker push 10.121.4.236:5000/debian7/consul
-> contenedor sube sin problemas.

Para otros que tienen problemas con 1.3.0 a 1.3.1, tuve que hacer los siguientes cambios para OS X con 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

entonces deberías poder hacer una extracción de la ventana acoplable.

Si usa fig, también necesita Fig 1.0.1 y haga:

$ fig up --allow-insecure-ssl

@mhamrah ¡Gracias! Pasé horas tratando de arreglar esto ...

+1 para asumir que localhost es seguro. ¿Alguien está realmente en contra de esto?

Sí, asumir que localhost es seguro ayudaría mucho. Utilizo vagrant para mi caja acoplable, por lo que actualizar el script de inicio cada vez que destruyo o abro una caja es simplemente ineficiente. Supongo que ahora tendré que hacer títeres en mi ventana acoplable para poder modificar el init en el vagabundo.

También usar una bandera --insecure en el pull and push sería bueno, así que podría usar la IP de vagrant box si fuera necesario.

@thocking : le suponiendo que localhost es seguro: consulte https://github.com/docker/docker/issues/8898

Para ser honesto, también me preguntaba por qué mis Jenkins Containerbuilds automatizados no pudieron presionar ...
(Es bueno tener un testenv. Antes de ponerlo en producción).
Tengo que comprobar si esta "característica" fue realmente anunciada; si no, estaré más paranoico ante cambios tan extremos y masivos en el comportamiento de los demonios.

Lo que extraño en esta discusión:
¿Por qué incluso tengo que decirle al demonio que use el modo seguro / no seguro "predeterminado" para cada host?

¿No debería ser más productivo configurar el registro con este comportamiento predeterminado?
Entonces, dependiendo de la configuración, si no se proporciona ningún parámetro --secure o --insecure, el demonio debe solicitar
si es posible la forma segura y si no, se utilizó la alternativa no segura.

Una de las cosas principales de Docker es que es completamente fácil de usar y configurar un env completo. por favor no mates este efecto WOW con tales "lanzamientos / decisiones" ...

solo mis 2 centavos ...

Problemas similares aquí a los anteriores, incluido @jwthomp. Pasé más de 10 horas tratando de resolver este problema y, mientras tanto, he cambiado a Docker 1.3.0.

Actualmente estoy ejecutando el registro de Docker en Marathon y el registro de Docker "admite SSL al ejecutar nginx como interfaz" (consulte https://github.com/docker/docker-registry/issues/697) pero usar nginx como interfaz es Complicado por Marathon que ejecuta el registro de la ventana acoplable en varios hosts / puertos esclavos.

Podría habilitar SSL directamente dentro del registro (usando GUNICORN_OPTS) pero luego _sólo_ habla SSL y no puede pasar las verificaciones de salud de Marathon.

Modifiqué el sistema de configuración de Bamboo HAProxy para configurar también HAProxy como una interfaz https para todos los servicios de la forma en que lo hubiera hecho nginx, pero todavía tengo problemas con la ventana acoplable que valida el certificado en mi registro privado, por lo que todavía no es posible. yo en este momento.

Está muy bien protegerse contra RCE, pero también es necesario que exista alguna compatibilidad con versiones anteriores. Al menos una marca para que el demonio de la ventana acoplable especifique todos los registros como inseguros. Debe haber una forma de especificar http o https como parte del nombre del registro en cada comando de extracción de la ventana acoplable. Por el momento, 1.3.1 parece un gran Catch-22 para cualquiera que use un registro privado.

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

Bonito.
El viernes 14 de noviembre de 2014 a las 10:42 a.m. Ilya Radchenko [email protected]
escribió:

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

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/docker/docker/issues/8887#issuecomment -63082089.

@mhamrah No

Frio. Tuve problemas incluso para entrar, supongo que debido a alguna versión
desajuste entre las iso de Docker. De hecho, cambié a usar vagrant +
coreos para el soporte de Docker, y funciona bien. Solo necesitas configurar
DOCKER_HOST, que boot2docker hace automáticamente.

El jueves 20 de noviembre de 2014 a las 1:52:21 a. M. Kayvan Sylvan [email protected]
escribió:

@mhamrah https://github.com/mhamrah No tuve que hacer la eliminación de
las claves ssh, etc. Acabo de agregar la línea necesaria en
/ var / lib / boot2docker / profile y reinició la ventana acoplable. ¡Gracias por el consejo!

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/docker/docker/issues/8887#issuecomment -63768043.

Lo siento chicos, quería responder antes.

Como ya dijo @ewindisch , no queremos fomentar este comportamiento del lado del cliente. El dolor inducido por requerir el indicador como indicador de demonio es que las personas realmente configuran TLS en su registro. De lo contrario, no hay ningún incentivo. Gracias por su comprensión.

Hay una imagen "oficial" basada en la ventana acoplable del registro de la ventana acoplable en el registro oficial de la ventana acoplable. Su uso recomendado es sin TLS.

Si Docker quisiera que los usuarios configuraran TLS en su registro, ¿no tendría sentido equilibrar el "dolor inducido" con una "reducción del dolor" igual y opuesta al proporcionar una imagen oficial de Docker que por defecto proporcione TLS?

@tiborvass . Está ignorando el caso de desarrollo interno detrás del firewall. Así que ahora tengo que configurar un proxy inverso con SSL habilitado frente a mi registro (simplemente no hay razón para hacer esto) o tengo que ir a todos y cada uno de mis desarrolladores y modificar los argumentos del demonio en ejecución. dentro de boot2docker. Esto no tiene sentido. Hay muchos entornos de desarrollo que proporcionan seguridad configurable en los que la seguridad a menudo está deshabilitada para entornos de desarrollo. Me sorprende verlo cerrar este tema cuando ha habido tantos votos a favor de una solución.

¿Qué hay de incluir en la lista blanca todos los ips privados? ¿Terreno medio?

O hacer que el nombre del protocolo, 'http' o 'https' forme parte del nombre de la imagen para la extracción.

@tiborvass tanto @sroebuck como @blevine hacen grandes puntos. Este se convertirá cada vez más en el escenario para las tiendas que construyen contenedores internamente, y la furia por romper el flujo de trabajo anterior también aumentará. Todos entendemos el lado de la seguridad de esto, y tal vez pull no sea el lugar adecuado para resolverlo, pero siempre que la imagen del registro oficial no proporcione una forma simple y lista para hacer frente a este cambio, debería ser considerado un problema de UX bastante importante a resolver.

¡Hola @tiborvass ! Este problema también nos está afectando en este momento. Prefiero el enfoque de @nickandrew . Sería un poco más como git clone y también abriría la posibilidad de diferentes protocolos conectables en el futuro. Una ventaja para Docker, ya que reduciría el acoplamiento y una ventaja para la comunidad.

@blevine tenga en cuenta que a partir de 1.3.2 localhost está en la lista blanca de forma predeterminada, consulte: https://github.com/docker/docker/pull/9124

Puede hacer que el registro escuche en localhost pasando: -p 127.0.0.0:5000:5000 a docker run

@proppy , no estoy muy seguro de cómo me ayuda escuchar en localhost.

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

¿O debería convertirse en una URL real? No sé nada sobre el protocolo de registro, pero no parece incompatible extender la sintaxis actual para especificar una URL adecuada.

@blevine significa que puede configurar un registro de duplicación local.

Arg, ahora tengo que decodificar en base64 mi configuración de nube para que coreos haga que mis máquinas se inicien

@tiborvass Vaya, esto es realmente desafortunado. :(

Tenemos clústeres de desarrollo que subimos y bajamos sobre la marcha y parte de cómo manejamos estos clústeres es crear un registro para ese clúster. Un clúster puede estar formado por muchos nodos físicos o vms, y también puede estar en una computadora de escritorio o en una computadora portátil de los desarrolladores (aunque normalmente no podemos lanzar una pila completa). Cada clúster es un entorno de desarrollo y pila totalmente autónomo. También tenemos herramientas de línea de comandos basadas en Docker que permiten a un desarrollador interactuar con cualquier configuración de clúster de desarrollo en la empresa.

En este tipo de entorno complejo y dinámico, hacer que TLS en un registro sea un requisito es un dolor gigantesco. Tener que modificar el inicio del demonio de la ventana acoplable cada vez que configuramos, agregamos una nueva red en la que podría estar un registro es igualmente un dolor.

No me malinterpretes, aprecio el pensamiento detrás de querer admitir TLS exclusivamente, sin embargo, te animo a que consideres que hay casos válidos en los que el entorno respalda de manera segura la eliminación de la complejidad de TLS para la reducción del dolor y la infraestructura necesaria para respaldar eso.

@tiborvass +1. +1000. Esto ha generado una complejidad absolutamente innecesaria para
nosotros a un flujo de trabajo de desarrollo altamente dinámico. La barrera de entrada ha sido
planteado significativamente aquí para algo que solo necesita aplicarse en un
contexto de producción. Por favor, termine con nuestro dolor.

El martes 9 de diciembre de 2014, Jeff Thompson [email protected]
escribió:

@tiborvass https://github.com/tiborvass Wow, este es uno de esos
Momentos de cambio de mesa virtual tristemente. :(

Tenemos grupos de desarrollo que subimos y bajamos sobre la marcha y parte
De cómo manejamos estos clústeres es que creamos un registro para ese clúster. A
El clúster puede ser de muchos nodos físicos o vms, y también puede estar en un
computadora de escritorio o computadora portátil de los desarrolladores (aunque normalmente no podemos iniciar una
completa pila). Cada clúster es una pila y un desarrollo totalmente autónomos
medio ambiente. También tenemos herramientas de línea de comandos basadas en Docker que permiten un
desarrollador para interactuar con cualquier configuración de clúster de desarrollo en la empresa.

En este tipo de entorno complejo y dinámico, hacer TLS en un registro
un requisito es un dolor gigantesco. Tener que modificar el inicio del demonio de la ventana acoplable
Cada vez que configuramos, agregamos una nueva red en la que podría estar un registro.
igualmente un dolor.

No me malinterpretes, agradezco el pensamiento detrás del deseo de apoyar
TLS, sin embargo, hay casos en los que el entorno admite de forma segura la eliminación
la complejidad de TLS para la reducción del dolor y la infraestructura necesaria
para apoyarlo.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/docker/docker/issues/8887#issuecomment -66367681.

@justinclayton @jwthomp @mattwilliamson @nickandrew @blevine

¿ --insecure-registry 0.0.0.0/8 resuelve su problema? De esa manera, aún puede usar HTTP.

Esta notación CIDR puede usarse de manera más granular para habilitar configuraciones "detrás del firewall" especificando rangos como "--insecure-registry 172.16.0.0/12". No recomiendo usar esta opción en absoluto, pero sí recomiendo que los usuarios que eligen esta opción usen un rango más selectivo (como su espacio de IP) en lugar de todas las direcciones posibles con 0.0.0.0/8.

El demonio de la ventana acoplable está integrado en coreos, por lo que de alguna manera tengo que agregar esos indicadores al inicio en todo el clúster. Creo que es mucho más flexible tenerlo en el comando de extracción para entornos en los que no se puede controlar el demonio de la ventana acoplable.

Es el equivalente a decirnos que cambiemos un archivo php.ini por un host php compartido.

El 9 de diciembre de 2014, a las 22:18, Tibor Vass [email protected] escribió:

@justinclayton @jwthomp @mattwilliamson @nickandrew @blevine

¿No soluciona --insecure-registry 0.0.0.0/8 su problema? De esa manera, aún puede usar HTTP.

-
Responda a este correo electrónico directamente o véalo en GitHub.

Los indicadores de ejecución de

En el sitio web de CoreOS encontrará ejemplos de cómo cambiar la configuración de Docker. Se podrían modificar fácilmente las instrucciones para agregar un indicador de depuración para especificar un indicador de registro inseguro en su lugar.

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

@tiborvass todo el ecosistema de configuración debe respaldar esto para que funcione fácilmente desde el primer momento. Las personas no esperan realizar personalizaciones no estándar para el inicio del demonio en todos los lugares donde puedan estar tirando (boot2docker, coreos, cualquier cosa instalada con los módulos chef / puppet, etc.) cuando pasan al paso de configurar su propio registro interno. La imagen del contenedor del registro oficial en sí _ ya no funciona_ cuando se siguen los pasos marcados como "recomendados" en el archivo Léame. El archivo Léame no menciona TLS en absoluto, de hecho, y configurar esto no es un proceso trivial. Además, como @mattwilliamson mencionó brevemente anteriormente, existen innumerables casos, como entornos de compilación compartidos, en los que alguien que usa el demonio para extraer una imagen no es lo mismo que la persona que configura el demonio.

La conclusión es que hacer de esto un argumento del lado del cliente es claramente la solución menos disruptiva y, lo que es más importante, la solución menos prescriptiva. Docker ya se ha convertido en un elemento primitivo en docenas, si no cientos, de otros proyectos y flujos de trabajo y, como tal, realmente no debería dictar patrones de uso en este ámbito. El hecho de que Git ofrezca una opción de configuración de tiempo de ejecución simple para deshabilitar http.sslverify no significa que Linus Torvalds aliente a las personas a no proteger sus datos confidenciales en contextos donde es importante hacerlo.

La analogía de git es un buen ejemplo de cómo debería funcionar. Git no lo obliga a usar TLS, y es decisión del usuario al configurar un host qué nivel desea admitir. También es decisión del usuario a la hora de determinar el nivel de seguridad que requiere (o desea omitir). La configuración es un paso simple, ya sea globalmente o por repositorio. Aunque Docker no nos obliga a usar TLS, al hacer que la alternativa no sea trivial, no ofrece otras opciones razonables.

La notación CIDR permite un enfoque posiblemente de "martillo pesado", y AFAIK, no se asigna a los nombres de DNS, por lo que incluso si enmascara un 10.0.0.0/16, tirando some.private-registry.com en un 10.0 / 16 won ' t trabajo. Más importante aún, la configuración no es trivial.

Docker prospera en su simplicidad para la contenedorización y reduce en gran medida la barrera para implementar aplicaciones en una variedad de entornos. Todos conocemos los beneficios. La mayoría de los desarrolladores no pueden responder preguntas simples de notación CIDR, el archivo de configuración de la ventana acoplable puede estar en lugares no estándar (las ubicaciones de boot2docker y CoreOS son diferentes a otras distribuciones), y es bastante fácil estropear estos archivos de configuración con bucles de retroalimentación difíciles para éxito. ¿Tengo que seguir syslog? Oh, espera, ¿estoy en RHEL y sus mensajes?

Un nuevo desarrollador puede copiar y pegar fácilmente un fragmento de docker pull , pero si lo hace ssh en un host boot2docker, ejecuta vi, edita un archivo de configuración, luego rastrea un syslog en busca de errores ... no tanto. Y sí, olvidó reiniciar el demonio de la ventana acoplable.

Esto es lo que me gustaría ver:

• Configuración del demonio de Docker aplicada a través del comando de Docker
• Configuración de extracción de Docker para anulaciones de TLS, especificada mediante el comando de Docker
• La configuración de extracción de Docker se conserva en los comandos para registros específicos

Sí, pero Amazon no le permite cambiar una configuración de escala automática. Tendré que hacer una copia o hacer una nueva.

El 9 de diciembre de 2014, a las 23:55, Eric Windisch [email protected] escribió:

Los indicadores de ejecución se pueden configurar con CoreOS. Puede editar el archivo de configuración de systemd para Docker. Para configurar esto para un clúster, puede usar cloud-config.

En el sitio web de CoreOS encontrará ejemplos de cómo cambiar la configuración de Docker. Se podrían modificar fácilmente las instrucciones para agregar un indicador de depuración para especificar un indicador de registro inseguro en su lugar.

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

-
Responda a este correo electrónico directamente o véalo en GitHub.

Actualmente tengo que solucionar este problema en el entorno de desarrollo de mi empresa ejecutando este comando minuciosamente investigado cada vez que hago '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"'

Que dolor. La adopción de la ventana acoplable dentro de mi empresa de más de 400 personas está estancada debido a este problema. No tenemos absolutamente ningún uso para TLS en nuestro entorno de desarrollo interno donde todo está controlado. Aplaudimos su uso para repositorios de concentradores públicos, y creemos que forzar eso en otros lugares en todos los casos es un gran error.

@CleanCut muy bien dicho. Estaba realmente decepcionado de que 1.4.0 apareciera y se fuera y este problema permanece abierto.

@CleanCut awesome - Lo que me gustaría en boot2docker es que agregue más información a la carga útil inicial boot2docker init , que luego haría esto por ti.

no resuelve los problemas específicos de boot2docker no basados ​​en VM, pero --insecure-registry no es la única personalización específica del sitio que desean los usuarios de b2d.

¿Puede hacer una solicitud de extracción o un problema para esto en el repositorio de boo2docker, por favor?

Realmente levanta la barrera para que alguien use un proyecto aplaudido por bajar barreras.

El 13 de diciembre de 2014, a las 02:10, Justin Clayton [email protected] escribió:

@CleanCut muy bien dicho. Estaba realmente decepcionado de que 1.4.0 apareciera y se fuera y este problema permanece abierto.

-
Responda a este correo electrónico directamente o véalo en GitHub.

@SvenDowideit Seguro. Aquí está

Parece que hay consenso en este hilo de que este no es un problema resuelto; ¿Podríamos reabrir este problema?

¡Sí, por favor!
Le 2014-12-15 15:05, "Justin Clayton" [email protected] a écrit:

Parece que hay consenso en este hilo de que esto no está resuelto
problema; ¿Podríamos reabrir este problema?

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/docker/docker/issues/8887#issuecomment -67055878.

+1. No tengo nada que agregar, pero quiero simplemente desahogar mi frustración por esta decisión. Como todos los demás, estoy ejecutando un registro en una red local donde la seguridad se maneja hasta la saciedad en otros lugares. Tengo docenas de contenedores docker en ejecución que ahora deben rebotarse para agregar el indicador 'bien documentado'.

@bfirsh : este es uno de esos ejemplos en los que un archivo de configuración de demonio de Docker y un kill -HUP <dockerdaemonpid> serían increíbles: actívelo para volver a leer el cfg, sin necesidad de reiniciarlo, evitando así el reinicio del contenedor.

@SvenDowideit +1 para la función de recarga, es realmente molesto reiniciar el servidor mediante una configuración simple.

+1

Perdóneme si no entiendo las cosas correctamente, pero parece que este problema está en la raíz de mi propio escenario (similar al descrito por @blevine donde mi empresa tiene un proxy de reescritura de certificados que hace que no pueda incluso hablar con el Docker Hub Registry público). Sé que eventualmente querré configurar mi propio registro privado, pero estoy en la fase de aprendizaje, donde aún no estoy seguro de si adoptaré Docker. Esta es una pesadilla de UX para alguien en las primeras etapas de adopción.

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

+1 para reabrir esta discusión, porque parece que la comunidad no está muy contenta con la solución actual.

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

tratando de abordar esto desde todos los ángulos hasta que escuchemos una respuesta definitiva sobre este tema.

+1, esto es actualmente difícil de configurar y trabajar.

@mhamrah hace grandes puntos. No fuerce las cosas, deje que los usuarios decidan y configuren según sus propias necesidades.

Los registros que utilizan certificados autofirmados también son un problema, especialmente
en un contexto de desarrollador usando boot2docker que cambió a un archivo de solo lectura
sistema. Esto requiere un paso de configuración adicional y diferente para
arranca la máquina virtual en ejecución.

Creo que todos los que publican en este hilo ven el valor y el beneficio
de Docker, lo utilizan a diario, intentan promocionarlo en sus
organizaciones, pero están experimentando un problema doloroso e innecesario que
obstaculiza la adopción.

Por mucho que todos sabemos, Docker todavía es desconocido para muchas personas en tecnología.
especialmente dentro de la empresa. La documentación ayuda, pero todavía estamos
saltar a través del aro, y es un gran bloqueador con un resultado general negativo
efecto.
El domingo, 25 de enero de 2015 a las 5:54 p. M., Jay Taylor [email protected] escribió:

+1, esto es actualmente difícil de configurar y trabajar.

@mhamrah https://github.com/mhamrah hace grandes puntos. No fuerces
cosas, deje que el usuario decida y configure según sus propias necesidades.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/docker/docker/issues/8887#issuecomment -71398193.

+1 bueno para probar cosas rápidamente

: +1:

: +1:

Es muy decepcionante que todavía no podamos extraer de registros inseguros sin pasar una bandera al demonio de la ventana acoplable. Esta es solo otra molestia para cada nueva máquina que implementamos.

+1

Algunos pensamientos:

1. ¿Podríamos tener comodines de nombre de host? por ejemplo, --insecure-registry=*.internal
2. ¿Los certificados autofirmados podrían tratarse de forma diferente a http?
3. relacionado con 2, ¿podría Docker hacer algo similar a SSH y pedirle al usuario que acepte un certificado autofirmado cada vez que vea uno nuevo / quejarse en voz alta si hay uno que no coincide?

Y mientras hago sugerencias, ¿por qué no tratar a localhost como siempre seguro? (como lo hace Chrome)

Editar: ah, veo que ya lo es.

+1000 en esto ... y +1 en la función de recarga de configuración, eso es lo que hace que esto sea dos veces peor. Me quedé con v1.2 porque pensé que seguramente un mantenedor se daría cuenta de lo molesto que es el indicador --insecure-registry en el demonio para la implementación y lo arreglaría, pero de alguna manera las versiones menores siguen ignorándolo.

Por ejemplo, si tuviera que cambiar mi IP de registro privado por cualquier motivo, tendría que reiniciar cada daemon de la ventana acoplable en cada VM, ¿¡solo porque mi registro cambió !? Esas 2 cosas nunca deberían estar tan estrechamente acopladas. Y decirle a la gente que simplemente agregue 0.0.0.0/8 anula todo el propósito de la implementación de seguridad en primer lugar.

Agregar esta bandera a los comandos push / pull parece tan obvio como una alternativa para la bandera del demonio, por favor, alguien me explique por qué todavía lo están combatiendo pero agregando características "agradables de tener" mientras tanto.

El comentario de @agquick es

Al darnos cuenta de que esto es un dolor continuo para una cantidad sustancial de usuarios, estamos reconsiderando agregar --insecure a pull . @ewindisch y yo trabajaremos en un PR que

Disculpas por la larga espera y gracias por expresar tus opiniones y señalar tus puntos débiles.

@tiborvass Me imagino que hay una cantidad igualmente grande de usuarios que _no_ quieren permitir extracciones de registros inseguros. Me doy cuenta de que Docker actualmente no tiene un control detallado sobre los permisos / configuración, pero si existe la posibilidad de poder "bloquear" esto, creo que sería un buen toque.

¡Oh, hazlo así! Estaba a punto de implementarlo yo mismo.

Enviado desde mi smartphone BlackBerry 10 en la red Bell.
Desde: Sebastiaan van Stijn
Enviado: lunes 23 de febrero de 2015 a las 4:53 p.m.
Para: Docker / Docker
Responder a: ventana acoplable / ventana acoplable
Cc: Kristopher Cieplak
Asunto: Re: [docker] --insecure-registry debe estar en "docker pull" (# 8887)

@tibor vasshttps: //github.com/tiborvass Me imagino que hay una cantidad igualmente grande de usuarios que no quieren permitir extracciones de registros inseguros. Me doy cuenta de que Docker actualmente no tiene un control detallado sobre los permisos / configuración, pero si existe la posibilidad de poder "bloquear" esto, creo que sería un buen toque.

-
Responda a este correo electrónico directamente o véalo en Gi

@thaJeztah Estoy tratando de averiguar en qué caso de uso estás pensando que significa que no podemos tener una bandera --insecure-registry en docker pull .

• si un usuario no quiere ser MITMed accidentalmente en un registro seguro, puede simplemente evitar pasar --insecure-registry
• Si un usuario quiere hacer cumplir a los usuarios que todas las imágenes provienen de registros seguros (es decir, un escenario 'empresarial'), ¡de todos modos no pueden hacer cumplir esto en absoluto en este momento!

Entonces, ¿podría explicar qué inhibe docker pull --insecure-registry ?

Para desarrollar mi segundo punto, no veo cómo bloquearías esto sin repensar una cantidad significativa de cómo funciona la ventana acoplable. Dejando de lado la posibilidad de docker load un tarball que podría obtener escribiendo su propio extractor de registro, y usando docker run -v para escalar privs y agregar algo a los argumentos del demonio, hay una manera muy simple de omitir cualquier 'aplicación':

$ 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 usuario quiere hacer cumplir a los usuarios que todas las imágenes provienen de registros seguros (es decir, un escenario 'empresarial'), ¡de todos modos no pueden hacer cumplir esto en absoluto en este momento!

Este es el escenario, sí.

Para desarrollar mi segundo punto, no veo cómo bloquearías esto sin repensar una cantidad significativa de cómo funciona la ventana acoplable.

Entiendo completamente que (en este momento) no hay forma de bloquearlo. Los usuarios que tienen acceso a docker.sock tienen acceso de root de manera efectiva, por lo que pueden cambiar lo que quieran. Además, aún podrían cambiar la bandera del demonio y reiniciar el demonio.

Sin embargo, _ sí_ da una señal clara al usuario si docker pull --insecure-registry .. da un error ("Los registros inseguros están deshabilitados"), que _ notificaría a los usuarios que no es deseado, por ejemplo, cuando prueben algún ejemplo que encuentren. algun lado.

Entonces, ¿cubriría todos los casos? No. Me dolería, yo tampoco lo creo.

Personalmente, creo que haría más daño que bien, simplemente porque induce a error a la gente a pensar "oh, mira, Docker hace cumplir esto" cuando en realidad es una protección muy superficial. Podría seguir, pero al final creo que se trata de una cuestión de gustos.

Si está buscando cómo podría doler, simplemente desplácese hacia arriba. Hay innumerables problemas de UX con este enfoque que crean barreras para la adopción, y todos se detallan anteriormente.

Veo los problemas principalmente con la ventana acoplable que no se puede reiniciar sin matar a sub
contenedores. que hacen que configurarlo / reconfigurarlo sea mucho más difícil.

El miércoles 15 de abril de 2015 a las 8:11 p.m., Jan Krueger [email protected]
escribió:

+1

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/docker/docker/issues/8887#issuecomment -93362359.

Estoy bastante decepcionado de que aún no se hayan tomado medidas sobre este tema. Obviamente, está causando dolor a varias personas.

Obviamente, es molesto para una gran cantidad de personas, está bloqueando activamente mi trabajo en este momento. Tener que reiniciar el demonio de Docker para permitir la extracción de un registro inseguro varía de molesto a absolutamente imposible dependiendo de la situación en la que se encuentre.

El principal argumento para no hacer esto parece ser que el administrador del sistema debería poder bloquear el sistema y asegurarse de que solo se puedan extraer imágenes de repositorios seguros. Ese caso de uso es definitivamente real, pero creo que tiene un mal valor predeterminado. Parece mucho más razonable tener una bandera que se pueda pasar al demonio al inicio como --no-insecure que deshabilita el uso de --insecure-registry en pull . De esa manera, un administrador puede bloquear las cosas si realmente lo desea.

Para aquellos que desean este comportamiento, les ofrezco la siguiente solución. Entiendo que no será viable para todos los usuarios ya que no usa la API de Docker para extracciones. También es algo lento ...

Ver mi proyecto 'docker-pull': https://github.com/ewindisch/docker-pull

Lo usarías como tal:

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

También es posible permitir que todos los registros sean inseguros:

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

Les recordaré que _todavía_ es muy desaconsejable hacer esto.

@ewindisch ingenioso truco.

Otra solución bastante buena es usar un túnel 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

¡Ambas son soluciones fantásticas!

A mí también me gustaría que se invirtiera el valor predeterminado.

El 15 de abril de 2015, a las 6:14 p.m., Joe Doliner [email protected] escribió:

Estoy bastante decepcionado de que aún no se hayan tomado medidas sobre este tema. Obviamente, está causando dolor a varias personas.

Obviamente, es molesto para una gran cantidad de personas, está bloqueando activamente mi trabajo en este momento. Tener que reiniciar el demonio de Docker para permitir la extracción de un registro inseguro varía de molesto a absolutamente imposible dependiendo de la situación en la que se encuentre.

El principal argumento para no hacer esto parece ser que el administrador del sistema debería poder bloquear el sistema y asegurarse de que solo se puedan extraer imágenes de repositorios seguros. Ese caso de uso es definitivamente real, pero creo que tiene un mal valor predeterminado. Parece mucho más razonable tener un indicador que se pueda pasar al demonio al iniciar como --no-inseguro que deshabilita el uso del registro --inseguro en pull. De esa manera, un administrador puede bloquear las cosas si realmente lo desea.

-
Responda a este correo electrónico directamente o véalo en GitHub.

así que esto se vuelve a abrir y el estado actual después de 4 meses no es nada y, como solución, ¿usa un montón de trucos? : - / ¿Hay alguna discusión sobre esto en otros lugares o simplemente está muerto?

Y si, +1

+1

+1

Me gustaría señalar que conté las instancias de "+1" en esta página, y el recuento llega a 31 hasta ahora. Eso sin contar los otros comentarios de apoyo que en realidad no incluyen esa cadena exacta.

El problema aquí es que habilitar --insecure en la extracción le quita el control al administrador del sistema, al que pertenece.
La seguridad es difícil y hacer cambios para aflojar la seguridad no es una decisión pequeña.
Además, las personas que están perfectamente satisfechas con la configuración actual no van a venir aquí y -1 esto tampoco.
Por otra parte...
Es trivial reconfigurar el demonio para habilitar extracciones inseguras de un registro.
También es trivial configurar algunos certificados autofirmados y ni siquiera tener que volver a configurar la ventana acoplable.

"Sysadmin" es un caso de uso para Docker, pero yo "desarrollador" y "no administrador de sistemas" son casos de uso igualmente válidos. Para un desarrollador, proporcionar una opción --insecure reduce la fricción en el flujo de trabajo.

Quizás podríamos tener lo mejor de ambos mundos proporcionando una opción que los administradores de sistemas podrían especificar para _negar_ el uso de una opción --insecure . De esa manera, los administradores de sistemas todavía tienen el control total, pero los casos que no son administradores de sistemas no tienen que lidiar con el dolor del flujo de trabajo.

Lo que es trivial para un administrador de sistemas puede resultar sorprendentemente engorroso para los que no son administradores de sistemas. Tuve que ayudar a casi dos docenas de desarrolladores a realizar (y rehacer) este cambio de configuración en 5 sistemas operativos diferentes utilizados en nuestro grupo de desarrollo. De hecho, mantengo un script para automatizar el cambio de configuración para nuestros entornos.

Nuestros administradores de sistemas no configurarán certificados autofirmados para nuestro registro, ya sea que sea trivial o no.

De todos modos, incluso si esto no cambia, eventualmente la gente se adaptará a ellos. Supongo que el dolor con el que estoy lidiando desaparecerá la próxima vez que nuestros administradores de sistemas realicen mantenimiento en el registro, porque en ese momento deberíamos poder instalar certificados SSL reales. Quizás ese sea el punto. Haga que sea más fácil tomar el camino seguro que el camino inseguro en el futuro.

: +1: @CleanCut , y todos los demás lo dijeron todo. Solo trabajo con el caso del desarrollador y reconfigurar el demonio de la ventana acoplable es solo una pérdida de tiempo para nosotros.

Si tiene acceso al conector de la ventana acoplable hoy, es _un_ administrador de sistemas. Estás
root ya, tiene "carga de la ventana acoplable" y ya tiene soluciones para hacer
extracciones de registro inseguras. Agregar la opción de imagen al cliente no sería
menos seguro que el status quo.

Sin embargo, hay algo que decir acerca de aumentar intencionalmente la
fricción para los desarrolladores que intentan hacer algo incorrecto en otros para atraer
que hagan lo correcto.
El 18 de junio de 2015 a las 12:41 p. M., "Brian Goff" [email protected] escribió:

El problema aquí es que habilitar --insecure on pull quita el control
desde el administrador del sistema, donde pertenece.
La seguridad es difícil y hacer cambios para aflojar la seguridad no es una tarea pequeña.
decisión.
Además, las personas que están perfectamente satisfechas con la configuración actual no van a
para venir aquí y -1 esto tampoco.
Por otra parte...
Es trivial reconfigurar el demonio para habilitar extracciones inseguras de un
registro.
También es trivial configurar algunos certificados autofirmados y ni siquiera tener que hacerlo
Vuelva a configurar Docker.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/docker/docker/issues/8887#issuecomment -113213172.

@ewindisch @tiborvass leyendo, veo https://github.com/docker/docker/issues/8887#issuecomment -75638745;

Al darnos cuenta de que esto es un dolor continuo para una cantidad sustancial de usuarios, estamos reconsiderando agregar --insecure to pull. @ewindisch y yo trabajaremos en un PR que
Disculpas por la larga espera y gracias por expresar tus opiniones y señalar tus puntos débiles.

¿Sigue siendo esa la posición actual? (No creo que se haya creado un PR)

+1

Esto sigue molestándome y molestándome a diario.

:( triste cabeza de cono.

--inscure tiene mucho sentido desde un punto de vista de desarrollador. Depende de la persona que implemente la ventana acoplable en su entorno para que sea seguro.

+1

: +1:

_ ENCUESTA DE USUARIOS_

_La mejor manera de recibir una notificación cuando haya cambios en esta discusión es haciendo clic en el botón Suscribirse en la parte superior derecha.

Las personas que se enumeran a continuación han apreciado su discusión significativa con un +1 aleatorio:

@justinclayton
@anandkumarpatel
@ tangr1
@ fred4jupiter
@mingfang
@djannot
@Frusty
@ tobegit3hub
@testacuentaspivey
@mhamrah
@mwhooker
@ ryan-apátrida
@jonathanvaughn
@gollawil
@ebartz
@maelp

+1

+1

+1

Usamos un registro interno en una red cerrada, agregando que esto nos facilitaría la implementación.

+1

Si este problema aún está abierto para Halloween, creo que todos los +1 deberían tener una fiesta de aniversario de un año ahogado en nuestros docker-docker-sorrows.

+1 para la fiesta del dolor!

El 14 de septiembre de 2015, a la 1:32 p.m., Gordon [email protected] escribió:

ENCUESTA DE USUARIOS

La mejor manera de recibir una notificación cuando haya cambios en esta discusión es haciendo clic en el botón Suscribirse en la parte superior derecha.

Las personas que se enumeran a continuación han apreciado su discusión significativa con un +1 aleatorio:

@justinclayton
@anandkumarpatel
@ tangr1
@ fred4jupiter
@mingfang
@djannot
@Frusty
@ tobegit3hub
@testacuentaspivey
@mhamrah
@mwhooker
@ ryan-apátrida
@jonathanvaughn
@gollawil
@ebartz
@maelp

-
Responda a este correo electrónico directamente o véalo en GitHub.

+1

+1 para la fiesta del dolor

Estimado propietario del bot que le dice a la gente que deje de usar "+1":
usamos +1 para solucionarlo y no hay mucho más que decir.

+1

+1

Hay un par de soluciones, incluido el uso de túneles SSH, pero eso requiere cuentas ssh en el host del registro. La siguiente solución alternativa no la necesita.

Ejecute el reenviador de puertos de registro de la siguiente manera:

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

Y luego extraiga o envíe imágenes de su registro local:

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

@rsmoorthy Eso es fantástico. Gracias por demostrar sucintamente la inutilidad de esta restricción actual.

Docker, vuelva a incluir esta batería en particular.

+1

Debo decir que fomentar la seguridad enérgicamente para el usuario ha influido seriamente en mis pensamientos sobre el uso de Docker. Entiendo completamente que podemos agregar el indicador --insecure-registry al daemon al iniciar, y no entraré en todas las razones por las que no funciona todo el tiempo o puede ser imposible.

Tengo una pregunta para los desarrolladores de Docker, ¿realmente creen que saben qué es lo mejor para el usuario final? Por mi parte, no requiero SSL en mis registros en absoluto, porque la red en la que se ejecutan ya está completamente encriptada. Entonces, ¿por qué demonios cifraría el tráfico cifrado? ¿Realmente esto está haciendo algo más que agregar gastos generales y piezas móviles a un sistema ya complejo y masivo?

Además, ¿existen realmente casos de uso en los que las personas utilizan un registro privado en Internet? ¿Qué se hace con la autenticación en ese sentido? ¿No se podría simplemente tirar de una imagen hacia abajo y luego destrozarla? ¿En lugar de intentar interceptarlo en ruta a otra computadora?

TL; DR +1

+1

@Supernomad bien dicho.

Véalo desde el lado de Docker: es un problema que es mejor mantener nunca implementado oficialmente, pero con muchas soluciones posibles para aliviar el dolor. Algunos usuarios que gritan en voz alta son aún menos dolorosos que el marketing de la competencia, que califica a la ventana acoplable como "insegura a propósito" y daña su reputación para siempre.
Habiendo dicho eso, +1.

@tiborvass @ewindisch Este número tiene más de un año. Han pasado más de 8 meses desde que dijo que iba a ser reevaluado. ¿Lo has evaluado? Si es así, ¿qué se ha decidido? ¡No dejes a un hermano colgado! :-)

Dado que este problema se abrió, cerró y volvió a abrir inicialmente, la comunidad ha ideado numerosas formas de solucionarlo ellos mismos, principalmente para demostrar la inutilidad de esta configuración predeterminada:

• 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

Sin mencionar que CoreOS ahora se envía con --insecure-registry 0.0.0.0/0 como predeterminado. Estos ejemplos muestran claramente que la idea de que existen líneas de separación de preocupaciones entre el "administrador de sistemas" y el "desarrollador" ahora es en gran parte arbitraria y falsa en 2015. De hecho, la idea misma de contenedores (de los cuales Docker es su principal evangelist) ha acelerado enormemente esta tendencia alejándose de las operaciones tradicionales que todavía se molestan en llamar a cualquiera "administrador de sistemas" en primer lugar.

De todos modos, me encantaría ver que esto se cierre para siempre, de una forma u otra.

+1

+1

+1

¿Por qué debería confiar en Docker Registry con mi clave privada SSL?

Para los otros usuarios de CoreOS que se quedaron a secar por esta intromisión,
https://coreos.com/os/docs/latest/registry-authentication.html#using -a-registro-sin-ssl-configurado

@político no podría haberlo dicho mejor yo mismo. Definitivamente, parece que Docker simplemente ignora el hecho de que una gran parte de sus usuarios están al menos insatisfechos.

El hecho es que estoy en el proceso de migrar completamente lejos de Docker y no podría estar más feliz con la decisión. Actualmente estoy usando git y lxc y no solo se transmite más rápido que Docker, sino que en realidad me permite hacer lo que es mejor para mi empresa y no lo que otra empresa piensa, aunque de manera completa y totalmente incorrecta, que es lo mejor para mí.

Sugiero encarecidamente que eche un vistazo a las alternativas que son honestamente mejores que Docker, como rocket, raw lxc, qemu (no es lo mismo, pero es mejor) solo por nombrar algunas.

Sugeriré encarecidamente este curso de acción a todos los que conozco que estén considerando contenedores a partir de ahora. Al menos hasta que la gente de Docker se dé cuenta de que no tienen ni idea, y enfatizo que _absolutamente_ no tienen idea de qué es lo mejor para el usuario final en términos de seguridad.

Me di por vencido y compré un certificado SSL dedicado y barato. La dependencia de la CLI de Docker en el sistema de CA es demasiado fuerte: los certificados autofirmados no solo son frustrantes desde el punto de vista operativo, simplemente no funcionan.

• docker-machine elimina su anulación ca.crt entre abajo / arriba
• ninguna de sus imágenes base incluye el certificado que hace que las herramientas como drone para CI sean imposibles
• Docker CLI usa una carpeta no estándar para certificados, por lo que es algo más para recordar.
• Incluso si lo haces funcionar 18 horas después, siempre tendrás la sensación de que algo más está roto.

En pocas palabras: Docker inflige una penalización continua y persistente a su equipo de operaciones cuando intenta utilizar un certificado autofirmado.

Esto es aún más frustrante ya que curl -k ha existido por la eternidad.

+1

Es bastante triste, que les importa un comino esto. Si algún desarrollador solo quiere jugar con la ventana acoplable y alojar su propio entorno, normalmente no querrá perder el tiempo con los certificados SSL y esas cosas. Además, si tiene su propio servidor en casa que está lejos de ser público, simplemente no necesita SSL.

@buehler puede agregar la opción --insecure-registry a la configuración de su daemon, o al archivo de configuración daemon.json ; entonces solo necesita configurarlo una vez y tirar sin tener que especificar la bandera

Solo una actualización nuestra: desde entonces, hemos eliminado el registro de nuestra infraestructura y hemos vuelto a usar nuestra bifurcación de dogestry personalizada con soporte de almacenamiento de Azure Blob . Descubrimos que Docker Registry estaba duplicando capas y nuestras máquinas se estaban quedando sin espacio en disco, lo que resultó en interrupciones. El registro resultó ser un callejón sin salida para nosotros.

@buehler solo para concretar la propuesta de @thaJeztah , agregue esta línea a la configuración:

--insecure-registry 0.0.0.0/0

Podrá acceder al registro que desee. Funciona bien para probar cosas.

@politician, la duplicación ocurre si las imágenes están etiquetadas con diferentes repositorios. La falta de eliminación de blobs es un problema significativamente mayor.

@thaJeztah, si es tan fácil de hacer, pero el 80% (ciertamente un número arbitrario) de los usuarios necesita hacerlo, entonces por favor, configúrelo como predeterminado.

@justinclayton no; la configuración de esa opción básicamente dice "ignorar cualquier problema con la comunicación segura con el registro", así que permita los ataques man-in-the-middle "listos para usar", o incluso que el demonio vuelva a no TLS "http: //" . Docker _does_ ya lo configuró como predeterminado para los registros en el rango 127.x.x.x .

Si tiene un registro local y no desea generar un certificado para él, agregar --insecure-registry a sus opciones de demonio toma menos de un minuto. Sin embargo, debería ser una acción deliberada, no algo que esté configurado de forma predeterminada.

@thaJeztah Entiendo tu argumento, pero eso no puede ser el final. Existe una brecha significativa en la experiencia del usuario para los nuevos desarrolladores como resultado de estar en el lado del demonio. El escenario de _mayoría_ donde esto es un problema es un nuevo desarrollador que sigue las instrucciones en docker.com para descargar y ejecutar el instalador de Docker Toolbox en su Mac. Al finalizar, inmediatamente intentan ejecutar docker pull <internally-signed-registry>/foo y reciben un error. Este es el verdadero problema. ¿Quizás eso signifique que este problema debería cambiarse de nombre?

Hay muchas otras formas en que esto también podría resolverse; Estoy seguro de que la comunidad y la empresa podrían ponerse de acuerdo en uno de ellos:

• El nombre actual de este problema es '--insecure-registry debería estar en "docker pull"'. Como este problema aún está abierto, debo asumir que esta opción aún se está considerando.
• Si se proporcionara (y documentara) una solución de un solo comando que fuera simple para los usuarios novatos, eso resolvería este problema.
• En nuestro caso, el registro _ está_ protegido. Utiliza un certificado firmado por nuestra CA interna como todo lo demás en nuestro entorno de compilación. Esta es suficiente seguridad. Si el demonio de alguna manera pudiera honrar el almacén de certificados de MacOS, eso también haría que este dolor de cabeza desapareciera.
• Si se les solicita que agreguen el certificado o realicen esta configuración en la máquina acoplable durante el proceso de instalación de Toolbox, probablemente también estaría bien.

Informe a los más de 70 participantes de este número en qué dirección planea tomar con esto, o simplemente cierre el problema para que no nos quedemos colgados. Gracias.

@thaJeztah
No hay forma de agregar un único registro --inseguro a las opciones de demonio sin reiniciar todos los contenedores en ejecución. Ese es uno de los principales problemas. No podemos volver a cargar la configuración sin reiniciar (el problema dura desde 2013), no podemos extraer imágenes de otros registros inseguros sin agregar la opción al demonio y también reiniciar. Y hoy en día todavía no tenemos una hoja de ruta clara para solucionar ese problema.

@apakhomov supongo que podría agregarse a la lista de cambios de configuración que se pueden actualizar sin reiniciar https://docs.docker.com/engine/reference/commandline/daemon/#configuration -reloading. ¿Puede abrir una edición separada para eso?

+1.

Algunos proveedores de PaaS no dan acceso al demonio y ejecutan una red privada para el usuario (Jelastic, por ejemplo).

¿Es posible agregar múltiples registros inseguros a la ventana acoplable?
algo como --insecure-registry xxxx: xxxx --insecure-registry zzzz: zzzz

@kkorada --insecure-registry=0.0.0.0/0 hará que Docker se comporte como antes.

@kkorada sí, puede especificar varios registros (la bandera es --insecure-registry=[] - los corchetes indican que se puede especificar varias veces).

También para la ventana acoplable 1.12, configuraremos esta opción en el archivo de configuración daemon.json , sin reiniciar el demonio. Vea la solicitud de extracción abierta aquí: https://github.com/docker/docker/pull/22337

gracias @mingfang y @thaJeztah

Como @mhamrah y @justinclayton sugirieron , también recomendaría una solución usando ssh, además de TLS, similar a cómo Git permite acceder a un repositorio utilizando tanto SSH y TLS. Esto podría hacer uso de la solución alternativa ssh que @justinclayton enumeró .

Aunque no tengo datos para respaldar mi afirmación, supongo que hay muchos más registros privados que se ejecutan detrás de cortafuegos que registros que se ejecutan en Internet abierta. En ese caso, ssh es más fácil de configurar y, si no más, seguro que TLS.

Además, después de haber luchado durante días con docker push y mi registro privado local que se ejecuta dentro de una máquina virtual interna suficientemente segura (y más tiempo luchando para crear certificados autofirmados), he llegado a apreciar realmente rkt --insecure-options=image,tls,http .

Es una locura que esto no sea un entorno de cliente. Obviamente, no debería estar activado de forma predeterminada porque eso alentaría una práctica insegura. Sin embargo, poner la configuración en el demonio lo hace muy poco práctico para fines de depuración o en entornos de desarrollo local.

Mi caso de uso actual: ejecutar un entorno de desarrollo con docker compose. El entorno necesita un registro de Docker local. Está diseñado para ejecutarse completamente en una máquina virtual local.

La forma de la ventana acoplable: explicando cómo configurar la máquina acoplable para habilitar el registro inseguro en cada máquina de los desarrolladores, posiblemente requiriéndoles que vuelvan a crear su máquina acoplable si ya tienen una o editar la configuración a mano.

La solución hacky: socat ejecutándose en cada contenedor que necesita usar el registro, redirigiendo a localhost.

No precisamente facilitando las cosas ...

+1

Realmente una lástima que - ¡inseguro no sea una configuración de cliente!
Eso nos crea mucho dolor y es muy similar a muchas de las explicaciones anteriores.
Establezca --insecure-registry = 0.0.0.0 / 0 de forma predeterminada para proporcionar una forma de pasarlo al comando docker, así como a las configuraciones de docker-compose.

+1

+1

¿Es hora de la fiesta anual +1 Pity de nuevo?

El 13 de diciembre de 2016, a la 1:00 a. M., 沙包 妖 梦[email protected] escribió:

+1

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub o silencie el hilo.

Si las capas de imágenes están firmadas, no es necesario utilizar CA PKI por motivos de seguridad. Vea también cómo funciona apt / yum. Además, el uso de SSL en una LAN tiene poco sentido y, en un entorno de nube, significa que debe aprovisionar, además de los propios certificados, una buena fuente de aleatoriedad (consulte también: https://lukehinds.github.io/2015-03 -03-Entropía-en-la-nube /).

En pocas palabras: si es innecesario, no lo fuerces a los usuarios.

Acabo de abrir # 29736 que está relacionado.

+1, si tener un indicador --insecure-registry del lado del cliente no es una opción, debería haber una forma de especificar un certificado de confianza que se utilizará para docker pull y docker push . No todo el mundo tiene acceso a certificados de confianza a nivel de sistema operativo, o acceso para jugar con el demonio de Docker.

Los servidores de CI alojados (que se utilizan para crear imágenes de la ventana acoplable y enviarlas a un registro privado) son un gran ejemplo de cuándo es posible que no tenga ese nivel de acceso.

+1

@ajhodges https://docs.docker.com/registry/insecure/#using -certificados -autofirmados

@tiborvass
Solo funciona si tienes acceso a sudo ...

+1 buena forma de disuadir a los desarrolladores de usar Docker

+1, me gustaría ver --insecure-registry por docker login también.

Ni siquiera veo esto como un problema de seguridad, ya que lo está haciendo conscientemente. Y si alguien no autorizado tiene acceso de root, esto tampoco proporcionará ninguna seguridad. ¿Qué mérito tiene realmente esta restricción?

Si tuvo malas intenciones, simplemente podría cargar su imagen de la ventana

+1 y, francamente, esto aturde la mente

+1 al tren del dolor.

¡Más F * cking One!

¿Hay un PR abierto para esto?

No AFAIK. Los enlaces anteriores se generan porque parte de mi propio código hace referencia a este problema. Retiraré esa referencia por un tiempo para silenciar el spam aquí.

+1 también ...

+1

+1, es muy inconveniente agregar la configuración a deamon.json y reiniciar la ventana acoplable.

Diferentes máquinas tienen diferentes sistemas operativos. Algunos instalan la ventana acoplable desde yum 、 apt-get , y otros directamente usando binario. Así que tengo que detectar eso y reiniciar Dockerd correctamente ... eso es un desastre

¡Solo hago hincapié en la necesidad de extracción de la ventana acoplable --insecure-registry bandera!

Solo han pasado tres años, no perdamos la esperanza ahora

golpe 🤣

+1

+1

El argumento de que esto alienta a los usuarios a configurar sus registros como seguros no solo es presuntuoso, sino que también carece de un punto clave. Coloca las operaciones en una posición en la que muchas personas deben tener acceso a la cuenta raíz para realizar su trabajo de operaciones, donde los registros de la ventana acoplable se mueven mucho.
Ese acoplamiento, desde el punto de vista de la seguridad operativa, crea un mayor riesgo de seguridad.

En segundo lugar, en una red privada (como en una aplicación alojada en la nube de varios niveles), la protección de los registros no es necesaria y complica aún más las implementaciones de tecnología que se encuentran en la parte superior, que requieren capas de administración de seguridad (para manejar la autenticación automatizada de Docker / refresh) siempre que se utilice un registro de Docker seguro.

Como mínimo, el demonio de la ventana acoplable debe ser configurable para PERMITIR que se pasen parámetros de registro inseguros. Eso mueve el diseño de seguridad al lugar adecuado: en manos del administrador y fuera de la ventana acoplable.

FWIW Estaría feliz con un comando para "agregar algún registro a la lista de registros inseguros", ya que parchear las configuraciones json desde los scripts de shell es un problema importante.

+1

: +1: +1

+1

+1

+1

+1

Muchas de las implementaciones solicitadas de esto harían imposible que las empresas que utilizan Docker cumplan con los requisitos de cumplimiento de SOC, etc.

Debería haber una solución para esto, pero no creo que haya una solución fácil que no suponga un cambio arquitectónico más drástico en la forma en que se almacenan y ejecutan las imágenes.

Aún así, eso debería suceder.

Ya no estoy involucrado con el desarrollo de Docker, así que me eliminaré de las menciones. Buena suerte a todos ^ _ ^

El requisito de SOC es un buen punto. En ese caso, esta función debe HABILITARSE con una opción de configuración que se agregará a la configuración de la ventana acoplable de todo el sistema. De esa forma se pueden mantener los requisitos de SOC. Algo como "ALLOW_INSECURE_REGISTY_OPTION" que habilita la marca --insecure-registry en la línea de comandos de la ventana acoplable.

Para el cumplimiento de SOC, la opción no debe estar habilitada.

+1

Solo han pasado tres años, no perdamos la esperanza ahora

5.

Es muy poco probable que esta propuesta (en su forma actual) se implemente, por varios
razones, entre las cuales;

• mantiene a la persona que administra el demonio de la ventana acoplable a cargo de las conexiones
  al demonio se le permite hacer. tenga en cuenta que esta opción se puede "recargar en vivo",
  por lo que no es necesario reiniciar el demonio para cambiar la configuración.
• cada comando o ruta de código que potencialmente interactúe con un registro tendrá
  ser modificado; no solo docker pull , sino también docker build , docker run ,
  docker plugin , docker service y docker stack subcomandos, así como
  orquestadores como swarmkit, que extraen imágenes de los nodos trabajadores.
• Cumplimiento de SOC (como se mencionó anteriormente)

Como mínimo, el demonio de la ventana acoplable debe ser configurable para PERMITIR inseguro
parámetro de registro que se va a pasar. Eso mueve el diseño de seguridad al adecuado
place: en manos del administrador y fuera de la ventana acoplable.

Creo que el administrador en este caso sería la persona / equipo que administra el
hosts en los que se ejecuta el demonio docker, no el usuario que se conecta al control remoto
API. Esta es la razón por la que esta configuración es una configuración de demonio.

parchear las configuraciones json desde los scripts de shell es un punto importante.

Ese es un punto justo, pero ortogonal a esta discusión. No es imposible_
para parchear la configuración JSON, pero acordó que puede ser más complicado que otros
formatos de archivo. Tenga en cuenta que esta configuración también se puede establecer como a través de banderas en
el demonio, que le permite usar un archivo de unidad desplegable systemd para reconfigurar
el demonio.

Algo como "ALLOW_INSECURE_REGISTY_OPTION" que habilita la marca --insecure-registry en la línea de comandos de la ventana acoplable.

Si desea permitir extracciones inseguras de cualquier registro (que sería el equivalente
de agregar una bandera --insecure-registry ), puede permitir que "Internet" sea inseguro
registro; lo siguiente debería permitir que cualquier dirección IPv4 se utilice como registro inseguro,
(por lo tanto, recurrir a conexiones que no son TLS);

A través del archivo de configuración /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"]}

O pasando las opciones como banderas en el demonio (que se puede establecer en un systemd
anular archivo);

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