Moby: --insecure-registry должен быть включен "docker pull"

Мы запускаем внутренние незащищенные реестры докеров во всех средах CI и производственных средах. Я должен сказать, что было бы очень полезно просто разрешить доступ ко всем незащищенным реестрам, не перечисляя их один за другим. У нас есть несколько реестров в каждой среде для обеспечения высокой доступности. Это изменение значительно усложнило нам жизнь. Я собираюсь открыть еще один тикет о проблемах, который специально предназначен для решения этой проблемы, поскольку эта проблема больше связана с перемещением опции в опцию pull, а не на демон.

И есть небольшая проблема с курицей и яйцом, когда вы не используете фиксированный порт для запуска реестра.

Поскольку вы не знаете, какой порт будет назначен докером заранее, вы не можете запустить демонстрацию с флагом, который ссылается на него.

: +1:

поэтому я предполагаю, что поддержка --insecure в командной строке docker pull , принудительное отключение проверок безопасности, очевидно, для _this_ pull команды, также решит вашу проблему @proppy и @octalthorpe, верно? поскольку запуск с этим флагом не будет проверять списки вообще

@abourget также необходимо поддерживать в удаленном API.

В настоящее время докер-р разоблачить insecure_registry флага на pull функции, но он используется только для решения конечной точки: https://github.com/docker/docker-py/blob/master/ docker / client.py # L794

Виновником кажется https://github.com/docker/docker/commit/6a1ff022b0744213ed588d9c16dbb13ce055eda6

Но я не смог найти ни соответствующего PR, ни вопросов, в которых обсуждались бы эти изменения.

@tiborvass есть идеи?

@proppy - это было обработано как уязвимость системы безопасности, на которую наложено эмбарго, и не обсуждалось в публичном PR. Основная команда имела видимость и голосование по проблеме.

Мне нужно подумать о последствиях такого изменения для localhost / 127.0.0.1, но мне это не особенно нравится. Это нестандартная, необычная конфигурация, и решение хорошо задокументировано.

@ewindisch, с другой стороны, уже запущено множество демонов localhost .

Если буквально всем этим пользователям нужно будет передать --insecure-registry localhost:5000 , вы также можете сделать его значением по умолчанию.

@ewindisch У вас есть документация или руководство по тому, что составляет уязвимость класса эмбарго? Это не удаленный RCE без аутентификации. Опасность здесь не кажется достаточно острой, чтобы оправдать критическое изменение точки выпуска без предупреждения.

@mmdriley - обычно применяется определение согласно Mitre / NST. В этом случае возможна атака «человек посередине», которая позволяет выполнять произвольный ненадежный код на пораженных системах, поэтому да, мы классифицируем это как RCE. Это означает, что если бы вы использовали Docker для получения изображений, например, на ноутбуке в кафе, другой пользователь этой точки доступа Wi-Fi потенциально мог бы запускать произвольные приложения, предоставленные злоумышленником. Они также могут потенциально получить доступ к вашей учетной записи DockerHub или другим реестрам, в которых вы будете проходить аутентификацию.

РЕДАКТИРОВАТЬ: добавление ссылки для описания CVE: https://groups.google.com/d/msg/docker-user/oYm0i3xShJU/0QbAw9eN9qkJ

Да, я был неправ, говоря, что это не RCE. Это плохая ошибка и отличное свидетельство того, почему надежная подпись изображений - отличная идея. Однако эксплуатация не является тривиальной: для этого требуется, чтобы активный злоумышленник завис в Starbucks в надежде, что кто-то поблизости воспользуется Docker через небезопасный Wi-Fi. Это не будет превращено в оружие в одночасье - и, следовательно, не заслуживает обратного несовместимого изменения без предупреждения.

Как было предложено выше, существуют очевидные способы немедленно улучшить безопасность без нарушения совместимости. Например, отключение резервной копии HTTPS для index.docker.io и нескольких других популярных общедоступных реестров эффективно решило бы проблему для большинства пользователей. Добавление предупреждения к выходным данным консоли о том, что происходит откат HTTP, смягчило бы интерактивный случай. Откат HTTP будет отмечен как устаревший и удален, скажем, в выпуске следующего месяца. Наконец, очевидно, что localhost и :: 1 не уязвимы.

Опять же, мне не следовало сбрасывать со счетов степень уязвимости, но меня беспокоит, что процесс ответа и исправление не придали должного значения тому, чтобы не сломать клиентов.

В настоящее время мы динамически создаем / уничтожаем реестры докеров в среде, не имеющей полного доменного имени, доступного для многих из этих экземпляров. Поддержка параметра --insecure-repository для запросов, связанных с реестром (через удаленный API), устранит значительные сложности, которые это исправление безопасности создало для нас.

У нас аналогичная проблема с Docker 1.3.1. Мы используем локальный (частный) реестр Docker по адресу http: // docker : 5000 /. До Docker 1.3.0 он работал нормально. С Docker версии 1.3.1 он больше не работает, потому что клиент Docker автоматически предполагает, что реестр доступен по HTTPS. Но мы вообще не используем HTTPS.

Было бы неплохо реализовать резервный механизм, который использует HTTP, если серверы реестра Docker недоступны через HTTPS.

@kruxik, если вы используете --insecure-registry docker:5000 при запуске демона, он вернется к HTTP.

@tiborvass спасибо за предложение. Ты прав. Но если у вас много разработчиков со своими рабочими станциями и ноутбуками, установка --insecure-registry на каждой станции непрактична. По крайней мере, пусть это как необязательный параметр для операций pull / push нам будет достаточно;)

+1

У нас это работало с 1.3.0, но с 1.3.1.

версия докера
....
Версия сервера: 1.3.1
....
docker push 10.121.4.236:5000/debian7/consul
-> .... Если этот частный реестр поддерживает только HTTP или HTTPS с неизвестным сертификатом CA, добавьте --insecure-registry 10.121.4.236:5000 к аргументам демона. В случае HTTPS, если у вас есть доступ к сертификату CA реестра, флаг не нужен; просто поместите сертификат CA в

Понизить
Версия сервера: 1.3.0
docker push 10.121.4.236:5000/debian7/consul
-> контейнер загружается без проблем.

Для других, у которых возникли проблемы с 1.3.0 по 1.3.1, мне пришлось внести следующие изменения для OS X с помощью 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

тогда вы _должны_ уметь тянуть докер.

Если вы используете fig, вам также понадобится Fig 1.0.1 и выполните:

$ fig up --allow-insecure-ssl

@mhamrah Спасибо! Потратил часы, пытаясь это исправить ...

+1 к предположению, что localhost безопасен. Кто-нибудь вообще против этого?

Да, если предположить, что localhost безопасен, это очень поможет. Я использую vagrant для своего докер-бокса, поэтому обновлять скрипт инициализации каждый раз, когда я уничтожаю или открываю ящик, просто неэффективно. Я предполагаю, что теперь мне придется куколизировать свой докер-бокс, чтобы я мог изменить init на бродяге.

Также было бы неплохо использовать флаг --insecure для pull и push, поэтому при необходимости я мог бы использовать IP-адрес бродячего ящика.

@thocking : если предполагается, что https://github.com/docker/docker/issues/8898

