Moby: --insecure-registry deve estar em "docker pull"

Executamos registros docker internos inseguros em todos os ambientes de CI e de produção. Devo dizer que seria muito útil simplesmente permitir o acesso a todos os registros inseguros, sem ter que listá-los um por um. Temos vários registros em cada ambiente para HA. Essa mudança tornou as coisas muito mais complicadas para nós. Vou abrir outro tíquete de problemas especificamente para resolver isso, pois esse problema é mais para mover a opção para o pull do que para o daemon.

E há um pequeno problema do ovo e da galinha quando você não usa uma porta fixa para executar o registro.

Como você não sabe qual porta será atribuída pelo docker com antecedência, você não pode realmente iniciar a demonstração com um sinalizador que faça referência a ela.

: +1:

então acho que apoiar --insecure na linha de comando docker pull , desabilitando as verificações de segurança à força, obviamente para _este_ comando pull, também resolveria seu problema com @proppy e @octalthorpe, certo? como correr com este sinalizador não verificaria listas de qualquer

@abourget também precisa ser suportado na API remota.

Atualmente, docker-py expõe um sinalizador insecure_registry na função pull , mas é usado apenas para resolver o endpoint: https://github.com/docker/docker-py/blob/master/ docker / client.py # L794

O culpado parece ser https://github.com/docker/docker/commit/6a1ff022b0744213ed588d9c16dbb13ce055eda6

Mas não consegui encontrar o PR correspondente ou questões em que essa mudança foi discutida.

@tiborvass alguma ideia?

@proppy - Isso foi tratado como uma vulnerabilidade de segurança embargada e não foi discutido em um PR público. A equipe central teve visibilidade e voto sobre o assunto.

Preciso refletir sobre as implicações de tal mudança para localhost / 127.0.0.1, mas não estou particularmente interessado nisso. É uma configuração incomum e fora do padrão e a solução está bem documentada.

@ewindisch por outro lado, há muitos daemon do docker já em execução, com o contêiner de registro em execução em localhost .

Se literalmente todos esses usuários precisarão passar --insecure-registry localhost:5000 , você também pode torná-lo o padrão.

@ewindisch Vocês têm documentação ou orientação sobre o que constitui uma vulnerabilidade de classe de embargo? Este não é um RCE remoto não autenticado. O perigo aqui não parece agudo o suficiente para justificar uma alteração brusca em uma liberação pontual sem aviso prévio.

@mmdriley - a definição de acordo com Mitre / NST geralmente se aplica. Nesse caso, um ataque man-in-the-middle é viável, o que permite a execução de código arbitrário não confiável em sistemas afetados, portanto, sim, classificamos isso como um RCE. Isso significa que se você fosse usar o Docker para extrair imagens de um laptop em um café, por exemplo, outro usuário daquele ponto de acesso WiFi poderia executar aplicativos arbitrários fornecidos por um invasor. Eles também podem potencialmente obter acesso à sua conta DockerHub ou outros registros nos quais você se autenticaria.

EDITAR: adicionar link para a descrição CVE: https://groups.google.com/d/msg/docker-user/oYm0i3xShJU/0QbAw9eN9qkJ

Sim, eu estava errado em dizer que não era RCE. É um bug ruim e uma grande prova de por que a assinatura robusta de imagens é uma ótima ideia. No entanto, a exploração não é trivial: requer que um invasor ativo passe o tempo no Starbucks esperando que alguém próximo use o Docker em um WiFi inseguro. Isso não será transformado em arma da noite para o dia - e, portanto, não merece uma alteração incompatível com versões anteriores sem aviso.

Como foi sugerido acima, havia maneiras óbvias de melhorar a segurança imediatamente sem quebrar a compatibilidade. Por exemplo, desabilitar o fallback de HTTPS para index.docker.io e um punhado de outros registros públicos populares teria resolvido efetivamente o problema para a maioria dos usuários. Adicionar um aviso à saída do console de que o fallback de HTTP estava acontecendo teria mitigado o caso interativo. O fallback de HTTP seria marcado como obsoleto e removido, digamos, no lançamento do próximo mês. Finalmente, localhost e :: 1 obviamente não são vulneráveis.

Novamente, eu não deveria ter desconsiderado a extensão da vulnerabilidade, mas estou preocupado que o processo de resposta e a correção não deram valor suficiente para não interromper os clientes.

Atualmente, estamos criando / destruindo registros docker dinamicamente em um ambiente que não tem FQDN disponível para muitas dessas instâncias. O suporte a uma opção --insecure-repository para solicitações relacionadas ao registro (por API remota) removeria complicações significativas que essa correção de segurança criou para nós.

Temos um problema semelhante com o Docker 1.3.1. Usamos o registro Docker local (privado) no endereço http: // docker : 5000 /. Até o Docker 1.3.0 funcionava bem. Com o Docker versão 1.3.1, ele não funciona mais porque o cliente Docker assume automaticamente que o Registry está acessível em HTTPS. Mas não usamos HTTPS de forma alguma.

Seria bom implementar um mecanismo de fallback que usa HTTP se um servidor Docker Registry não estiver acessível via HTTPS.

@kruxik se você usar --insecure-registry docker:5000 ao iniciar o daemon, ele retornará ao HTTP.

@tiborvass obrigado pela sugestão. Você está certo. Mas se você tem muitos desenvolvedores com suas estações de trabalho e notebooks, definir --insecure-registry em cada estação é uma maneira impraticável. Pelo menos deixá-lo como um parâmetro opcional para operações pull / push seria suficiente para nós;)

+1

Isso funcionou para nós com 1.3.0, mas com 1.3.1

versão docker
....
Versão do servidor: 1.3.1
....
docker push 10.121.4.236:5000/debian7/consul
-> .... Se este registro privado suportar apenas HTTP ou HTTPS com um certificado CA desconhecido, adicione --insecure-registry 10.121.4.236:5000 aos argumentos do daemon. No caso de HTTPS, se você tiver acesso ao certificado CA do registro, não há necessidade do sinalizador; simplesmente coloque o certificado CA em

Downgrade
Versão do servidor: 1.3.0
docker push 10.121.4.236:5000/debian7/consul
-> uploads de contêineres sem problemas.

Para outras pessoas com problemas de 1.3.0 a 1.3.1, tive que fazer as seguintes alterações para OS X com 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

então você _deve_ ser capaz de fazer um docker pull.

Se estiver usando a fig, você também precisará da Fig 1.0.1 e faça:

$ fig up --allow-insecure-ssl

@mhamrah Obrigado! Passei horas tentando consertar isso ...

+1 para assumir que o localhost é seguro. Alguém é realmente contra isso?

Sim, assumir que o localhost é seguro ajudaria muito. Eu uso o vagrant para minha caixa de encaixe, então atualizar o script de inicialização toda vez que destruo ou abro uma caixa é simplesmente ineficiente. Eu acho que agora terei que fantoche minha docker box para que eu possa modificar o init no vagrant up.

também usar um sinalizador --insecure no pull e push seria bom, então eu poderia usar o IP da vagrant box se necessário.

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

Para ser honesto, eu também estava me perguntando por que meus Jenkins Containerbuilds automatizados não conseguiram empurrar ...
(É bom ter um teste antes de colocá-lo em produção).
Tenho que verificar se esse "recurso" foi realmente anunciado - senão ficarei mais paranóico com mudanças tão extremas no comportamento dos daemons.

O que sinto falta nesta discussão:
Por que preciso dizer ao daemon para usar o modo seguro / não seguro "padrão" para cada host?

Não deveria ser mais produtivo configurar o registro com esse comportamento padrão?
Portanto, dependendo da configuração, se nenhum parâmetro --secure ou --insecure for fornecido, o daemon deve solicitar
se a maneira segura é possível e se não foi usado o fallback para não seguro.

Uma das principais características do docker é que ele é totalmente fácil de usar e de configurar um ambiente completo. por favor, não elimine este efeito WOW com tais "lançamentos / decisões" ...

apenas meus 2 centavos ...

Problemas semelhantes aos acima, incluindo @jwthomp. Passei mais de 10 horas tentando resolver esse problema e, nesse meio tempo, fiz downgrade para o docker 1.3.0.

Estou executando o registro do docker no Marathon e o registro do docker atualmente "suporta SSL executando nginx como front-end" (consulte https://github.com/docker/docker-registry/issues/697), mas usar o nginx como front-end é complicado pelo Marathon executando o registro docker em vários hosts / portas escravos.

Eu poderia ativar o SSL diretamente no registro (usando GUNICORN_OPTS), mas ele _só_ fala SSL e não pode passar nas verificações de integridade do Marathon.

Modifiquei o sistema de configuração do Bamboo HAProxy para também configurar o HAProxy como um front-end https para todos os serviços da maneira que o nginx teria sido, mas ainda tenho problemas com o docker para validar o certificado no meu registro privado, então ainda não é possível eu neste momento.

É muito bom proteger contra RCE, mas também precisa haver alguma compatibilidade com versões anteriores. Pelo menos um sinalizador para o daemon docker para especificar todos os registros como inseguros. Deve haver uma maneira de especificar http ou https como parte do nome do registro em cada comando docker pull. No momento, 1.3.1 parece um grande Catch-22 para qualquer um usando um registro privado.

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

Agradável.
Na sexta-feira, 14 de novembro de 2014 às 10:42 Ilya Radchenko [email protected]
escreveu:

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

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/docker/docker/issues/8887#issuecomment -63082089.

@mhamrah Eu não tive que fazer a remoção das chaves ssh, etc. Eu apenas adicionei a linha necessária em / var / lib / boot2docker / profile e reiniciei o docker. Obrigado pela dica!

Legal. Tive problemas até mesmo para entrar, presumo por causa de alguma versão
incompatibilidade entre docker iso. Na verdade, mudei para o vagrant +
coreos para suporte docker, e funciona bem. Você só precisa definir
DOCKER_HOST, que boot2docker faz automaticamente.

Em Qui, 20 de novembro de 2014 às 1:52:21 Kayvan Sylvan [email protected]
escreveu:

@mhamrah https://github.com/mhamrah Eu não tive que fazer a remoção de
as chaves ssh, etc. Acabei de adicionar a linha necessária no
/ var / lib / boot2docker / profile e docker reiniciado. Obrigado pela dica!

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/docker/docker/issues/8887#issuecomment -63768043.

Desculpe pessoal, eu pretendia responder antes.

Como @ewindisch já disse, não queremos encorajar esse comportamento do lado do cliente. A dor induzida por exigir o sinalizador como um sinalizador daemon é que as pessoas realmente configuram o TLS em seu registro. Caso contrário, não há incentivo. Obrigado pela sua compreensão.

Há uma imagem "oficial" baseada no docker do registro do docker no registro oficial do docker. Recomenda-se o uso sem TLS.

Se o Docker desejasse que os usuários configurassem o TLS em seus registros, não faria sentido equilibrar a "dor induzida" com uma "redução da dor" igual e oposta , fornecendo uma imagem oficial do docker cujo padrão é fornecer TLS?

@tiborvass . Você está ignorando o caso de desenvolvimento interno por trás do firewall. Portanto, agora, ou tenho que configurar um proxy reverso com SSL habilitado na frente do meu registro (simplesmente não há razão para fazer isso) ou tenho que ir a cada um dos meus desenvolvedores e modificar os argumentos para o daemon em execução dentro do boot2docker. Isso não faz sentido. Existem muitos ambientes de desenvolvimento que fornecem segurança configurável em que a segurança é freqüentemente desabilitada para ambientes de desenvolvimento. Estou surpreso em vê-lo encerrar este problema quando houve tantos votos para uma solução.

Que tal colocar na lista de permissões todos os ips privados? Meio termo?

Ou tornar o nome do protocolo, 'http' ou 'https' parte do nome da imagem para pull.

@tiborvass @sroebuck e @blevine trazem ótimos pontos. Isso se tornará cada vez mais o cenário para lojas que constroem contêineres internamente, e a fúria por quebrar o fluxo de trabalho anterior também aumentará. Todos nós entendemos o lado da segurança disso, e talvez pull não seja o lugar certo para resolvê-lo, mas contanto que a imagem do registro oficial não forneça uma maneira simples e imediata de lidar com essa mudança, deveria ser considerado um problema de UX muito importante a ser resolvido.

Ei @tiborvass ! Este problema também está nos afetando. Eu prefiro a abordagem de @nickandrew . Seria um pouco mais como um clone do git e também abriria a possibilidade de diferentes protocolos plugáveis ​​no futuro. Uma vitória para docker, pois reduziria o acoplamento e uma vitória para a comunidade.

@blevine observe que a partir de 1.3.2 localhost está na lista de permissões por padrão, consulte: https://github.com/docker/docker/pull/9124

Você pode fazer o registro escutar no localhost passando: -p 127.0.0.0:5000:5000 para docker run

@proppy , não tenho certeza de como ouvir no localhost me ajuda.

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

Ou deve se tornar um URL real? Não sei nada sobre o protocolo de registro, mas não parece incompatível estender a sintaxe atual para especificar um URL adequado.

@blevine significa que você pode configurar um registro de espelhamento local.

Arg, agora eu tenho que decodificar em base64 minha configuração de nuvem para coreos para fazer minhas máquinas inicializarem

@tiborvass Uau, isso é realmente lamentável. :(

Temos clusters de desenvolvimento que ativamos e desativamos dinamicamente e parte de como lidamos com esses clusters é que criamos um registro para esse cluster. Um cluster pode ter muitos nós físicos ou vms, e também pode estar em uma máquina desktop ou laptop do desenvolvedor (embora normalmente não possamos iniciar uma pilha completa). Cada cluster é uma pilha totalmente independente e um ambiente de desenvolvimento. Também temos ferramentas de linha de comando baseadas em docker que permitem a um desenvolvedor interagir com qualquer configuração de cluster de desenvolvimento na empresa.

Nesse tipo de ambiente complexo e dinâmico, tornar o TLS em um registro um requisito é uma dor gigantesca. Ter que modificar a inicialização do docker daemon toda vez que configuramos e adicionamos uma nova rede onde um registro pode estar é igualmente uma dor.

Não me interpretem mal, agradeço a ideia por trás do desejo de oferecer suporte exclusivo ao TLS. No entanto, incentivo você a considerar que há casos válidos em que o ambiente oferece suporte seguro para a remoção da complexidade do TLS para a redução da dor e da infraestrutura necessária para oferecer suporte isto.

@tiborvass +1. +1000. Isso gerou uma complexidade absolutamente desnecessária para
para um fluxo de trabalho de desenvolvimento altamente dinâmico. A barreira para a entrada foi
gerado significativamente aqui para algo que só precisa ser aplicado em um
contexto de produção. Por favor, acabe com nossa dor.

Na terça-feira, 9 de dezembro de 2014, Jeff Thompson [email protected]
escreveu:

@tiborvass https://github.com/tiborvass Uau, esse é um daqueles
momentos de inversão de mesa virtual tristemente. :(

Temos clusters de desenvolvimento que ativamos e desativamos dinamicamente e separamos
de como lidamos com esses clusters é criar um registro para esse cluster. UMA
cluster pode ser muitos nós físicos ou vms, e também pode estar em um
desktop ou laptop de desenvolvedores (embora normalmente não possamos lançar um
pilha completa). Cada cluster é uma pilha totalmente independente e de desenvolvimento
ambiente. Também temos ferramentas de linha de comando baseadas em docker que permitem um
desenvolvedor para interagir com qualquer configuração de cluster de desenvolvimento na empresa.

Neste tipo de ambiente complexo e dinâmico, fazer TLS em um registro
um requisito é uma dor gigantesca. Ter que modificar a inicialização do docker daemon
cada vez que configuramos, adicionamos uma nova rede na qual um registro pode estar
igualmente uma dor.

Não me interpretem mal, agradeço o pensamento por trás do desejo de apoiar
TLS, no entanto, há casos em que o ambiente suporta com segurança a remoção
a complexidade do TLS para a redução da dor e da infraestrutura necessária
para apoiá-lo.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/docker/docker/issues/8887#issuecomment -66367681.

@justinclayton @jwthomp @mattwilliamson @nickandrew @blevine

--insecure-registry 0.0.0.0/8 resolve seu problema? Dessa forma, você ainda pode usar HTTP.

Esta notação CIDR pode ser usada mais granularmente para habilitar configurações "atrás do firewall" especificando intervalos como "--insecure-registry 172.16.0.0/12". Não aconselho o uso dessa opção, mas recomendo que os usuários que escolham essa opção usem um intervalo mais seletivo (como seu espaço IP) em vez de todos os endereços possíveis com 0.0.0.0/8.

O docker daemon é integrado ao coreos, portanto, preciso, de alguma forma, adicionar esses sinalizadores à inicialização em todo o cluster. Acho que é muito mais flexível tê-lo no comando pull para ambientes em que você não pode controlar o daemon do docker em si.

É o equivalente a nos dizer para mudar um arquivo php.ini para um host php compartilhado.

Em 9 de dezembro de 2014, às 22h18, Tibor Vass [email protected] escreveu:

@justinclayton @jwthomp @mattwilliamson @nickandrew @blevine

--Insecure-registry 0.0.0.0/8 não resolve seu problema? Dessa forma, você ainda pode usar HTTP.

-
Responda a este e-mail diretamente ou visualize-o no GitHub.

Sinalizadores de execução

Exemplos de alteração da configuração do Docker estão no site do CoreOS. Pode-se modificar facilmente as instruções para adicionar um sinalizador de depuração para especificar um sinalizador de registro inseguro.

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

@tiborvass todo o ecossistema de configuração precisa suportar isso para funcionar facilmente fora da caixa. As pessoas não esperam fazer personalizações fora do padrão na inicialização do daemon em todos os lugares que possam estar puxando (boot2docker, coreos, qualquer coisa instalada com os módulos chef / puppet, etc) quando passam para a etapa de configuração de seu próprio registro interno. A própria imagem do contêiner do registro oficial _não funciona mais_ ao usar as etapas marcadas como "recomendado" no leia-me. O leia-me não faz nenhuma menção ao TLS, na verdade, e sua configuração não é um processo trivial. Além disso, como @mattwilliamson mencionou brevemente acima, existem inúmeros casos, como ambientes de construção compartilhada, onde alguém que usa o daemon para extrair uma imagem não é o mesmo que a pessoa que está configurando o daemon.

O resultado final é que tornar isso um argumento do lado do cliente é claramente a solução menos perturbadora e, mais importante, a solução menos prescritiva. O Docker já se tornou um primitivo em dezenas, senão centenas de outros projetos e fluxos de trabalho e, como tal, não deveria realmente ditar os padrões de uso neste escopo. Só porque o Git oferece uma opção de configuração de tempo de execução simples para desabilitar http.sslverify, não significa que Linus Torvalds encoraja as pessoas a não proteger seus dados confidenciais em contextos onde é importante fazer isso.

A analogia do git é um bom exemplo de como isso deve funcionar. Git não força você a usar TLS, e é a decisão do usuário ao configurar um host de qual nível ele deseja oferecer suporte. Também é a decisão do usuário ao obter o nível de segurança que ele exige (ou deseja contornar). A configuração é uma etapa simples, globalmente ou por repo. Embora o Docker não nos force a usar o TLS, ao tornar a alternativa não trivial, ele não oferece outras opções razoáveis.

A notação CIDR permite uma abordagem indiscutivelmente "martelo pesado", e AFAIK, não mapeia para nomes de DNS, então mesmo se eu mascarar um 10.0.0.0/16, puxando some.private-registry.com em um won 10.0 / 16 t trabalhar. Mais importante ainda, a configuração não é trivial.

O Docker prospera em sua simplicidade para a conteinerização e reduz significativamente a barreira para implantar aplicativos em uma variedade de ambientes. Todos nós conhecemos os benefícios. A maioria dos desenvolvedores não consegue responder a perguntas simples de notação CIDR, o arquivo de configuração do docker pode estar em locais não padrão (os locais boot2docker e CoreOS são diferentes de outras distros) e é bastante fácil bagunçar esses arquivos de configuração com difíceis loops de feedback para sucesso. Eu tenho que seguir o syslog? Oh, espere, estou no RHEL e suas mensagens?

Um novo desenvolvedor pode facilmente copiar e colar um snippet docker pull , mas fazê-los ssh em um host boot2docker, executar o vi, editar um arquivo de configuração e depois seguir um syslog para erros ... nem tanto. E, sim, você se esqueceu de reiniciar o daemon do docker.

Aqui está o que eu gostaria de ver:

• Configurações do daemon do Docker aplicadas por meio do comando docker
• Configurações de pull do Docker para substituições de TLS, especificadas por meio do comando docker
• Configurações de pull do Docker preservadas em comandos para registros específicos

Sim, mas o Amazon não permite que você altere uma configuração de escala automática. Terei que fazer uma cópia dele ou fazer um novo.

Em 9 de dezembro de 2014, às 23:55, Eric Windisch [email protected] escreveu:

Os sinalizadores de execução são configuráveis ​​com CoreOS. Você pode editar o arquivo de configuração do systemd para Docker. Para configurar isso para um cluster, você pode usar cloud-config.

Exemplos de alteração da configuração do Docker estão no site do CoreOS. Pode-se modificar facilmente as instruções para adicionar um sinalizador de depuração para especificar um sinalizador de registro inseguro.

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

-
Responda a este e-mail diretamente ou visualize-o no GitHub.

Atualmente, tenho que contornar esse problema no ambiente de desenvolvimento da minha empresa, executando este comando meticulosamente pesquisado toda vez que faço 'boot2docker'

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 dor. A adoção do docker dentro da minha empresa de mais de 400 funcionários está paralisada devido a esse problema. Não temos absolutamente nenhuma utilidade para o TLS em nosso ambiente de desenvolvimento interno, onde tudo é controlado. Aplaudimos seu uso para repositórios de hub públicos e achamos que forçar isso em todos os casos é um grande erro.

@CleanCut muito bem colocado. Fiquei realmente desapontado que 1.4.0 veio e se foi e este problema continua em aberto.

@CleanCut incrível - O que eu gostaria no boot2docker, é que ele adicionasse mais informações à carga útil inicial boot2docker init , que faria isso para você.

não resolve os problemas específicos do boot2docker não baseado em vm, mas --insecure-registry não é a única personalização específica do site que os usuários b2d desejam.

você pode fazer uma solicitação pull ou emitir para isso no repositório boo2docker, por favor?

Realmente levanta a barreira para alguém usar um projeto aplaudido por reduzir barreiras.

Em 13 de dezembro de 2014, às 02:10, Justin Clayton [email protected] escreveu:

@CleanCut muito bem colocado. Fiquei realmente desapontado que 1.4.0 veio e se foi e este problema continua em aberto.

-
Responda a este e-mail diretamente ou visualize-o no GitHub.

@SvenDowideit Claro. Aqui está

Parece que há consenso neste tópico de que este não é um problema resolvido; podemos reabrir este problema?

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

Parece que há consenso neste tópico de que isso não é um problema resolvido
problema; podemos reabrir este problema?

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/docker/docker/issues/8887#issuecomment -67055878.

+1. Não tenho nada a acrescentar, mas quero simplesmente desabafar minha frustração com essa decisão. Como todo mundo, estou executando um registro em uma rede local onde a segurança é controlada ad nauseam em outro lugar. Tenho dezenas de contêineres docker em execução que agora precisam ser devolvidos para adicionar o sinalizador 'bem documentado'.

@bfirsh - este é um daqueles exemplos em que um arquivo de configuração do Docker daemon e um kill -HUP <dockerdaemonpid> seriam incríveis - acione-o para reler o cfg, sem precisar reiniciá-lo - evitando assim a reinicialização do contêiner

@SvenDowideit +1 para o recurso de recarregamento, é realmente irritante reiniciar o servidor com uma configuração simples.

+1

Perdoe-me se não estou entendendo as coisas corretamente, mas parece que esse problema está na raiz do meu próprio cenário (semelhante ao descrito por @blevine, onde minha empresa tem um proxy de reescrita de certificado que me impede de até mesmo falar com o Docker Hub Registry público). Sei que, eventualmente, vou querer configurar meu próprio registro privado, mas estou apenas na fase de aprendizado, na qual ainda não tenho certeza se irei adotar o Docker. Este é um pesadelo de UX para alguém nos estágios iniciais de adoção.

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

+1 para reabrir esta discussão, porque parece que a comunidade não está muito feliz com a solução atual.

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

apenas tentando acertar isso de todos os ângulos até ouvirmos uma resposta definitiva sobre este tópico.

+1, atualmente é difícil configurar e trabalhar.

@mhamrah traz ótimos pontos. Não force as coisas, deixe que os usuários decidam e configurem de acordo com suas próprias necessidades.

Registros que usam certificados autoassinados também são um problema, especialmente
em um contexto de desenvolvedor usando boot2docker que mudou para um arquivo somente leitura
sistema. Isso requer uma etapa de configuração adicional e diferente para
inicialize o VM em execução.

Acredito que todos que postaram neste tópico veem o valor e o benefício
do docker, estão usando-o diariamente, estão tentando promovê-lo em seus
organizações, mas estão enfrentando um problema doloroso e desnecessário que
impede a adoção.

Por mais que todos nós conheçamos o docker, ele ainda é desconhecido para muitas pessoas na área de tecnologia
especialmente dentro da empresa. A documentação ajuda, mas ainda estamos
saltando através de aros, e é um grande bloqueador com um resultado geral negativo
efeito.
No domingo, 25 de janeiro de 2015 às 17:54, Jay Taylor [email protected] escreveu:

+1, atualmente é difícil configurar e trabalhar.

@mhamrah https://github.com/mhamrah traz ótimos pontos. Não force
coisas, deixe o usuário decidir e configurar para suas próprias necessidades.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/docker/docker/issues/8887#issuecomment -71398193.

+1 bom para experimentar coisas rapidamente

: +1:

: +1:

Super decepcionante que ainda não podemos extrair de registros inseguros sem passar um sinalizador para o daemon do docker. Este é apenas mais um incômodo para cada nova máquina que implantamos.

+1

Alguns pensamentos:

1. poderíamos ter curingas de nome de host? por exemplo, --insecure-registry=*.internal
2. os certificados autoassinados podem ser tratados de forma diferente do http?
3. relacionado ao 2, o docker poderia fazer algo semelhante ao SSH e solicitar que o usuário aceite um certificado autoassinado sempre que encontrar um novo / reclamar em voz alta se houver um incompatível?

E enquanto estou fazendo sugestões, por que não tratar o localhost como sendo sempre seguro? (como o Chrome faz)

Edit: ah, vejo que já é.

+1000 nisso .. e +1 no recurso de recarga de configuração, isso é o que torna isso duas vezes pior. Fiquei com a v1.2 porque imaginei que certamente um mantenedor perceberia o quão irritante o sinalizador --insecure-registry no daemon é para implantação e consertaria, mas de alguma forma as versões menores continuam ignorando-o.

Por exemplo, se eu tivesse que mudar meu IP de registro privado por qualquer motivo, eu teria que reiniciar cada daemon docker em cada VM - só porque meu registro mudou !? Essas 2 coisas nunca devem ser acopladas tão fortemente. E dizer às pessoas para apenas adicionar 0.0.0.0/8 anula todo o propósito da implementação de segurança em primeiro lugar.

Adicionar este sinalizador aos comandos push / pull parece tão óbvio quanto um fallback para o sinalizador daemon, por favor, alguém me explique por que eles ainda estão lutando contra isso, mas adicionando recursos "bom ter" nesse meio tempo.

O comentário de @agquick é local, especialmente sobre os recursos "bom ter".

Percebendo que isso é uma dor contínua para um número substancial de usuários, estamos reconsiderando a adição de --insecure a pull . @ewindisch e eu estaremos trabalhando em um PR que iremos vincular a este problema.

Pedimos desculpas pela longa espera e obrigado por expressar suas opiniões e apontar seus pontos fracos.

@tiborvass Posso imaginar que há um número igualmente grande de usuários que _não_ querem permitir pulls de registros não seguros. Sei que o Docker atualmente não tem controle refinado sobre permissões / configuração, mas se houver uma chance de ser capaz de "bloquear" isso, acho que seria um bom toque.

Oh, que coisa! Estava prestes a implementá-lo sozinho.

Enviado do meu smartphone BlackBerry 10 na rede Bell.
De: Sebastiaan van Stijn
Enviado: segunda-feira, 23 de fevereiro de 2015, 4:53 PM
Para: docker / docker
Responder para: docker / docker
Cc: Kristopher Cieplak
Assunto: Re: [docker] --insecure-registry deve estar em "docker pull" (# 8887)

@tibor vasshttps: //github.com/tiborvass Posso imaginar que haja um número igualmente grande de usuários que não querem permitir pulls de registros inseguros. Sei que o Docker atualmente não tem controle refinado sobre permissões / configuração, mas se houver uma chance de ser capaz de "bloquear" isso, acho que seria um bom toque.

-
Responda a este e-mail diretamente ou visualize-o em Gi tHubhttps: //github.com/docker/docker/issues/8887#issuecomment -75644600.

@thaJeztah Estou tentando descobrir em qual caso de uso você está pensando que significa que não podemos ter um sinalizador --insecure-registry para docker pull .

• se um usuário não quiser ser acidentalmente MITMed em um registro seguro, ele pode simplesmente evitar passar --insecure-registry
• se um usuário deseja impor aos usuários que todas as imagens vêm de registros seguros (ou seja, um cenário de 'empresa'), eles não podem realmente impor isso de qualquer maneira no momento!

Então você poderia explicar o que docker pull --insecure-registry inibe?

Para elaborar meu segundo ponto, não consigo ver como você bloquearia isso sem repensar uma parte significativa de como o docker funciona! Deixando de lado a possibilidade de docker load um tarball que você poderia obter escrevendo seu próprio extrator de registro e usando docker run -v para escalar privs e adicionar algo aos argumentos do daemon, há uma maneira muito simples de contornar qualquer 'aplicação':

$ 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

se um usuário deseja impor aos usuários que todas as imagens vêm de registros seguros (ou seja, um cenário de 'empresa'), eles não podem realmente impor isso de qualquer maneira no momento!

Este é o cenário, sim.

Para elaborar meu segundo ponto, não consigo ver como você bloquearia isso sem repensar uma parte significativa de como o docker funciona

Eu entendo perfeitamente que (neste momento) não há como bloqueá-lo. Os usuários que têm acesso a docker.sock têm efetivamente acesso root, então podem mudar o que quiserem. Além disso, eles ainda seriam capazes de alterar o sinalizador do daemon e reiniciá-lo.

No entanto, _deverá_ dar um sinal claro ao usuário se docker pull --insecure-registry .. der um erro ("Registros inseguros estão desabilitados"), que _deveria_ notificar os usuários de que não é desejado, por exemplo, ao tentar algum exemplo que encontraram algum lugar.

Então, cobriria todos os casos? Não. Iria magoar, eu também não acho.

Pessoalmente, acho que faria mais mal do que bem, simplesmente porque engana as pessoas a pensar "olhe, o docker reforça isso" quando, na verdade, é uma proteção muito superficial. Eu poderia continuar, mas no final acho que se trata de uma questão de gosto.

Se você está procurando como pode doer, basta rolar para cima. Existem inúmeros problemas de UX com essa abordagem que criam barreiras para a adoção, e todos eles foram detalhados acima.

Eu vejo os problemas principalmente com o docker incapaz de reiniciar sem matar o sub
containers. que tornam a configuração / reconfiguração muito mais difícil.

Na quarta-feira, 15 de abril de 2015 às 20:11, Jan Krueger [email protected]
escreveu:

+1

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/docker/docker/issues/8887#issuecomment -93362359.

Estou muito desapontado por ainda não ter havido nenhuma ação sobre este problema. Obviamente, está causando dor a várias pessoas.

Obviamente, é irritante para um grande número de pessoas, está bloqueando ativamente meu trabalho agora. Ter que reiniciar o daemon do Docker para permitir a extração de um registro inseguro varia de irritante a totalmente impossível, dependendo da situação em que você se encontra.

O principal argumento para não fazer isso parece ser que o administrador do sistema deve ser capaz de bloquear o sistema e certificar-se de que apenas as imagens de repositórios seguros podem ser retiradas. Esse caso de uso é definitivamente real, mas acho que é um péssimo padrão. Parece muito mais razoável ter um sinalizador que pode ser passado ao daemon no início como --no-insecure que desativa o uso de --insecure-registry em pull . Dessa forma, um administrador pode bloquear as coisas se realmente quiser.

Para aqueles que desejam muito esse comportamento, eu ofereço a seguinte solução alternativa. Eu entendo que não será viável para todos os usuários, pois não usa a API Docker para pulls. Também é um pouco lento ...

Veja meu projeto 'docker-pull': https://github.com/ewindisch/docker-pull

Você o usaria como tal:

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

Também é possível permitir que todos os registros sejam inseguros:

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

Vou lembrar que _ainda_ é altamente desaconselhável fazer isso.

@ewindisch nifty hack.

Outra solução muito boa é usar um 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

Essas duas soluções alternativas são fantásticas!

Eu também gostaria de ver o padrão revertido.

Em 15 de abril de 2015, às 18:14, Joe Doliner [email protected] escreveu:

Estou muito desapontado por ainda não ter havido nenhuma ação sobre este problema. Obviamente, está causando dor a várias pessoas.

Obviamente, é irritante para um grande número de pessoas, está bloqueando ativamente meu trabalho agora. Ter que reiniciar o daemon do Docker para permitir a extração de um registro inseguro varia de irritante a totalmente impossível, dependendo da situação em que você se encontra.

O principal argumento para não fazer isso parece ser que o administrador do sistema deve ser capaz de bloquear o sistema e certificar-se de que apenas as imagens de repositórios seguros podem ser retiradas. Esse caso de uso é definitivamente real, mas acho que é um péssimo padrão. Parece muito mais razoável ter um sinalizador que pode ser passado para o daemon na inicialização, como --no-insecure, que desativa o uso de --insecure-registry no pull. Dessa forma, um administrador pode bloquear as coisas se realmente quiser.

-
Responda a este e-mail diretamente ou visualize-o no GitHub.

então isso é reaberto e o status atual após 4 meses é nada e como uma solução alternativa usar um monte de hacks? : - / Há alguma discussão sobre isso acontecendo em outro lugar ou está simplesmente morto?

E sim, +1

+1

+1

Gostaria de salientar que contei as ocorrências de "+1" nesta página e a contagem chega a 31 até agora. Isso sem contar os outros comentários de apoio que, na verdade, não incluem aquela string exata.

O problema aqui é que habilitar --insecure no pull tira o controle do administrador do sistema, ao qual ele pertence.
A segurança é difícil e fazer alterações para afrouxá-la não é uma decisão fácil.
Além disso, as pessoas que estão perfeitamente satisfeitas com a configuração atual não virão aqui e -1 isso também.
Por outro lado...
É trivial reconfigurar o daemon para permitir pulls inseguros de um registro.
Também é trivial configurar alguns certificados autoassinados e nem mesmo precisar reconfigurar o docker.

"Sysadmin" é um caso de uso para docker, mas eu "desenvolvedor" e "não-administrador" são casos de uso igualmente válidos. Para um desenvolvedor, fornecer uma opção --insecure reduz o atrito no fluxo de trabalho.

Talvez pudéssemos ter o melhor dos dois mundos, fornecendo uma opção que os administradores de sistemas poderiam especificar para _denhar_ o uso de uma opção --insecure . Dessa forma, os administradores de sistemas ainda têm controle total, mas os casos que não são administradores de sistemas não precisam lidar com a dor do fluxo de trabalho.

O que é trivial para um administrador de sistema pode ser surpreendentemente complicado para não administradores de sistema. Tive que ajudar quase duas dúzias de desenvolvedores a fazer (e refazer) essa mudança de configuração em 5 sistemas operacionais diferentes usados ​​em nosso grupo de desenvolvimento. Na verdade, mantenho um script para automatizar a mudança de configuração para nossos ambientes.

Nossos administradores de sistemas não configuram certificados autoassinados para nosso registro, seja trivial ou não.

De qualquer forma, mesmo que isso não mude, eventualmente as pessoas vão se adaptar a eles. Suponho que a dor com a qual estou lidando desaparecerá na próxima vez que nossos administradores de sistema fizerem manutenção no registro, porque nesse ponto devemos ser capazes de instalar os certificados SSL reais. Talvez seja esse o ponto principal. Torne mais fácil seguir o caminho seguro do que o caminho inseguro daqui para frente.

: +1: @CleanCut , e todo mundo disse tudo. Eu só trabalho com o caso do desenvolvedor e reconfigurar o daemon do docker é uma perda de tempo para nós.

Se você tiver acesso ao socket docker hoje, você _é_ um administrador de sistema. Você é
já root, você tem "docker load" e já tem soluções alternativas para fazer
registro inseguro puxa. Adicionar a opção de imagem ao cliente não seria
menos seguro do que o status quo.

Há algo, no entanto, a ser dito sobre aumentar intencionalmente o
atrito para desenvolvedores que tentam fazer a coisa errada em outro para atrair
eles a fazerem o certo.
Em 18 de junho de 2015, 12:41, "Brian Goff" [email protected] escreveu:

O problema aqui é que habilitar --insecure no pull tira o controle
do administrador do sistema, a que pertence.
A segurança é difícil, e fazer alterações para afrouxar a segurança não é uma tarefa fácil
decisão.
Além disso, as pessoas que estão perfeitamente satisfeitas com a configuração atual não vão
para vir aqui e -1 isso também.
Por outro lado...
É trivial reconfigurar o daemon para permitir pulls inseguros de um
registro.
Também é trivial configurar alguns certificados autoassinados e nem mesmo precisar
reconfigure o docker.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/docker/docker/issues/8887#issuecomment -113213172.

@ewindisch @tiborvass lendo de volta, vejo https://github.com/docker/docker/issues/8887#issuecomment -75638745;

Percebendo que isso é uma dor contínua para um número substancial de usuários, estamos reconsiderando a adição de --insecure para puxar. @ewindisch e eu estaremos trabalhando em um PR que iremos vincular a este problema.
Pedimos desculpas pela longa espera e obrigado por expressar suas opiniões e apontar seus pontos fracos.

Essa ainda é a posição atual? (Eu não acho que um PR foi criado)

+1

Isso continua a me incomodar e irritar diariamente.

:( triste conehead.

--inscure faz todo o sentido para um POV do desenvolvedor. É responsabilidade da pessoa que está implementando o docker em seu ambiente para torná-lo seguro.

+1

: +1:

_USER POLL_

_A melhor maneira de ser notificado quando há mudanças nesta discussão é clicando no botão Inscrever-se no canto superior direito._

As pessoas listadas abaixo apreciaram sua discussão significativa com um +1 aleatório:

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

+1

+1

+1

Usamos um registro interno em uma rede fechada, o que tornaria a implantação mais fácil para nós.

+1

Se esse problema ainda estiver aberto até o Halloween, acho que todos os + 1s devem ter uma festa de aniversário de afogamento em nossas docas de um ano.

1 para a festa da tristeza!

Em 14 de setembro de 2015, às 13h32, Gordon [email protected] escreveu:

USUÁRIO

A melhor maneira de ser notificado quando houver alterações nesta discussão é clicando no botão Inscrever-se no canto superior direito.

As pessoas listadas abaixo apreciaram sua discussão significativa com um +1 aleatório:

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

-
Responda a este e-mail diretamente ou visualize-o no GitHub.

+1

1 para a festa da tristeza

Caro proprietário do bot que diz às pessoas para pararem de usar "+1":
usamos +1 para resolver o problema e não há muito mais a ser dito.

+1

+1

Existem algumas soluções alternativas, incluindo o uso de túneis SSH - mas isso requer contas ssh no host de registro. A solução alternativa a seguir não precisa disso.

Execute o encaminhador de porta do registro, da seguinte maneira:

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

E, em seguida, extraia ou envie imagens de seu registro local:

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

@rsmoorthy Isso é fantástico. Obrigado por demonstrar sucintamente a futilidade desta restrição atual.

Docker, inclua novamente esta bateria específica.

+1

Devo dizer que encorajar fortemente a segurança do usuário afetou seriamente meus pensamentos sobre o uso do docker. Eu entendo perfeitamente que podemos adicionar o sinalizador --insecure-registry ao daemon na inicialização e não vou entrar em todos os motivos que isso não funciona o tempo todo, ou pode ser impossível.

Tenho uma pergunta para os desenvolvedores do Docker, vocês realmente acham que sabem o que é melhor para o usuário final? Eu, pelo menos, não exijo SSL em meus registros, porque a rede em que eles funcionam já está totalmente criptografada. Então, por que diabos eu criptografaria o tráfego criptografado, isso realmente faz alguma coisa além de adicionar sobrecarga e mover peças para um sistema já complexo e enorme?

Além disso, existem casos de uso em que as pessoas estão usando um registro privado na Internet? O que se faz a respeito da autenticação nesse sentido? Não se poderia simplesmente puxar uma imagem para baixo e depois rasgá-la? Em vez de tentar interceptá-lo a caminho de outro computador?

TL; DR +1

+1

@Supernomad bem dito.

Veja do lado do docker: é um problema que é melhor manter nunca oficialmente implementado, mas com várias soluções alternativas possíveis para aliviar a dor. Alguns usuários gritando alto ainda são menos dolorosos do que o docker de marketing da concorrência rotulando como "inseguro de propósito" e prejudicando sua reputação para sempre.
Dito isto, +1.

@tiborvass @ewindisch Esta edição tem mais de um ano. Já se passaram mais de 8 meses desde que você disse que seria reavaliado. Você avaliou isso? Em caso afirmativo, o que foi decidido? Não deixe um irmão pendurado! :-)

Desde que este problema foi inicialmente aberto, fechado e reaberto, a comunidade encontrou várias maneiras de consertar por conta própria, principalmente para demonstrar a futilidade dessa configuração padrão:

• 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

Sem mencionar que o CoreOS agora vem com --insecure-registry 0.0.0.0/0 como padrão. Esses exemplos mostram claramente que a ideia de que há linhas de separação de interesses entre o "administrador do sistema" e o "desenvolvedor" agora é amplamente arbitrária e espúria em 2015. Na verdade, a própria ideia de contêineres (dos quais Docker é o chefe evangelista) acelerou muito essa tendência, afastando-se das operações tradicionais que ainda se preocupam em chamar qualquer pessoa de "administrador de sistema" em primeiro lugar.

De qualquer forma, adoraria ver isso fechado para sempre, de uma forma ou de outra.

+1

+1

+1

Por que devo confiar no Docker Registry com minha chave privada SSL?

Para os outros usuários do CoreOS deixados de lado por esta intromissão,
https://coreos.com/os/docs/latest/registry-authentication.html#using -a-registro-sem-ssl-configurado

@politician não poderia ter dito melhor. Definitivamente, parece que o docker está simplesmente ignorando o fato de que uma grande parte de seus usuários estão, no mínimo, insatisfeitos.

O fato é que estou migrando completamente do docker e não poderia estar mais feliz com a decisão. No momento, estou usando git e lxc e não só é mais rápido do que o docker, mas também me permite fazer o que é melhor para minha empresa e não o que outra empresa pensa, embora completa e totalmente incorretamente, ser melhor para mim.

Eu sugiro dar uma olhada nas alternativas que são honestamente melhores do que docker, como rocket, raw lxc, qemu (não o mesmo, mas ainda melhor) apenas para citar alguns.

Eu estarei sugerindo fortemente este curso de ação para todos que eu conheço que estão considerando contêineres de agora em diante. No mínimo, até que o pessoal da docker perceba que não tem ideia, e eu insisto _absolutamente_, não tenho ideia, o que é melhor para o usuário final em termos de segurança.

Desisti e comprei um certificado SSL dedicado barato. A dependência do Docker CLI no sistema CA é muito forte - os certificados autoassinados não são apenas frustrantes em termos operacionais, eles simplesmente não funcionam.

• docker-machine exclui sua substituição ca.crt entre baixo / cima
• nenhuma de suas imagens de base inclui o certificado tornando ferramentas como drone para CI impossíveis
• docker CLI usa uma pasta não padrão para certs, então isso é apenas outra coisa para lembrar.
• mesmo se você conseguir fazê-lo funcionar 18 horas depois, você sempre terá a sensação incômoda de que alguma outra coisa está quebrada

Resumindo: o Docker inflige uma penalidade contínua e persistente à sua equipe de operações ao tentar usar um certificado autoassinado.

Isso é ainda mais frustrante porque curl -k existe para a eternidade.

+1

É muito triste que eles não se importem com isso. Se algum desenvolvedor quiser apenas mexer no docker e hospedar seu próprio ambiente, normalmente você não quer mexer com certificados SSL e outras coisas. Além disso, se você tiver seu próprio servidor em casa que está longe de ser público, você simplesmente não precisa de SSL.

@buehler, você pode adicionar a opção --insecure-registry às configurações do seu daemon ou ao arquivo de configuração daemon.json ; então você só precisa configurá-lo uma vez e puxar sem ter que especificar o sinalizador

Apenas uma atualização nossa: desde então, retiramos o Registry de nossa infraestrutura e voltamos a usar nossa bifurcação personalizada de dogestry com suporte de armazenamento de Blobs do Azure . Descobrimos que o Docker Registry estava duplicando camadas e nossas máquinas estavam ficando sem espaço em disco, o que resultou em interrupções. O registro acabou sendo um beco sem saída e uma perda de tempo para nós.

@buehler apenas para concretizar a proposta de @thaJeztah , adicione esta linha à configuração:

--insecure-registry 0.0.0.0/0

Você poderá acessar qualquer registro que desejar. Funciona bem para testar coisas.

@politician a duplicação acontece se as imagens forem marcadas com repositórios diferentes. A falta de exclusão de blobs é um problema significativamente maior.

@thaJeztah se for assim tão fácil de fazer, mas 80% (número reconhecidamente arbitrário) dos usuários precisam fazê-lo, então apenas torne-o o padrão.

@justinclayton no; definir essa opção basicamente diz "ignorar qualquer problema com comunicação segura com o registro", portanto, permita ataques man-in-the-middle "fora da caixa", ou até mesmo o daemon voltando para não-TLS "http: //" . O Docker já o definiu como padrão para registros na faixa de 127.x.x.x .

Se você tiver um registro local e não quiser gerar um certificado para ele, adicionar --insecure-registry às opções do daemon leva menos de um minuto para fazer. No entanto, deve ser uma ação deliberada, não algo definido por padrão.

@thaJeztah Eu entendo seu argumento, mas isso não pode ser apenas o fim de tudo. Há uma lacuna significativa na experiência do usuário para novos desenvolvedores como resultado disso estar no lado daemon. O cenário _maioria_ em que isso é difícil é um novo desenvolvedor que segue as instruções em docker.com para baixar e executar o instalador do Docker Toolbox em seu Mac. Após a conclusão, eles imediatamente tentam executar docker pull <internally-signed-registry>/foo e são recebidos com um erro. Este é o verdadeiro problema. Talvez isso signifique que esse problema deva ser renomeado?

Existem muitas outras maneiras pelas quais isso também pode ser resolvido; Tenho certeza de que a comunidade e a empresa concordariam com um deles:

• O nome atual desse problema é '--insecure-registry deve estar em "docker pull"'. Como esse problema ainda está aberto, devo presumir que essa opção ainda está sendo considerada.
• Se uma solução de comando único para isso fosse fornecida (e documentada) que fosse simples para usuários novatos, isso resolveria o problema.
• Em nosso caso, o registro _está_ protegido. Ele usa um certificado assinado por nossa CA interna como tudo o mais em nosso ambiente de construção. Isso é segurança suficiente. Se o daemon de alguma forma fosse capaz de honrar o armazenamento de certificados do MacOS, essa dor de cabeça também iria embora.
• Se eles fossem solicitados a adicionar o certificado ou fazer essa configuração na docker-machine durante o processo de instalação do Toolbox, provavelmente também estaria tudo bem.

Informe os mais de 70 participantes deste problema em que direção você planeja tomar com isso, ou então feche o problema para que não fiquemos pendurados. Obrigado.

@thaJeztah
Não há como adicionar --insecure-registry único ao daemon opts sem reiniciar todos os contêineres em execução. Esse é um dos principais problemas. Não podemos recarregar a configuração sem reiniciar (o problema dura desde 2013), não podemos extrair imagens de outros registros inseguros sem adicionar opção ao daemon e também reiniciar. E hoje em dia ainda não temos um roteiro claro para consertar esse problema.

@apakhomov acho que pode ser adicionado à lista de alterações de configuração que podem ser atualizadas sem reiniciar https://docs.docker.com/engine/reference/commandline/daemon/#configuration -reloading. Você pode abrir uma edição separada para isso?

+1.

Alguns provedores de PaaS não dão acesso ao daemon e executam uma rede privada para o usuário (Jelastic, por exemplo).

é possível adicionar vários registros inseguros ao docker?
algo como --insecure-registry xxxx: xxxx --insecure-registry zzzz: zzzz

@kkorada --insecure-registry=0.0.0.0/0 fará o Docker se comportar como antes.

@kkorada sim, você pode especificar vários registros (o sinalizador é --insecure-registry=[] - colchetes indicam que pode ser especificado várias vezes).

Também para docker 1.12, tornaremos esta opção configurável no arquivo de configuração daemon.json , sem reiniciar o daemon. Veja a solicitação de pull aberto aqui: https://github.com/docker/docker/pull/22337

obrigado @mingfang e @thaJeztah

Como @mhamrah e @justinclayton sugeriram , eu também recomendaria uma solução usando ssh além de TLS, semelhante a como o Git permite acesso a um repositório usando ssh e TLS. Isso pode usar a solução alternativa ssh que @justinclayton listou .

Embora eu não tenha dados para apoiar minha afirmação, acho que há muito mais registros privados em execução atrás de firewalls do que registros em execução na Internet aberta. Nesse caso, o ssh é mais fácil de configurar e, se não mais, seguro do que o TLS.

Além disso, depois de ter lutado por dias com docker push e meu registro privado local rodando dentro de uma máquina virtual interna suficientemente segura (e mais tempo lutando para criar certificados autoassinados), eu acabei de realmente apreciar rkt --insecure-options=image,tls,http .

É uma loucura que esta não seja uma configuração de cliente. Obviamente, não deveria estar ativado por padrão, pois isso encorajaria a prática insegura. Colocar a configuração no daemon, entretanto, torna-o muito impraticável para propósitos de depuração ou em ambientes de desenvolvimento local.

Meu caso de uso atual: executando um ambiente de desenvolvimento com docker compose. O ambiente precisa de um registro docker local. Ele deve ser executado inteiramente em uma VM local.

A maneira docker: explicando como configurar a docker-machine para habilitar o registro inseguro em cada máquina do desenvolvedor, possivelmente exigindo que eles recriem sua docker-machine se já tiverem uma ou editem a configuração manualmente.

A solução hacky: socat rodando em cada container que precisa usar o registro, redirecionando para o localhost.

Não exatamente facilitando as coisas ...

+1

Realmente uma pena que --insecure não seja uma configuração de cliente!
Isso cria muita dor para nós, também muito semelhante a muitas das explicações acima.
Defina --insecure-registry = 0.0.0.0 / 0 por padrão para fornecer uma maneira de passá-lo para o comando docker, bem como para as configurações docker-compose.

+1

+1

É hora da festa anual da Piedade +1 novamente?

Em 13 de dezembro de 2016, à 1h00, 沙包 妖 梦[email protected] escreveu:

+1

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub ou ignore a conversa.

Se as camadas de imagens forem assinadas, não há necessidade de usar o CA PKI para segurança. Veja também como o apt / yum funciona. Além disso, usar SSL em uma LAN faz pouco sentido e em um ambiente de nuvem significa que você deve provisionar - além dos próprios certificados - uma boa fonte de aleatoriedade (consulte também: https://lukehinds.github.io/2015-03 -03-Entropia-na-nuvem /).

Resumindo: se for desnecessário, não force os usuários.

Acabei de abrir # 29736, que está relacionado.

+1, se ter um sinalizador --insecure-registry lado do cliente não for uma opção, deve haver uma maneira de especificar um certificado confiável a ser usado para docker pull e docker push . Nem todos têm acesso a certificados confiáveis ​​em um nível de sistema operacional ou acesso para brincar com o daemon do Docker.

Servidores de CI hospedados (que estão sendo usados ​​para construir imagens docker e enviar para um registro privado) são um ótimo exemplo de quando você pode não ter esse nível de acesso.

+1

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

@tiborvass
Só funciona se você tiver acesso sudo ...

+1 boa maneira de desencorajar os desenvolvedores de usar o docker

+1, eu gostaria de ver --insecure-registry para docker login também.

Eu nem vejo isso como um problema de segurança, já que você está fazendo isso conscientemente. E se alguém não autorizado obtiver acesso root, isso também não fornecerá nenhuma segurança. Que mérito essa restrição realmente tem?

Se você teve más intenções, pode simplesmente carregar sua imagem maliciosa do docker para o DockerHub, que é confiável.

+1 e, francamente, isso confunde a mente

+1 para o trem da dor.

Plus F * cking One!

Existe um PR aberto para isso?

Não AFAIK. Os links acima são gerados porque alguns dos meus próprios códigos fazem referência a esse problema. Vou puxar essa referência por um tempo para acalmar o spam aqui.

+1 também ...

+1

+1, é muito inconveniente adicionar a configuração a deamon.json e reiniciar o docker.

Máquinas diferentes têm sistemas operacionais diferentes. Alguns instalam o docker de yum 、 apt-get , e alguns diretamente usando o binário. Então eu tenho que detectar isso e reiniciar o dockerd corretamente ... isso é um desastre

Acabei de enfatizar o docker pull need --insecure-registry flag!

Faz apenas três anos - não vamos perder a esperança agora

colisão 🤣

+1

+1

O argumento de que isso incentiva os usuários a definir seus registros como seguros não é apenas presunçoso, mas também omite um ponto-chave. Ele coloca as operações em uma posição em que muitas pessoas devem ter acesso à conta root para fazer seu trabalho de operações, onde os registros docker estão se movendo muito.
Esse acoplamento, do ponto de vista da segurança operacional, cria um risco de segurança maior.

Em segundo lugar, em uma rede privada (como em um aplicativo hospedado em nuvem de várias camadas), a proteção de registros não é necessária e complica ainda mais as implementações de tecnologia que ficam no topo, exigindo camadas de gerenciamento de segurança (para lidar com a autenticação docker automatizada / atualização) sempre que um registro seguro do docker é usado.

No mínimo, o daemon do docker deve ser configurável para PERMITIR que o parâmetro de registro inseguro seja passado. Isso move o design de segurança para o local adequado - nas mãos do administrador e fora do próprio docker.

FWIW Eu ficaria feliz com um comando para "adicionar algum registro à lista de registros inseguros", uma vez que corrigir configurações json de scripts de shell é um grande problema.

+1

: +1: +1

+1

+1

+1

+1

Muitas das implementações solicitadas tornariam impossível para as empresas que utilizam o Docker aderir aos requisitos de conformidade do SOC, etc.

Deveria haver uma solução para isso, mas não acho que haja uma solução fácil que não seja uma mudança arquitetônica mais drástica em como as imagens são armazenadas e executadas.

Ainda assim, isso deve acontecer.

Não estou mais envolvido com o desenvolvimento do Docker, então vou me retirar das menções. Boa sorte a todos ^ _ ^

O requisito SOC é um bom ponto. Nesse caso, esse recurso deve ser ATIVADO com uma opção de configuração a ser adicionada à configuração do docker de todo o sistema. Dessa forma, os requisitos do SOC podem ser mantidos. Algo como "ALLOW_INSECURE_REGISTY_OPTION" que ativa o sinalizador --insecure-registry na linha de comando do docker.

Para conformidade com SOC, a opção não deve ser habilitada.

+1

Faz apenas três anos - não vamos perder a esperança agora

5

Esta proposta (em sua forma atual) é muito improvável de ser implementada, por vários
motivos, entre os quais;

• mantém a pessoa que gerencia o daemon docker responsável por quais conexões
  o daemon tem permissão para fazer. observe que esta opção pode ser "recarregada ao vivo",
  portanto, o daemon não precisa ser reiniciado para alterar a configuração.
• cada comando ou caminho de código que potencialmente interage com um registro terá
  a ser modificado; não apenas docker pull , mas também docker build , docker run ,
  docker plugin , docker service e docker stack subcomandos, bem como
  orquestradores como o swarmkit, que extraem imagens de nós de trabalho.
• Conformidade SOC (como mencionado acima)

No mínimo, o daemon do docker deve ser configurável para PERMITIR inseguro
parâmetro de registro a ser passado. Isso move o projeto de segurança para a
local - nas mãos do administrador e fora do próprio docker.

Acho que o administrador, neste caso, seria a pessoa / equipe que gerencia o
hosts nos quais o docker daemon é executado, não o usuário que se conecta ao remoto
API. Esta é a razão para esta configuração ser uma configuração de daemon.

corrigir configurações json de scripts de shell é um grande problema.

Esse é um ponto justo, mas ortogonal a esta discussão. Não é impossível_
para corrigir a configuração JSON, mas concordou que pode ser mais complicado do que outros
formatos de arquivo. Observe que esta configuração também pode ser definida por meio de sinalizadores no
o daemon, que permite que você use um arquivo de unidade drop-in do systemd para reconfigurar
o demônio.

Algo como "ALLOW_INSECURE_REGISTY_OPTION" que ativa o sinalizador --insecure-registry na linha de comando do docker.

Se você quiser permitir pulls inseguros de qualquer registro (o que seria o equivalente
de adicionar uma bandeira --insecure-registry ), você pode permitir que "a internet" seja insegura
registro; o seguinte deve permitir que qualquer endereço IPv4 seja usado como registro não seguro,
(portanto, volte para conexões não-TLS);

Por meio do arquivo de configuração /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 passando as opções como sinalizadores no daemon (que podem ser definidos em um systemd
substituir arquivo);

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