Честно говоря, мне также было интересно, почему мои автоматизированные сборки контейнеров Jenkins не смогли протолкнуть ...
(Хорошо иметь тест перед запуском в производство).
Я должен проверить, действительно ли эта «особенность» была анонсирована - в противном случае я буду больше параноиком относиться к столь радикальным изменениям в поведении демонов.

Чего мне не хватает в этом обсуждении:
Почему я даже должен указать демону использовать "по умолчанию" безопасный / незащищенный режим для каждого хоста?

Разве не было бы более продуктивно настроить реестр с этим поведением по умолчанию?
Таким образом, в зависимости от настройки, если не указан параметр --secure или --insecure, демон должен запросить
если возможен безопасный способ, и если нет, то использовался откат на небезопасный.

Одна из главных особенностей docker - это то, что им очень легко пользоваться и настраивать полный env. пожалуйста, не убивайте этот ВАУ-эффект такими "релизами / решениями" ...

только мои 2 цента ...

Проблемы здесь схожи с теми, что указаны выше, включая @jwthomp. Я потратил более 10 часов, пытаясь решить эту проблему, а тем временем перешел на докер 1.3.0.

Я запускаю реестр докеров под Marathon, и реестр докеров в настоящее время "поддерживает SSL, запустив nginx в качестве интерфейса" (см. Https://github.com/docker/docker-registry/issues/697), но использование nginx в качестве интерфейса осложняется тем, что Marathon запускает реестр докеров на различных подчиненных хостах / портах.

Я мог бы включить SSL прямо в реестре (используя GUNICORN_OPTS), но тогда он _Only_ говорит на SSL и не может пройти проверки работоспособности Marathon.

Я изменил систему конфигурации Bamboo HAProxy, чтобы также настроить HAProxy в качестве https-интерфейса для всех служб, как это было бы с nginx, но у меня все еще есть проблемы с докером, проверяющим сертификат в моем частном реестре, так что это все еще не подходит мне в это время.

Все очень хорошо для защиты от RCE, но также должна быть некоторая обратная совместимость. По крайней мере, флаг для демона докеров, чтобы указать все реестры как небезопасные. Должен быть способ указать http или https как часть имени реестра в каждой команде docker pull. На данный момент 1.3.1 кажется большой уловкой-22 для всех, кто использует частный реестр.

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

Отлично.
Пт, 14 ноября 2014 г., 10:42 Илья Радченко [email protected]
написал:

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

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/docker/docker/issues/8887#issuecomment -63082089.

@mhamrah Мне не нужно было удалять ключи ssh и т.д. Я просто добавил нужную строку в / var / lib / boot2docker / profile и перезапустил докер. Спасибо за совет!

Прохладный. У меня были проблемы даже с ssh'ing, я полагаю, из-за какой-то версии
несоответствие между docker iso. Я фактически перешел на использование vagrant +
coreos для поддержки докеров, и он хорошо работает. Вам просто нужно установить
DOCKER_HOST, который boot2docker выполняет автоматически.

20 ноября 2014 г. в 1:52:21 Кайван Сильван [email protected]
написал:

@mhamrah https://github.com/mhamrah Мне не нужно было удалять
ключи ssh и т. д. Я просто добавил нужную строку в
/ var / lib / boot2docker / profile и перезапустил докер. Спасибо за совет!

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/docker/docker/issues/8887#issuecomment -63768043.

Извините, ребята, я хотел ответить раньше.

Как уже сказал @ewindisch , мы не хотим поощрять такое поведение на стороне клиента. Боль, вызванная требованием флага в качестве флага демона, заключается в том, что люди фактически настраивают TLS в своем реестре. Иначе стимула нет. Спасибо за понимание.

В официальном реестре докеров есть "официальный" образ реестра докеров. Рекомендуется использовать без TLS.

Если Docker хотел бы, чтобы пользователи настраивали TLS в своем реестре, не имеет ли смысла балансировать «вызванную болью» с равным и противоположным «уменьшением боли» , предоставляя официальный образ докера, который по умолчанию предоставляет TLS?

@tiborvass . Вы игнорируете внутренний случай разработки за брандмауэром. Итак, теперь мне нужно либо настроить обратный прокси с включенным SSL перед моим реестром (для этого просто нет причин), либо мне нужно обратиться к каждому из моих разработчиков и изменить аргументы для запущенного демона. внутри boot2docker. Это не имеет никакого смысла. Существует множество сред разработки, которые обеспечивают настраиваемую безопасность, в которой безопасность часто отключена для сред разработки. Я удивлен, что вы закрыли этот вопрос, когда за решение было подано так много голосов.

А как насчет внесения в белый список всех частных IP-адресов? Середина?

Или сделайте имя протокола, http или https частью имени изображения для pull.

@tiborvass и @sroebuck, и @blevine - отличные

Привет, @tiborvass ! Этот вопрос кусает и нас прямо сейчас. Я предпочитаю подход @nickandrew . Будет немного больше похоже на git clone, а также откроет возможность для различных подключаемых протоколов в будущем. Выигрыш для докера, так как он уменьшит взаимосвязь и выигрыш для сообщества.

@blevine обратите внимание, что с 1.3.2 localhost по умолчанию занесено в белый список, см .: https://github.com/docker/docker/pull/9124

Вы можете заставить реестр прослушивать локальный хост, передав: -p 127.0.0.0:5000:5000 в docker run

@proppy , я не совсем понимаю, как мне помогает прослушивание на localhost.

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

Или он должен стать настоящим URL-адресом? Я ничего не знаю о протоколе реестра, но не кажется несовместимым расширить текущий синтаксис для указания правильного URL-адреса.

@blevine означает, что вы можете настроить локальный реестр зеркалирования.

Arg, теперь мне нужно base64 декодировать мою облачную конфигурацию для coreos, чтобы мои машины запустились

@tiborvass Вау, это действительно прискорбно. :(

У нас есть кластеры разработки, которые мы запускаем и отключаем на лету, и часть того, как мы обрабатываем эти кластеры, - это создание реестра для этого кластера. Кластер может состоять из множества физических узлов или виртуальных машин, а также может находиться на настольном компьютере или ноутбуке разработчика (хотя обычно мы не можем запустить полный стек). Каждый кластер представляет собой полностью автономный стек и среду разработки. У нас также есть инструменты командной строки на основе докеров, которые позволяют разработчику взаимодействовать с любой настройкой кластера разработки в компании.

В такой сложной и динамичной среде превращение TLS в реестр в обязательное требование - огромная боль. Необходимость изменять запуск демона докеров каждый раз, когда мы настраиваем, мы добавляем новую сеть, в которой может находиться реестр, также является проблемой.

Не поймите меня неправильно, я ценю мысли, стоящие за желанием поддерживать исключительно TLS, однако я призываю вас учитывать, что существуют допустимые случаи, когда среда безопасно поддерживает устранение сложности TLS для уменьшения боли и инфраструктуры, необходимой для поддержки Это.

@tiborvass +1. +1000. Это создало совершенно ненужную сложность для
нас к высокодинамичному рабочему процессу разработки. Барьер для входа был
здесь значительно повысился за то, что нужно только подать заявку в
производственный контекст. Пожалуйста, прекратите нашу боль.

Во вторник, 9 декабря 2014 г., Джефф Томпсон [email protected]
написал:

@tiborvass https://github.com/tiborvass Вау, это один из таких
К сожалению, виртуальный стол переворачивает моменты. :(

У нас есть кластеры разработки, которые мы поднимаем и опускаем на лету и расставляем
Чтобы понять, как мы обрабатываем эти кластеры, мы создаем реестр для этого кластера. А
кластер может состоять из множества физических узлов или виртуальных машин, а также может находиться на
настольный компьютер или ноутбук разработчиков (хотя обычно мы не можем запустить
полный стек). Каждый кластер - это полностью автономный стек и разработка
среда. У нас также есть инструменты командной строки на основе докеров, которые позволяют
разработчик взаимодействует с любым кластером разработки в компании.

В такой сложной и динамичной среде создание TLS в реестре
требование - это огромная боль. Необходимость изменить запуск демона докеров
каждый раз, когда мы настраиваем, мы добавляем новую сеть, в которой может находиться реестр.
одинаково боль.

Не поймите меня неправильно, я ценю то, что стоит за желанием поддержать
TLS, однако есть случаи, когда среда безопасно поддерживает удаление
сложность TLS для уменьшения боли и необходимой инфраструктуры
чтобы поддержать это.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/docker/docker/issues/8887#issuecomment -66367681.

@justinclayton @jwthomp @mattwilliamson @nickandrew @blevine

Разве --insecure-registry 0.0.0.0/8 решает вашу проблему? Таким образом, вы все еще можете использовать HTTP.

Эту нотацию CIDR можно использовать более детально для включения конфигураций «за брандмауэром», указав диапазоны, такие как «--insecure-registry 172.16.0.0/12». Я вообще не советую использовать эту опцию, но я рекомендую пользователям, выбирающим эту опцию, использовать более избирательный диапазон (например, их IP-пространство), а не все адреса, насколько это возможно с 0.0.0.0/8.

Демон docker встроен в coreos, поэтому мне нужно каким-то образом добавить эти флаги при запуске в кластере. Я думаю, что гораздо более гибко использовать команду pull для сред, в которых вы не можете управлять самим демоном докера.

Это то же самое, что сказать нам изменить файл php.ini для общего хоста php.

9 декабря 2014 г. в 22:18 Тибор Васс [email protected] написал:

@justinclayton @jwthomp @mattwilliamson @nickandrew @blevine

Разве --insecure-registry 0.0.0.0/8 не решает вашу проблему? Таким образом, вы все еще можете использовать HTTP.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

Флаги выполнения

Примеры изменения конфигурации Docker есть на сайте CoreOS. Можно легко изменить инструкции, добавив вместо этого флаг отладки, чтобы указать флаг небезопасного реестра.

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

@tiborvass вся экосистема конфигурации должна поддерживать это, чтобы работать легко из коробки. Люди не ожидают внесения нестандартных настроек в запуск демона везде, где они могут тянуть (boot2docker, coreos, все, что установлено с модулями chef / puppet и т. Д.), Когда они переходят к этапу настройки своего собственного внутреннего реестра. Сам официальный образ контейнера реестра _ больше не работает_ при выполнении действий, отмеченных как "рекомендованные" в файле readme. На самом деле в файле readme нет никакого упоминания о TLS, и его настройка - нетривиальный процесс. Кроме того, как вкратце упомянул @mattwilliamson выше, существует множество случаев, например, в общих средах сборки, когда кто-то, использующий демон для извлечения изображения, не совпадает с человеком, настраивающим демона.

Суть в том, что доведение этого аргумента до аргументации на стороне клиента, несомненно, является менее разрушительным и, что более важно, менее предписывающим решением. Docker уже стал примитивом в десятках, если не сотнях других проектов и рабочих процессов, и поэтому не должен диктовать шаблоны использования в этой области. Тот факт, что Git предлагает простой вариант конфигурации среды выполнения для отключения http.sslverify, не означает, что Линус Торвальдс поощряет людей не защищать свои конфиденциальные данные в ситуациях, когда это важно.

Аналогия с git - хороший пример того, как это должно работать. Git не заставляет вас использовать TLS, и это решение пользователя при настройке хоста, какой уровень он хочет поддерживать. Это также решение пользователя, когда он выбирает, какой уровень безопасности ему требуется (или который он хочет обойти). Настройка - это простой шаг, глобально или для каждого репо. Хотя Docker не заставляет нас использовать TLS, делая альтернативу нетривиальной, он не предоставляет других разумных вариантов.

Обозначение CIDR допускает, возможно, подход «тяжелого молотка», а AFAIK не сопоставляется с именами DNS, поэтому даже если я замаскирую 10.0.0.0/16, потянув some.private-registry.com за 10,0 / 16 вон ' т работать. Что еще более важно, настройка не тривиальна.

Docker преуспевает в своей простоте для контейнеризации и значительно снижает барьер для развертывания приложений в различных средах. Все мы знаем о преимуществах. Большинство разработчиков не могут ответить на простые вопросы о нотации CIDR, файл конфигурации докера может находиться в нестандартных местах (местоположения boot2docker и CoreOS отличаются от других дистрибутивов), и довольно легко испортить эти файлы конфигурации с помощью сложных циклов обратной связи для успех. Я должен следить за системным журналом? Ой, подождите, я на RHEL и это сообщения?

Новый разработчик может легко скопировать и вставить фрагмент docker pull , но имея их ssh на хосте boot2docker, запустить vi, отредактировать файл конфигурации, а затем следить за системным журналом на предмет ошибок ... не так уж и много. И о да, вы забыли перезапустить демон докера.

Вот что я бы хотел увидеть:

• Настройки демона Docker, применяемые с помощью команды docker
• Параметры вытягивания Docker для переопределений TLS, указанные с помощью команды docker
• Параметры извлечения Docker сохраняются в командах для определенных реестров

Да, но Amazon не позволяет изменять конфигурацию автомасштабирования. Придется сделать копию или сделать новую.

9 декабря 2014 г. в 23:55 Эрик Виндиш [email protected] написал:

Флаги выполнения настраиваются с помощью CoreOS. Вы можете отредактировать файл конфигурации systemd для Docker. Для настройки этого для кластера вы можете использовать cloud-config.

Примеры изменения конфигурации Docker есть на сайте CoreOS. Можно легко изменить инструкции, добавив вместо этого флаг отладки, чтобы указать флаг небезопасного реестра.

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

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

В настоящее время мне приходится обходить эту проблему в среде разработки моей компании, выполняя эту тщательно изученную команду каждый раз, когда я выполняю 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"'

Вот это боль. Внедрение докеров в моей компании с более чем 400 сотрудниками застопорилось из-за этой проблемы. Мы абсолютно не используем TLS в нашей внутренней среде разработки, где все контролируется. Мы приветствуем его использование для общедоступных репозиториев хабов и считаем, что принуждение к этому где-либо еще во всех случаях является огромной ошибкой.

@CleanCut очень хорошо

@CleanCut awesome - Я бы хотел, чтобы в boot2docker добавлялась дополнительная информация в начальную полезную нагрузку boot2docker init , которая затем делала бы это за вас.

не решает специфических проблем boot2docker, не связанных с vm, но --insecure-registry - не единственная специфическая для сайта настройка, которую хотят пользователи b2d.

Можете ли вы сделать запрос на перенос или проблему для этого в репозитории boo2docker, пожалуйста?

Действительно поднимает барьер для кого-то, чтобы использовать проект, которому аплодируют, для снижения барьеров.

13 декабря 2014 г. в 02:10 Джастин Клейтон [email protected] написал:

@CleanCut очень хорошо

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

@SvenDowideit Конечно. Вот

Похоже, в этой беседе есть консенсус, что это не решенная проблема; не могли бы мы повторно открыть эту проблему?

Да, пожалуйста!
Le 2014-12-15 15:05, "Джастин Клейтон" [email protected] автор:

Похоже, в этой теме есть консенсус, что это не решенная проблема.
проблема; не могли бы мы повторно открыть эту проблему?

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/docker/docker/issues/8887#issuecomment -67055878.

+1. Мне нечего добавить, но я просто хочу выразить свое разочарование по поводу этого решения. Как и все остальные, я веду реестр в локальной сети, где безопасность обеспечивается до тошноты в другом месте. У меня работают десятки док-контейнеров, которые теперь нужно отскочить, чтобы добавить флаг «хорошо документированный».

@bfirsh - это один из тех примеров, когда конфигурационный файл демона Docker и kill -HUP <dockerdaemonpid> были бы замечательными -

@SvenDowideit +1 для функции перезагрузки, действительно раздражает перезапуск сервера с помощью простой настройки.

+1

Простите меня, если я не понимаю все правильно, но похоже, что эта проблема лежит в основе моего собственного сценария (похожего на тот, который описан @blevine, где у моей компании есть прокси-сервер для перезаписи сертификатов, из-за которого я не могу даже поговорите с общедоступным реестром Docker Hub). Я знаю, что в конечном итоге я захочу создать свой собственный частный реестр, но я только на этапе обучения, и я еще не уверен, буду ли я использовать Docker. Это кошмар UX для тех, кто находится на ранних стадиях внедрения.

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

+1, чтобы возобновить это обсуждение, потому что похоже, что сообщество не очень довольны текущим решением.

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

просто пытаюсь поразить это со всех сторон, пока мы не услышим окончательный ответ по этой теме.

+1, в настоящее время это сложно настроить и работать.

@mhamrah делает отличные

Реестры, использующие самозаверяющие сертификаты, также являются проблемой, особенно
в контексте разработчика с использованием boot2docker, который переключился на файл только для чтения
система. Это требует дополнительного и другого шага настройки, чтобы
загрузите запущенный vm.

Я считаю, что все, кто размещен в этой теме, видят ценность и выгоду
докеров, используют его ежедневно, пытаются продвигать в своих
организаций, но испытывают болезненную и ненужную проблему,
препятствует усыновлению.

Насколько мы все знаем, докер все еще неизвестен многим техническим специалистам.
особенно внутри предприятия. Документация помогает, но мы все еще
прыжки через обручи, и это большой блокиратор с отрицательным общим
эффект.
В воскресенье, 25 января 2015 г., в 17:54 Джей Тейлор написал на [email protected] :

+1, в настоящее время это сложно настроить и работать.

@mhamrah https://github.com/mhamrah делает отличные выводы . Не заставляйте
вещи, пусть пользователь решает и настраивает для своих нужд.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/docker/docker/issues/8887#issuecomment -71398193.

+1 хорошо для быстрого опробования

: +1:

: +1:

Очень досадно, что мы все еще не можем извлекать данные из небезопасных реестров, не передав флаг демону докера. Это еще одна неприятность для каждой новой машины, которую мы развертываем.

+1

Некоторые мысли:

1. можно ли использовать подстановочные знаки имени хоста? например, --insecure-registry=*.internal
2. Можно ли обрабатывать самоподписанные сертификаты иначе, чем http?
3. связанный с 2, может ли докер делать что-то похожее на SSH и предлагать пользователю принять самозаверяющий сертификат всякий раз, когда он видит новый / громко жаловаться, если есть несоответствующий?

И пока я делаю предложения, почему бы не рассматривать localhost как всегда безопасный? (как это делает Chrome)

Изменить: ах, я вижу, что это уже есть.

+1000 на это .. и +1 на функцию перезагрузки конфигурации, вот что делает это вдвое хуже. Я остался с v1.2, потому что я полагал, что сопровождающий наверняка поймет, насколько раздражает флаг --insecure-registry на демонах для развертывания и исправит его, но почему-то второстепенные выпуски продолжают игнорировать его.

Например, если бы мне пришлось изменить IP-адрес своего частного реестра по какой-либо причине, мне пришлось бы перезапускать каждый демон докера на каждой виртуальной машине - только потому, что мой реестр изменился !? Эти две вещи никогда не должны быть связаны так тесно. И совет людям просто добавить 0.0.0.0/8 в первую очередь разрушает всю цель реализации безопасности.

Добавление этого флага к командам push / pull кажется таким очевидным, как резерв для флага демона, пожалуйста, объясните мне, почему они все еще борются с ним, но тем временем добавляют функции «приятно иметь».

Комментарий @agquick очень

Понимая, что это постоянная проблема для значительного числа пользователей, мы пересматриваем возможность добавления --insecure в pull . @ewindisch и я будем работать над PR, который мы

Приносим извинения за долгое ожидание и благодарим за то, что высказали свое мнение и указали на свои болевые точки.

@tiborvass Я могу представить себе такое же большое количество пользователей, которые _не__ хотят разрешать извлечение из небезопасных реестров. Я понимаю, что в настоящее время Docker не имеет детального контроля над разрешениями / конфигурацией, но если есть шанс «заблокировать» это, я думаю, это было бы неплохо.

О боже, сделай это так! Собирался реализовать сам.

Отправлено с моего смартфона BlackBerry 10 в сети Bell.
Откуда: Себастьян ван Стейн
Отправлено: понедельник, 23 февраля 2015 г., 16:53
Кому: докер / докер
Ответ в теме: docker / docker
Копия: Кристофер Цеплак
Тема: Re: [docker] --insecure-registry должен быть на "docker pull" (# 8887)

@tibor vasshttps: //github.com/tiborvass Я могу представить себе такое же большое количество пользователей, которые не хотят разрешать извлечение из небезопасных реестров. Я понимаю, что в настоящее время Docker не имеет детального контроля над разрешениями / конфигурацией, но если есть шанс «заблокировать» это, я думаю, это было бы неплохо.

-
Ответьте на это письмо напрямую или просмотрите его на Gi tHubhttps: //github.com/docker/docker/issues/8887#issuecomment -75644600.

@thaJeztah Я пытаюсь понять, какой вариант использования, о котором вы думаете, означает, что у нас не может быть флаг --insecure-registry для docker pull .

• если пользователь не хочет, чтобы его случайно пропустили MITMed в безопасном реестре, он может просто избежать передачи --insecure-registry
• если пользователь хочет принудить пользователей к тому, что все образы поступают из безопасных реестров (то есть «корпоративный» сценарий), он в любом случае не может на самом деле это сделать в настоящий момент!

Не могли бы вы подробнее рассказать о том, что запрещает docker pull --insecure-registry ?

Чтобы подробнее остановиться на моем втором пункте, я не понимаю, как бы вы заблокировали это, не переосмыслив значительную часть того, как работает докер! Помимо возможности получить docker load tarball, который вы можете получить, написав свой собственный инструмент для удаления реестра, и используя docker run -v для повышения привилегий и добавления чего-либо к аргументам демона, есть очень простой способ обойти любые "принудительное исполнение":

$ 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

если пользователь хочет принудить пользователей к тому, что все образы поступают из безопасных реестров (то есть «корпоративный» сценарий), он в любом случае не может на самом деле это сделать в настоящий момент!

Это сценарий, да.

Чтобы подробнее остановиться на моем втором пункте, я не понимаю, как бы вы заблокировали это, не переосмыслив значительную часть того, как работает докер.

Я полностью понимаю, что (на данный момент) нет возможности заблокировать его. Пользователи, имеющие доступ к docker.sock имеют фактически root-доступ, поэтому могут изменять все, что захотят. Кроме того, они по-прежнему смогут изменить флаг демона и перезапустить демон.

Однако он _должно_ дать пользователю четкий сигнал, если docker pull --insecure-registry .. выдает ошибку («Небезопасные реестры отключены»), что _вого_ уведомляет пользователей о том, что это нежелательно, например, при попытке попробовать какой-либо пример, который они нашли. где-то.

Итак, охватит ли он все случаи? Нет. Было бы больно, я тоже так не думаю.

Я лично считаю, что это принесет больше вреда, чем пользы, просто потому, что это вводит людей в заблуждение, заставляя их думать: «О, смотрите, докер применяет это», хотя на самом деле это очень поверхностная защита. Я мог бы продолжить, но, в конце концов, думаю, дело в вкусе.

Если вы хотите узнать, как это может быть больно, просто прокрутите вверх. При таком подходе существует множество проблем UX, которые создают препятствия для принятия, и все они подробно описаны выше.

Я рассматриваю проблемы в основном с докером, который не может перезапуститься, не убивая суб
контейнеры. которые значительно усложняют его настройку / перенастройку.

В среду, 15 апреля 2015 г., в 20:11, Ян Крюгер [email protected]
написал:

+1

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/docker/docker/issues/8887#issuecomment -93362359.

Я очень разочарован тем, что до сих пор не было предпринято никаких действий по этому поводу. Очевидно, это причиняет боль многим людям.

Это явно раздражает огромное количество людей, сейчас активно блокирует мою работу. Необходимость перезапуска демона Docker, чтобы разрешить извлечение из небезопасного реестра, варьируется от раздражающего до совершенно невозможного в зависимости от ситуации, в которой вы находитесь.

Главный аргумент в пользу этого, по-видимому, заключается в том, что системный администратор должен иметь возможность заблокировать систему и убедиться, что можно извлечь только образы из безопасных репозиториев. Этот вариант использования определенно реален, но я думаю, что он плохой по умолчанию. Кажется более разумным иметь флаг, который можно передать демону при запуске, например --no-insecure который отключает использование --insecure-registry в pull . Таким образом, администратор может заблокировать вещи, если он / она действительно этого хочет.

Для тех, кто очень хочет такого поведения, я предлагаю следующий обходной путь. Я понимаю, что это не будет жизнеспособным для всех пользователей, поскольку он не использует Docker API для извлечения. Это тоже несколько медленный ...

См. Мой проект docker-pull: https://github.com/ewindisch/docker-pull

Вы бы использовали его как таковой:

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

Также можно разрешить все реестры как небезопасные:

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

Напомню, что делать это по-прежнему крайне не рекомендуется.

@ewindisch отличный хак.

Еще одно довольно хорошее решение - использовать туннель 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

Это оба фантастических обходных пути!

Я тоже хотел бы, чтобы значение по умолчанию было отменено.

15 апреля 2015 г. в 18:14 Джо Долинер [email protected] написал:

Я очень разочарован тем, что до сих пор не было предпринято никаких действий по этому поводу. Очевидно, это причиняет боль многим людям.

Это явно раздражает огромное количество людей, сейчас активно блокирует мою работу. Необходимость перезапуска демона Docker, чтобы разрешить извлечение из небезопасного реестра, варьируется от раздражающего до совершенно невозможного в зависимости от ситуации, в которой вы находитесь.

Главный аргумент в пользу этого, по-видимому, заключается в том, что системный администратор должен иметь возможность заблокировать систему и убедиться, что можно извлечь только образы из безопасных репозиториев. Этот вариант использования определенно реален, но я думаю, что он плохой по умолчанию. Кажется более разумным иметь флаг, который можно передать демону при запуске, например --no-insecure, который отключает использование --insecure-registry в pull. Таким образом, администратор может заблокировать вещи, если он / она действительно этого хочет.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

так что это снова открывается, и текущий статус через 4 месяца ничего, и в качестве обходного пути использовать кучу хаков? : - / Есть какие-то дискуссии об этом где-то еще, или это просто мертво?

И да, +1

+1

+1

Хочу отметить, что я подсчитал количество «+1» на этой странице, и на данный момент счет составляет 31. Это не считая других поддерживающих комментариев, которые на самом деле не включают эту точную строку.

Проблема здесь в том, что включение --insecure при извлечении забирает управление у системного администратора, которому оно принадлежит.
Безопасность - это сложно, и внесение изменений для ослабления безопасности - немаловажное решение.
Кроме того, люди, которые полностью довольны текущей настройкой, не собираются приходить сюда и -1 это тоже.
С другой стороны...
Перенастроить демон для включения небезопасного извлечения из реестра - тривиальная задача.
Также легко настроить некоторые самозаверяющие сертификаты, и даже не нужно повторно настраивать докер.

«Системный администратор» - это один из вариантов использования докера, но я, «разработчик» и «не-системный администратор», одинаково допустимы. Для разработчика предоставление опции --insecure снижает трение в рабочем процессе.

Возможно, мы могли бы получить лучшее из обоих миров, предоставив параметр, который системные администраторы могли бы указать, чтобы _ запретить_ использование параметра --insecure . Таким образом, системные администраторы по-прежнему имеют полный контроль, но случаи, когда они не являются системными администраторами, не должны иметь дело с болью рабочего процесса.

То, что тривиально для системного администратора, может оказаться на удивление обременительным для несистемных администраторов. Мне пришлось помочь почти двум десяткам разработчиков внести (и переделать) это изменение конфигурации в 5 различных ОС, используемых в нашей группе разработчиков. На самом деле я поддерживаю сценарий для автоматизации изменения конфигурации для наших сред.

Наши системные администраторы в настоящее время не настраивают самозаверяющие сертификаты для нашего реестра, независимо от того, тривиально это сделать или нет.

В любом случае, даже если это не изменится, со временем люди к ним приспособятся. Я полагаю, что боль, с которой я сталкиваюсь, исчезнет в следующий раз, когда наши системные администраторы проведут обслуживание реестра, потому что в этот момент мы сможем установить фактические сертификаты SSL. Возможно, в этом все дело. Сделайте так, чтобы было легче выбрать безопасный путь, чем идти вперед по небезопасному.

: +1: @CleanCut , и все остальные сказали все. Я работаю только с кейсом разработчика, и перенастройка демона докера для нас просто пустая трата времени.

Если у вас есть доступ к сокету докера сегодня, вы _системный администратор. Вы
root уже есть, у вас есть "docker load" и уже есть обходные пути
небезопасный реестр тянет. Добавление опции изображения к клиенту не будет
любой менее безопасный, чем статус-кво.

Однако есть кое-что сказать о намеренном увеличении
трение для разработчиков, пытающихся сделать что-то не то в других, чтобы соблазнить
их, чтобы сделать правильный.
18 июня 2015 г., 12:41, «Брайан Гофф» [email protected] написал:

Проблема здесь в том, что включение --insecure on pull забирает контроль
от системного администратора, которому он принадлежит.
Безопасность - это сложно, и внесение изменений, чтобы ослабить безопасность, - непростая задача.
решение.
Кроме того, люди, которые полностью довольны текущими настройками, не собираются
прийти сюда и -1 это тоже.
С другой стороны...
Перенастроить демон, чтобы разрешить небезопасное извлечение из
реестр.
Также легко настроить некоторые самозаверяющие сертификаты, и даже не нужно
перенастроить докер.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/docker/docker/issues/8887#issuecomment -113213172.

@ewindisch @tiborvass, читая ответ, я вижу https://github.com/docker/docker/issues/8887#issuecomment -75638745;

Понимая, что это постоянная проблема для значительного числа пользователей, мы пересматриваем возможность добавления --insecure to pull. @ewindisch и я будем работать над PR, который мы
Приносим извинения за долгое ожидание и благодарим за то, что высказали свое мнение и указали на свои болевые точки.

Это все еще текущая позиция? (Не думаю, что пиар был создан)

+1

Это продолжает беспокоить и раздражать меня ежедневно.

:( грустный конус.

--inscure имеет полный смысл с точки зрения разработчика. Это на человека, реализующего докер в своей среде, чтобы сделать его безопасным.

+1

: +1:

_ПОЛЬЗОВАТЕЛЬСКИЙ ОПРОС_

_ Лучший способ получить уведомление об изменениях в этом обсуждении - нажать кнопку «Подписаться» в правом верхнем углу. _

Перечисленные ниже люди оценили ваше содержательное обсуждение случайным +1:

@justinclayton
@anandkumarpatel
@ tangr1
@ fred4jupiter
@mingfang
@djannot
@Frusty
@ tobegit3hub
@testaccountspivey
@mhamrah
@mwhooker
@ Райан-без гражданства
@jonathanvaughn
@gollawil
@ebartz
@maelp

+1

+1

+1

Мы используем внутренний реестр в закрытой сети, добавление этого упростит нам развертывание.

+1

Если эта проблема все еще не решена к Хэллоуину, я думаю, что все +1 должны устроить годовщину в честь годовщины утопления в наших докерах.

+1 для вечеринки печали!

14 сентября 2015 года в 13:32 Гордон [email protected] написал:

ОПРОС ПОЛЬЗОВАТЕЛЯ

Лучший способ получить уведомление об изменениях в этом обсуждении - нажать кнопку «Подписаться» в правом верхнем углу.

Перечисленные ниже люди оценили ваше содержательное обсуждение случайным +1:

@justinclayton
@anandkumarpatel
@ tangr1
@ fred4jupiter
@mingfang
@djannot
@Frusty
@ tobegit3hub
@testaccountspivey
@mhamrah
@mwhooker
@ Райан-без гражданства
@jonathanvaughn
@gollawil
@ebartz
@maelp

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

+1

+1 для партии печали

Уважаемый владелец бота, который говорит людям, чтобы они перестали использовать «+1»:
мы используем +1, чтобы разобраться с этим, и больше нечего сказать.

+1

+1

Есть несколько обходных путей, в том числе использование туннелей SSH, но для этого требуются учетные записи ssh на хосте реестра. Следующее обходное решение не требует этого.

Запустите переадресацию портов реестра следующим образом:

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/your-image
docker push localhost:5000/my-image

@rsmoorthy Это фантастика. Спасибо, что лаконично продемонстрировали бесполезность этого текущего ограничения.

Докер, пожалуйста, снова включите именно эту батарею.

+1

Я должен сказать, что насильственное поощрение безопасности пользователя серьезно повлияло на мои мысли об использовании докера. Я полностью понимаю, что мы можем добавить флаг --insecure-registry к демону при запуске, и я не буду вдаваться во все причины, которые не работают постоянно или могут быть невозможными.

У меня вопрос к разработчикам Docker: вы действительно думаете, что знаете, что лучше для конечного пользователя? Я, например, вообще не требую SSL в моих реестрах, потому что сеть, в которой они работают, уже полностью зашифрована. Так зачем же мне шифровать зашифрованный трафик, действительно ли это что-то делает, кроме добавления служебных данных и перемещения частей в уже сложную и массивную систему?

Кроме того, действительно ли существуют случаи, когда люди используют частный реестр через Интернет? Что делать с аутентификацией в этом смысле? Разве нельзя просто снять изображение, а затем разорвать его на части? Вместо того, чтобы пытаться перехватить его на пути к другому компьютеру?

TL; DR +1

+1

@Supernomad хорошо сказано.

Посмотрите на это со стороны докера: это одна проблема, которую лучше оставить, никогда официально не реализованную, но с множеством возможных обходных путей, чтобы облегчить боль. Громкие крики некоторых пользователей все же менее болезненны, чем маркетинговая маркировка докеров конкурентов как «преднамеренно небезопасная» и навсегда наносящая ущерб его репутации.
Сказав это, +1.

@tiborvass @ewindisch Этому выпуску больше года. Прошло более 8 месяцев с тех пор, как вы сказали, что его нужно пересмотреть. Вы это оценили? Если да, то что было решено? Не оставляйте брата в подвешенном состоянии! :-)

Поскольку эта проблема была изначально открыта, закрыта и снова открыта, сообщество придумало множество способов исправить это самостоятельно, в основном, чтобы продемонстрировать бесполезность этого параметра по умолчанию:

• 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

Не говоря уже о том, что CoreOS теперь по умолчанию поставляется с --insecure-registry 0.0.0.0/0 . Эти примеры ясно показывают, что идея о разделении проблем между «системным администратором» и «разработчиком» в 2015 году в значительной степени произвольна и ложна. Фактически, сама идея контейнеров (из которых Docker является их главным евангелист) значительно ускорила эту тенденцию, отказавшись от традиционных операций, которые до сих пор пытаются называть кого-либо «системным администратором».

В любом случае, я бы хотел, чтобы это закрылось навсегда, так или иначе.

+1

+1

+1

Почему я должен доверять Docker Registry мой закрытый ключ SSL?

Для других пользователей CoreOS, оставшихся без присмотра из-за этого вмешательства,
https://coreos.com/os/docs/latest/registry-authentication.html#using -a-registry-without-ssl-configure

@politician не мог бы сказать лучше. Совершенно определенно кажется, что докер просто игнорирует тот факт, что большая часть их пользователей, по крайней мере, недовольна.

Дело в том, что я нахожусь в процессе полной миграции с докера, и я очень доволен этим решением. В настоящее время я использую git и lxc, и они не только работают быстрее, чем docker, но и позволяют мне делать то, что лучше всего для моей компании, а не то, что думает другая компания, хотя и полностью и совершенно неправильно, лучше для меня.

Я настоятельно рекомендую взглянуть на альтернативы, которые честно лучше, чем докер, такие как rocket, raw lxc, qemu (не то же самое, но все же лучше), и это лишь некоторые из них.

Я настоятельно рекомендую этот курс действий всем, кого я знаю, кто с этого момента рассматривает контейнеры. По крайней мере, до тех пор, пока люди в Docker не поймут, что они понятия не имеют, и я подчеркиваю, что совершенно не понимают, что лучше для конечного пользователя с точки зрения безопасности.

Я сдался и купил дешевый выделенный сертификат SSL. Зависимость Docker CLI от системы CA слишком сильна - самозаверяющие сертификаты не просто сбивают с толку, они просто не работают.

• docker-machine удаляет ваше переопределение ca.crt между вниз / вверх
• ни одно из ваших базовых изображений не включает в себя инструменты создания сертификатов, такие как дрон для CI, невозможно
• docker CLI использует нестандартную папку для сертификатов, так что это еще кое-что, что нужно запомнить.
• даже если вы заставите его работать через 18 часов, у вас всегда будет неприятное ощущение, что что-то еще сломано

Итог: Docker постоянно накладывает штраф на вашу команду операций при попытке использовать самозаверяющий сертификат.

Это тем более досадно, что curl -k существует вечно.

+1

Довольно печально, что им на это наплевать. Если какой-то разработчик просто хочет возиться с докером и размещать свою собственную среду, обычно вы не хотите возиться с сертификатами SSL и прочим. Кроме того, если у вас дома есть собственный сервер, который далеко не публичный, вам просто не нужен SSL.

@buehler вы можете добавить опцию --insecure-registry в настройки вашего демона или в файл конфигурации

Просто новости от нас: с тех пор мы удалили реестр из нашей инфраструктуры и вернулись к использованию нашей собственной вилки dogestry с поддержкой хранилища BLOB-объектов Azure . Мы обнаружили, что реестр Docker дублирует слои, и нашим машинам не хватало места на диске, что приводило к сбоям в работе. Реестр оказался для нас тупиком, отнимающим много времени.

@buehler, чтобы конкретизировать предложение @thaJeztah , добавьте эту строку в конфигурацию:

--insecure-registry 0.0.0.0/0

Вы сможете получить доступ к любому реестру, который захотите. Хорошо работает для тестирования.

@politician дублирование происходит, если изображения размечены разными репозиториями. Отсутствие удаления капель - гораздо более серьезная проблема.

@thaJeztah, если это так просто сделать, но 80% (предположительно произвольное количество) пользователей должны это сделать, тогда, пожалуйста, просто сделайте это по умолчанию.

@justinclayton нет; установка этого параметра в основном означает «игнорировать любые проблемы с безопасным обменом данными с реестром», поэтому разрешить атаки типа «злоумышленник посередине» «из коробки», или даже демон, откатывающийся к не-TLS «http: //» . Docker _does_ уже установил его по умолчанию для реестров в диапазоне 127.x.x.x .

Если у вас есть локальный реестр и вы не хотите создавать для него сертификат, добавление --insecure-registry в параметры вашего демона займет меньше минуты. Однако это должно быть преднамеренное действие, а не то, что установлено по умолчанию.

@thaJeztah Я понимаю ваш аргумент, но это не может быть концом. Существует значительный пробел в пользовательском опыте для новых разработчиков из-за того, что он находится на стороне демона. Сценарий _majority_, в котором это неприятно, - это новый разработчик, который следует инструкциям на docker.com, чтобы загрузить и запустить установщик Docker Toolbox на своем Mac. По завершении они сразу же пытаются запустить docker pull <internally-signed-registry>/foo и получают сообщение об ошибке. Это настоящая проблема. Может быть, это означает, что номер следует переименовать?

Есть много других способов решить эту проблему; Я уверен, что сообщество и компания могли бы согласиться по одному из них:

• Текущее название этой проблемы - «--insecure-registry should be on docker pull». Поскольку этот вопрос все еще открыт, я предполагаю, что этот вариант все еще рассматривается.
• Если бы для этого было предоставлено (и задокументировано) решение с одной командой, которое было бы простым для начинающих пользователей, это решило бы эту проблему.
• В нашем случае реестр защищен. Он использует сертификат, подписанный нашим внутренним центром сертификации, как и все остальное в нашей среде сборки. Это достаточная безопасность. Если бы демон каким-то образом мог соблюдать хранилище сертификатов MacOS, это также избавило бы от этой головной боли.
• Если бы им было предложено добавить сертификат или выполнить эту конфигурацию на машине-докере во время процесса установки Toolbox, это, вероятно, тоже было бы нормально.

Пожалуйста, сообщите более чем 70 участникам этой проблемы, в каком направлении вы планируете двигаться, или просто закройте проблему, чтобы мы не остались в стороне. Спасибо.

@thaJeztah
Невозможно добавить один параметр --insecure-registry к параметрам демона без перезапуска всех запущенных контейнеров. Это одна из основных проблем. Мы не можем перезагрузить конфигурацию без перезапуска (проблема сохраняется с 2013 года), мы не можем извлекать образы из других небезопасных реестров без добавления опции для демона, а также перезапуска. И в настоящее время у нас все еще нет четкого плана решения этой проблемы.

@apakhomov предполагаю, что его можно добавить в список изменений конфигурации, которые можно обновить без перезапуска https://docs.docker.com/engine/reference/commandline/daemon/#configuration -reloading. Вы можете открыть для этого отдельный выпуск?

+1.

Некоторые провайдеры PaaS не предоставляют доступ к демону и запускают частную сеть для пользователя (например, Jelastic).

можно ли добавить в докер несколько небезопасных реестров?
что-то вроде --insecure-registry xxxx: xxxx --insecure-registry zzzz: zzzz

@kkorada --insecure-registry=0.0.0.0/0 заставит Docker вести себя как раньше.

@kkorada да, вы можете указать несколько реестров (флаг --insecure-registry=[] - квадратные скобки указывают, что его можно указывать несколько раз).

Также для docker 1.12 мы сделаем эту опцию настраиваемой в файле конфигурации daemon.json без перезапуска демона. См. Открытый запрос на вытягивание здесь: https://github.com/docker/docker/pull/22337

спасибо @mingfang и @thaJeztah

Как @mhamrah и @justinclayton предложил , я хотел бы также рекомендовать решение с помощью SSH в дополнение к TLS, подобно тому , как Git позволяет получить доступ к respository , используя как SSH и TLS. Это может использовать обходной путь ssh, указанный @justinclayton .

Хотя у меня нет данных, подтверждающих мое утверждение, я предполагаю, что частных реестров, работающих за брандмауэрами, гораздо больше, чем реестров в открытом Интернете. В этом случае ssh проще настроить и, если не более, безопаснее, чем TLS.

Кроме того, после нескольких дней борьбы с docker push и моим локальным частным реестром, работающим внутри внутренней, достаточно безопасной виртуальной машины (и больше времени на создание самозаверяющих сертификатов), я только что по-настоящему оценил rkt --insecure-options=image,tls,http .

Безумие, что это не настройка клиента. Очевидно, он не должен быть включен по умолчанию, потому что это будет способствовать небезопасной практике. Однако установка этого параметра для демона делает его очень непрактичным для целей отладки или в локальных средах разработки.

Мой текущий вариант использования: запуск среды разработки с помощью docker compose. Среде нужен локальный реестр докеров. Он предназначен для работы полностью на локальной виртуальной машине.

Способ докера: объяснение, как настроить докер-машину для включения небезопасного реестра на каждой машине разработчиков, возможно, требуя от них воссоздать свою докер-машину, если она у них уже есть, или отредактировать конфигурацию вручную.

Хакерское решение: запуск socat в каждом контейнере, который должен использовать реестр, перенаправление на localhost.

Не то чтобы облегчить задачу ...

+1

Очень жаль, что --insecure не является конфигурацией клиента!
Это также причиняет нам много боли, очень похоже на многие из приведенных выше объяснений.
Пожалуйста, установите --insecure-registry = 0.0.0.0 / 0 по умолчанию, чтобы предоставить способ передать его команде docker, а также конфигурации docker-compose.

+1

+1

Пришло время снова проводить ежегодную вечеринку +1 Pity Party?

13 декабря 2016 г. в 01:00 沙包 妖 梦[email protected] написал:

+1

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите обсуждение.

Если слои изображений подписаны, нет необходимости использовать CA PKI для обеспечения безопасности. Смотрите также, как работают apt / yum. Кроме того, использование SSL в локальной сети не имеет смысла, а в облачной среде это означает, что вы должны предоставить - помимо самих сертификатов - хороший источник случайности (см. Также: https://lukehinds.github.io/2015-03 -03-Энтропия-в-облаке /).

Короче говоря: если в этом нет необходимости, не навязывайте это пользователям.

Я только что открыл # 29736, что связано.

+1, если наличие клиентского флага --insecure-registry не является вариантом, должен быть способ указать доверенный сертификат, который будет использоваться для docker pull и docker push . Не у всех есть доступ к доверительным сертификатам на уровне ОС или доступ к демонам Docker для экспериментов.

Размещенные серверы CI (которые используются для создания образов докеров и отправки в частный реестр) являются отличным примером того, когда у вас может не быть такого уровня доступа.

+1

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

@tiborvass
Работает, только если у вас есть доступ к sudo ...

+1 хороший способ отговорить разработчиков от использования докеров

+1, я бы тоже хотел увидеть --insecure-registry для docker login .

Я даже не считаю это проблемой безопасности, поскольку вы делаете это сознательно. И если кто-то неавторизованный получил root-доступ, это тоже не обеспечит никакой безопасности. В чем собственное достоинство этого ограничения?

Если у вас были плохие намерения, вы могли просто загрузить свой вредоносный образ докера в DockerHub, которому доверяют.

+1 и, честно говоря, это непостижимо

+1 к поезду боли.

Плюс F * cking One!

Есть ли для этого PR?

Не AFAIK. Приведенные выше ссылки созданы потому, что часть моего собственного кода ссылается на эту проблему. Я открою эту ссылку на некоторое время, чтобы утихомирить спам здесь.

+1 тоже ...

+1

+1, очень неудобно добавлять настройку в deamon.json и перезапускать докер.

У разных машин разные ОС. Некоторые устанавливают докер из yum 、 apt-get , а некоторые напрямую используют двоичный файл. Так что я должен это обнаружить и правильно перезапустить dockerd .... это катастрофа

Я просто подчеркиваю, что docker pull нужен --insecure-registry flag!

Прошло всего три года - давайте не терять надежду сейчас

шишка 🤣

+1

+1

Аргумент о том, что это побуждает пользователей делать свои реестры безопасными, не только самонадеян, но и упускает из виду ключевой момент. Это ставит операции в положение, когда многие люди должны иметь доступ к учетной записи root, чтобы выполнять свои операции, где реестры докеров часто перемещаются.
Эта связь с точки зрения операционной безопасности создает больший риск безопасности.

Во-вторых, в частной сети (например, в многоуровневом приложении, размещенном в облаке), защита реестров не требуется и еще больше усложняет реализацию технологий, которые находятся наверху, требуя уровней управления безопасностью (для обработки автоматической проверки подлинности докеров / обновить) везде, где используется безопасный реестр докеров.

По крайней мере, демон докера должен быть настроен на РАЗРЕШЕНИЕ небезопасного параметра реестра для передачи. Это перемещает проект безопасности в нужное место - в руки администратора и за пределы самого докера.

FWIW Я был бы счастлив, если бы получил команду «добавить реестр в список небезопасных реестров», поскольку исправление конфигураций json из сценариев оболочки является серьезной проблемой.

+1

: +1: +1

+1

+1

+1

+1

Многие из запрошенных реализаций этого сделают невозможным для компаний, использующих Docker, соблюдать требования соответствия SOC и т. Д.

Для этого должно быть решение, но я не думаю, что есть простое решение, которое не будет более радикальным архитектурным изменением того, как изображения хранятся и выполняются.

Тем не менее, это должно произойти.

Я больше не занимаюсь разработкой Docker, поэтому я уберу себя из упоминаний. Удачи всем ^ _ ^

Требование SOC - хороший аргумент. В этом случае эта функция должна быть ВКЛЮЧЕНА с параметром конфигурации, который нужно добавить в общесистемную конфигурацию докера. Таким образом, требования SOC могут быть сохранены. Что-то вроде «ALLOW_INSECURE_REGISTY_OPTION», которое включает флаг --insecure-registry в командной строке докера.

Для соответствия SOC этот параметр не должен быть включен.

+1

Прошло всего три года - давайте не терять надежду сейчас

5.

Это предложение (в его нынешнем виде) вряд ли будет реализовано для различных
причины, среди которых;

• он держит человека, управляющего демоном докера, ответственным за то, какие соединения
  демону разрешено делать. обратите внимание, что эта опция может быть "живой перезагрузкой",
  поэтому демон не нужно перезапускать, чтобы изменить конфигурацию.
• каждая команда или путь кода, которые потенциально могут взаимодействовать с реестром, будут иметь
  быть измененным; не только docker pull , но и docker build , docker run ,
  docker plugin , docker service и docker stack подкоманды, а также
  оркестраторы, такие как swarmkit, которые извлекают изображения из рабочих узлов.
• Соответствие SOC (как указано выше)

По крайней мере, демон докера должен быть настроен на РАЗРЕШЕНИЕ небезопасных
параметр реестра, который необходимо передать. Это перемещает дизайн безопасности в правильный
место - в руках администратора, а вне самого докера.

Я думаю, что администратором в этом случае будет человек / команда, управляющая
хосты, на которых работает демон докеров, а не пользователь, который подключается к удаленному
API. Это причина того, что эта конфигурация является конфигурацией демона.

исправление конфигураций json из сценариев оболочки - серьезная проблема.

Это справедливый вопрос, но он ортогонален этому обсуждению. Это не _невозможно_
чтобы исправить конфигурацию JSON, но согласился, что это может быть сложнее, чем другие
форматы файлов. Обратите внимание, что эта конфигурация также может быть установлена ​​как сквозные флаги на
демон, который позволяет вам использовать файл модуля drop-in systemd для перенастройки
демон.

Что-то вроде «ALLOW_INSECURE_REGISTY_OPTION», которое включает флаг --insecure-registry в командной строке докера.

Если вы хотите разрешить небезопасное извлечение из любого реестра (что было бы эквивалентно
добавления флага --insecure-registry ), вы можете разрешить "Интернет" как небезопасный
реестр; следующее должно разрешить использование любого IPv4-адреса в качестве небезопасного реестра,
(таким образом, вернитесь к соединениям без TLS);

Через файл конфигурации /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"]}

Или передав параметры в виде флагов демону (который может быть установлен в systemd
переопределить файл);

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