Moby: --insecure-registry 应该在“docker pull”上

我们在所有 CI 和生产环境中运行内部不安全的 docker 注册表。 我必须说，简单地启用对所有不安全注册表的访问，而不必一一列出它们是非常有用的。 我们在每个环境中都有多个 HA 注册表。 这种变化使我们的事情变得更加复杂。 我将打开另一个问题单，专门解决这个问题，因为这个问题更多地是将选项移到 pull 而不是守护进程上。

当您不使用固定端口来运行注册表时，就会出现一些鸡和蛋的问题。

由于您事先不知道 docker 将分配哪个端口，因此您无法真正使用引用它的标志来启动演示。

：+1：

所以我想在docker pull命令行上支持--insecure ，强行禁用安全检查，显然对于 _this_ pull 命令，也会解决你的问题@proppy和@octalthorpe对吧？ 因为使用此标志运行不会检查任何列表

@abourget它也需要在远程 API 中得到支持。

目前 docker-py 在pull函数上公开了一个insecure_registry标志，但它仅用于解析端点： https :

罪魁祸首似乎是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 在咖啡馆的笔记本电脑上提取图像，则该 WiFi 接入点的另一个用户可能会运行攻击者提供的任意应用程序。 他们还可能获得访问您的 DockerHub 帐户或您将对其进行身份验证的其他注册表的权限。

编辑：添加 CVE 描述链接： https :

是的，我说这不是 RCE 是错误的。 这是一个糟糕的错误，并且很好地证明了为什么强大的图像签名是一个好主意。 然而，利用并不是微不足道的：它需要一个积极的攻击者在星巴克闲逛，希望附近的人会通过不安全的 WiFi 使用 Docker。 这不会在一夜之间被武器化——因此不值得在没有警告的情况下进行向后不兼容的更改。

如上所述，有明显的方法可以在不破坏兼容性的情况下立即提高安全性。 例如，为 index.docker.io 和少数其他流行的公共注册表禁用 HTTPS 回退可以有效地解决大多数用户的问题。 向控制台输出添加 HTTP 回退正在发生的警告会减轻交互情况。 HTTP 回退将被标记为已弃用并在下个月的版本中删除。 最后，localhost 和 ::1 显然不容易受到攻击。

同样，我不应该低估漏洞的程度，但我担心响应过程和修复没有为不破坏客户提供足够的价值。

我们当前在没有 FQDN 可用于许多这些实例的环境中动态创建/销毁 docker 注册表。 支持注册表相关请求的 --insecure-repository 选项（通过远程 API）将消除此安全修复为我们带来的严重并发症。

我们在 Docker 1.3.1 中也有类似的问题。 我们在地址http://docker :5000/ 上使用本地（私有）Docker 注册表。 在 Docker 1.3.0 之前，它工作得很好。 对于 Docker 1.3.1 版，它不再起作用，因为 Docker 客户端会自动假定 Registry 可通过 HTTPS 访问。 但是我们根本不使用HTTPS。

如果无法通过 HTTPS 访问 Docker Registry 服务器，那么实现使用 HTTP 的回退机制会很好。

@kruxik如果您在启动守护程序时使用--insecure-registry docker:5000 ，它将回退到HTTP。

@tiborvass谢谢你的建议。 你是对的。 但是，如果您有很多开发人员使用他们的工作站和笔记本，那么在每个工作站上设置--insecure-registry是不切实际的。 至少让它作为拉/推操作的可选参数对我们来说就足够了;)

+1

这对我们 1.3.0 有效，但对于 1.3.1

码头工人版本
....
服务器版本：1.3.1
....
码头工人推 10.121.4.236:5000/debian7/consul
-> ....如果这个私有注册只支持 HTTP 或 HTTPS 和未知的 CA 证书，请添加--insecure-registry 10.121.4.236:5000到守护进程的参数。 在HTTPS的情况下，如果你可以访问registry的CA证书，就不需要flag； 只需将 CA 证书放在

降级
服务器版本：1.3.0
码头工人推 10.121.4.236:5000/debian7/consul
-> 容器上传没有问题。

对于 1.3.0 到 1.3.1 有问题的其他人，我必须使用 boot2docker 对 OS X 进行以下更改：

$ 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

那么你_应该_能够做一个docker pull。

如果使用 fig，您还需要 Fig 1.0.1 并执行以下操作：

$ fig up --allow-insecure-ssl

@mhamrah谢谢！ 花了几个小时试图解决这个问题......

+1 假设 localhost 是安全的。 真的有人反对吗？

是的，假设 localhost 是安全的会很有帮助。 我将 vagrant 用于我的 docker 盒子，所以每次我销毁或打开一个盒子时更新 init 脚本都是低效的。 我想我现在必须将我的 docker box 人偶化，以便我可以修改 vagrant 上的 init。

在 pull 和 push 上也使用 --insecure 标志会很好，所以我可以在需要时使用 vagrant box IP。

@thocking ：假设 localhost 是安全的：请参阅https://github.com/docker/docker/issues/8898

老实说，我也想知道为什么我的自动化 Jenkins Containerbuilds 未能推动......
（很高兴有一个 testenv。在将其投入生产之前）。
我必须检查这个“功能”是否真的被宣布 - 如果不是，我会对守护进程行为的如此极端的巨大变化更加偏执。

我在这次讨论中想念的是：
为什么我什至必须告诉守护程序为每个主机使用“默认”安全/不安全模式？

使用这种默认行为设置注册表不应该更有效率吗？
因此，如果没有 --secure 或 --insecure 参数给出守护程序应请求，则取决于设置
如果安全方式是可能的，如果不是，则使用了不安全的后备。

docker 的主要特点之一是它非常易于使用和设置完整的环境。 请不要用这样的“发布/决定”来扼杀这个WOW效果......

只是我的 2 美分...

这里的问题与上述问题类似，包括@jwthomp。 我花了 10 多个小时试图解决这个问题，同时已经降级到 docker 1.3.0。

我正在 Marathon 和 docker registry 下运行 docker 注册表，目前“通过将 nginx 作为前端运行来支持 SSL”（请参阅​​ https://github.com/docker/docker-registry/issues/697 ）但使用 nginx 作为前端是由于 Marathon 在各种从属主机/端口上运行 docker 注册表而变得复杂。

我可以直接在注册表中启用 SSL（使用 GUNICORN_OPTS），但是它 _only_ 说 SSL 并且无法通过 Marathon 健康检查。

我已经修改了 Bamboo HAProxy 配置系统，以将 HAProxy 配置为所有服务的 https 前端，就像 nginx 那样，但是我仍然在 docker 验证我的私有注册表上的证书时遇到问题，所以这仍然是行不通的此时的我。

可以很好地防止 RCE，但还需要一些向后兼容性。 至少有一个 docker 守护进程的标志，用于将所有注册表指定为不安全。 应该有一种方法可以在每个 docker pull 命令中指定 http 或 https 作为注册表名称的一部分。 目前，对于使用私有注册表的任何人来说，1.3.1 似乎是一个很大的 Catch-22。

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

好的。
2014 年 11 月 14 日星期五上午 10:42 Ilya Radchenko [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 中添加了所需的行并重新启动了 docker。 谢谢你的提示！

凉爽的。 我什至连 ssh 都遇到了麻烦，我想是因为某个版本
docker iso 之间的不匹配。 我实际上改用了 vagrant +
coreos 用于 docker 支持，它运行良好。 你只需要设置
DOCKER_HOST，boot2docker 自动执行。

2014 年 11 月 20 日星期四上午 1:52:21 Kayvan Sylvan通知@github.com
写道：

@mhamrah https://github.com/mhamrah我不必删除
ssh 密钥等。我刚刚添加了所需的行
/var/lib/boot2docker/profile 并重新启动 docker。 谢谢你的提示！

—
直接回复此邮件或在 GitHub 上查看
https://github.com/docker/docker/issues/8887#issuecomment -63768043。

对不起各位，我本来想早点回复的。

就像@ewindisch已经说过的那样，我们不想鼓励这种客户端行为。 要求该标志作为守护进程标志所引起的痛苦是人们实际上在他们的注册表上设置了 TLS。 否则没有动力。 感谢您的理解。

官方 docker 注册表上有 docker 注册表的“官方”基于 docker 的镜像。 建议在没有TLS 的

如果 Docker 希望用户在他们的注册表上设置 TLS，那么通过提供默认提供 TLS 的官方 Docker 映像来平衡“引起的痛苦”与相等和相反的“减轻痛苦”

@tiborvass 。 您忽略了内部防火墙开发案例。 所以现在我要么必须在我的注册表前设置一个启用了 SSL 的反向代理（根本没有理由这样做），要么我必须去找我的每一位开发人员并修改运行守护程序的参数在 boot2docker 里面。 这没有任何意义。 有许多开发环境提供可配置的安全性，其中开发环境的安全性通常被禁用。 我很惊讶地看到你关闭了这个问题，因为有这么多票支持解决方案。

将所有私有 ip 列入白名单怎么样？ 中间地带？

或者将协议名称、“http”或“https”作为拉取图像名称的一部分。

@tiborvass @sroebuck和@blevine 都提出了很好的观点。 这将越来越成为商店在内部构建容器的场景，并且对打破以前工作流程的愤怒也会增加。 我们都理解安全方面的问题，也许 pull 不是解决它的正确地方，但只要官方注册镜像没有提供简单的、开箱即用的方式来处理这种变化，它应该被认为是一个需要解决的非常重要的用户体验问题。

嘿@tiborvass ！ 这个问题现在也困扰着我们。 我更喜欢@nickandrew的方法。 会更像 git clone 并且还开辟了未来不同的可插拔协议的可能性。 Docker 的胜利，因为它会减少耦合并为社区带来胜利。

@blevine请注意，从 1.3.2 localhost ，默认情况下已将其列入白名单，请参阅： https :

您可以通过传递： -p 127.0.0.0:5000:5000到docker run使注册表在本地主机上侦听

@proppy ，我不太确定在 localhost 上收听对我有什么帮助。

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

或者它应该成为一个实际的 URL？ 我对注册表协议一无所知，但扩展当前语法以指定正确的 URL 似乎并不不兼容。

@blevine这意味着您可以设置本地镜像注册表。

Arg，现在我必须对 coreos 的云配置进行 base64 解码才能让我的机器启动

@tiborvass哇，这真的很不幸。 :(

我们有开发集群，我们可以随时启动和关闭这些集群，我们处理这些集群的部分方法是为该集群创建一个注册表。 集群可以是许多物理节点或虚拟机，也可以位于开发人员的台式机或笔记本电脑上（尽管我们通常无法启动完整的堆栈）。 每个集群都是一个完全独立的堆栈和开发环境。 我们还有基于 docker 的命令行工具，允许开发人员与公司中的任何开发集群设置进行交互。

在这种复杂且动态的环境中，在注册表上设置 TLS 是一项巨大的痛苦。 每次设置时都必须修改 docker daemon 启动，我们添加一个新的网络，注册表可以在上面同样痛苦。

不要误会我的意思，我很欣赏想要专门支持 TLS 的想法，但是我鼓励您考虑在一些有效的情况下，环境安全地支持移除 TLS 的复杂性以减少支持所需的痛苦和基础设施它。

@tiborvass +1。 +1000。 这产生了绝对不必要的复杂性
我们进入高度动态的开发工作流程。 进入壁垒已经
在这里显着提高只需要申请的东西
生产环境。 请结束我们的痛苦。

2014 年 12 月 9 日，星期二，Jeff Thompson通知@github.com
写道：

@tiborvass https://github.com/tiborvass哇，这是其中之一
可悲的虚拟表翻转时刻。 :(

我们有开发集群，我们可以随时上下移动和部分
我们如何处理这些集群是我们为该集群创建一个注册表。 一种
集群可以是许多物理节点或虚拟机，也可以在一个
开发人员台式机或笔记本电脑（尽管我们通常无法启动
全栈）。 每个集群都是一个完全独立的堆栈和开发
环境。 我们还有基于 docker 的命令行工具，允许
开发人员与公司中的任何开发集群设置进行交互。

在这种复杂和动态的环境中，在注册表上制作 TLS
一个要求是巨大的痛苦。 必须修改 docker daemon 启动
每次我们设置时，我们都会添加一个注册表可能位于的新网络
同样痛苦。

不要误会我的意思，我很欣赏想要支持背后的想法
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。

通过指定诸如“--insecure-registry 172.16.0.0/12”之类的范围，可以更精细地使用此 CIDR 符号来启用“防火墙后”配置。 我根本不建议使用此选项，但我建议用户选择此选项以使用更具选择性的范围（例如他们的 IP 空间），而不是尽可能使用 0.0.0.0/8 的所有地址。

docker 守护进程内置在 coreos 中，所以我必须以某种方式将这些标志添加到整个集群的启动中。 我认为对于无法控制 docker 守护程序本身的环境，将它放在 pull 命令上会灵活得多。

这相当于告诉我们为共享的 php 主机更改 php.ini 文件。

在2014年12月9日，在22:18，蒂博尔Vass的[email protected]写道：

@justinclayton @jwthomp @mattwilliamson @nickandrew @blevine

--insecure-registry 0.0.0.0/8 不能解决您的问题吗？ 这样你仍然可以使用 HTTP。

—
直接回复此邮件或在 GitHub 上查看。

@mattwilliamson执行标志可通过

CoreOS 网站上提供了更改 Docker 配置的示例。 人们可以轻松修改指令以添加调试标志以指定不安全的注册表标志。

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

@tiborvass整个配置生态系统需要支持这一点，才能轻松开箱即用。 当人们进入设置自己的内部注册表的步骤时，他们不希望在他们可能拉动的任何地方（boot2docker、coreos、任何安装有 Chef/puppet 模块的东西等）对守护程序启动进行非标准的定制。 使用自述文件中标记为“推荐”的步骤时，官方注册表容器映像本身_不再有效_。 事实上，自述文件根本没有提到 TLS，并且设置它是一个非常重要的过程。 此外，正如@mattwilliamson上面简要提到的那样，在共享构建环境等无数情况下，使用守护程序拉取映像的人与配置守护程序的人不同。

最重要的是，将其作为客户端的论点显然是破坏性较小的解决方案，更重要的是，规范性较低的解决方案。 Docker 已经成为数十个甚至数百个其他项目和工作流程的原始版本，因此实际上不应该在这个范围内规定使用模式。 仅仅因为 Git 提供了一个简单的运行时配置选项来禁用 http.sslverify 并不意味着 Linus Torvalds 鼓励人们在重要的上下文中不保护他们的敏感数据。

git 类比是一个很好的例子，说明它应该如何工作。 Git 不会强迫你使用 TLS，它是用户在设置主机时他们想要支持什么级别的决定。 这也是用户在拉取他们需要（或想要绕过）的安全级别时的决定。 配置是一个简单的步骤，无论是全局还是每个 repo。 尽管 Docker 没有强迫我们使用 TLS，但通过使替代方案变得重要，它没有提供其他合理的选择。

CIDR 表示法允许使用可以说是“重锤”的方法，而 AFAIK 不会映射到 dns 名称，因此即使我屏蔽了 10.0.0.0/16，也不会将 some.private-registry.com 拉入 10.0/16 中工作。 更重要的是，配置不是微不足道的。

Docker 因其容器化的简单性而蓬勃发展，并大大降低了在各种环境中部署应用程序的障碍。 我们都知道好处。 大多数开发人员无法回答简单的 CIDR 符号问题，docker 配置文件可能位于非标准位置（boot2docker 和 CoreOS 位置都与其他发行版不同），并且很容易将这些配置文件与困难的反馈循环搞混成功。 我必须跟踪系统日志？ 哦，等等，我在 RHEL 上，这是消息吗？

新开发人员可以轻松地复制和粘贴docker pull代码段，但让他们通过 ssh 进入 boot2docker 主机，运行 vi，编辑配置文件，然后跟踪系统日志以查找错误......不是那么多。 哦，是的，您忘记重新启动 docker 守护进程。

这是我想看到的：

• 通过 docker 命令应用的 Docker 守护进程设置
• 用于 TLS 覆盖的 Docker 拉取设置，通过 docker 命令指定
• 跨特定注册表的命令保留的 Docker 拉取设置

是的，但亚马逊不允许您更改 autoscscale 配置。 我将不得不复制它或制作一个全新的。

在2014年12月9日，在23:55，埃里克WINDISCH [email protected]写道：

CoreOS 可以配置执行标志。 您可以编辑 Docker 的 systemd 配置文件。 要为集群配置此功能，您可以使用 cloud-config。

CoreOS 网站上提供了更改 Docker 配置的示例。 人们可以轻松修改指令以添加调试标志以指定不安全的注册表标志。

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 多人公司内部对 docker 的采用停滞不前。 在一切都受控的内部开发环境中，我们绝对没有使用 TLS。 我们赞赏它用于公共集线器存储库，并认为在所有情况下都将其用于其他地方是一个巨大的错误。

@CleanCut说得很好。 真的很失望 1.4.0 来来去去，这个问题仍然存在。

@CleanCut很棒 - 我想要在 boot2docker 中添加更多信息到boot2docker init初始有效负载，然后它会为您执行此操作。

不能解决非基于 vm-boot2docker 的特定问题，但--insecure-registry并不是 b2d 用户想要的唯一站点特定定制。

你能在 boo2docker repo 中为此提出一个拉取请求或问题吗？

确实提高了某人使用因降低障碍而受到称赞的项目的障碍。

在2014年12月13日，在02:10，贾斯汀·克莱顿[email protected]写道：

@CleanCut说得很好。 真的很失望 1.4.0 来来去去，这个问题仍然存在。

—
直接回复此邮件或在 GitHub 上查看。

@SvenDowideit当然。 这里是

听起来在这个线程中有一个共识，即这不是一个已解决的问题； 我们可以重新打开这个问题吗？

是的，请！
Le 2014-12-15 15:05, "Justin Clayton" [email protected] a écrit :

听起来在这个线程中有一个共识，这不是一个解决方案
问题; 我们可以重新打开这个问题吗？

—
直接回复此邮件或在 GitHub 上查看
https://github.com/docker/docker/issues/8887#issuecomment -67055878。

+1。 我没有什么要补充的，只是想简单地发泄一下我对这个决定的不满。 像其他人一样，我在本地网络上运行一个注册表，在其他地方处理安全问题。 我有几十个正在运行的 docker 容器，现在需要将它们退回以添加“有据可查”的标志。

@bfirsh - 这是 Docker 守护程序配置文件和kill -HUP <dockerdaemonpid>很棒的示例之一 - 触发它重新读取 cfg，而无需重新启动它 - 从而避免容器重启

@SvenDowideit +1 重载功能，通过简单的配置重启服务器真的很烦人。

+1

如果我没有正确理解事情，请原谅我，但这个问题似乎是我自己场景的根源（类似于@blevine概述的

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

+1 重新开始此讨论，因为社区似乎对当前的解决方案并不满意。

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

只是试图从各个角度解决这个问题，直到我们听到关于这个主题的明确答案。

+1，目前很难配置和工作。

@mhamrah提出了很好的观点。 不要强求，让用户根据自己的需求来决定和配置。

使用自签名证书的注册表也是一个问题，尤其是
在使用 boot2docker 的开发人员上下文中切换到只读文件
系统。 这需要一个额外的和不同的配置步骤来
引导正在运行的虚拟机。

我相信每个发帖到这个线程的人都看到了它的价值和好处
的 docker，每天都在使用它，并试图在他们的
组织，但正在经历一个痛苦和不必要的问题
阻碍采用。

尽管我们都知道 docker，但许多技术人员仍然不知道——
尤其是在企业内部。 文档有帮助，但我们仍然
跳过篮筐，这是一个很大的阻碍，总体上是负面的
影响。
在Sun，2015年1月25日在下午五点54分周杰伦泰勒[email protected]写道：

+1，目前很难配置和工作。

@mhamrah https://github.com/mhamrah提出了很好的观点。 不要强迫
事情，让用户根据自己的需要决定和配置。

—
直接回复此邮件或在 GitHub 上查看
https://github.com/docker/docker/issues/8887#issuecomment -71398193。

+1 适合快速尝试事物

：+1：

：+1：

非常令人失望的是，我们仍然无法在不将标志传递给 docker 守护程序的情况下从不安全的注册表中提取。 这只是我们部署的每台新机器的另一个麻烦。

+1

一些想法：

1. 我们可以有主机名通配符吗？ 例如--insecure-registry=*.internal
2. 自签名证书可以与 http 区别对待吗？
3. 与 2 相关，docker 是否可以执行类似于 SSH 的操作，并在用户看到新证书时提示用户接受自签名证书/如果存在不匹配的证书，请大声抱怨？

当我提出建议时，为什么不把 localhost 视为总是安全的呢？ （就像 Chrome 一样）

编辑：啊，我看到它已经是了。

+1000 对此.. 和 +1 配置重新加载功能，这就是使这变得更糟的原因。 我坚持使用 v1.2，因为我认为维护者肯定会意识到守护进程上的 --insecure-registry 标志用于部署和修复它是多么烦人，但不知何故次要版本一直忽略它。

例如，如果我出于某种原因不得不更改我的私有注册表 IP，我将不得不重新启动每个 VM 上的每个 docker 守护程序——仅仅因为我的注册表更改了！？ 这两件事永远不应该结合得那么紧密。 并且告诉人们只添加 0.0.0.0/8 一开始就违背了安全实现的全部目的。

将此标志添加到推/拉命令似乎很明显是守护进程标志的后备，请有人向我解释为什么他们仍在与它作斗争，但同时添加了“很高兴拥有”的功能。

@agquick的评论是正确的，尤其是“很高兴拥有”功能。

意识到这对大量用户来说是一个持续的痛苦，我们正在重新考虑将--insecure到pull 。 @ewindisch和我将致力于一个 PR，我们将链接到这个问题。

抱歉让您久等，并感谢您发表意见并指出您的痛点。

@tiborvass我可以想象有同样多的用户_不_希望允许从不安全的注册表中提取。 我意识到 Docker 目前没有对权限/配置的细粒度控制，但是如果有机会能够“锁定”它，我认为这将是一个不错的选择。

哦，我做到了！ 正要自己实现它。

从我的 BlackBerry 10 智能手机在 Bell 网络上发送。
来自：塞巴斯蒂安·范·斯蒂恩
发送：2015 年 2 月 23 日星期一下午 4:53
至：码头工人/码头工人
回复：码头工人/码头工人
抄送：克里斯托弗·西普拉克
主题：回复：[docker] --insecure-registry 应该在“docker pull”上（#8887）

@tibor vasshttps://github.com/tiborvass我可以想象有同样多的用户不想允许从不安全的注册表中提取。 我意识到 Docker 目前没有对权限/配置的细粒度控制，但是如果有机会能够“锁定”它，我认为这将是一个不错的选择。

—
直接回复本邮件或在 Gi tHub上查看

@thaJeztah我想弄清楚你在想什么用例，这意味着我们不能有--insecure-registry标志到docker pull 。

• 如果用户不想在安全注册表上意外被中间人攻击，他们可以避免传递--insecure-registry
• 如果用户想要强制用户所有图像都来自安全注册表（即“企业”场景），他们目前实际上根本无法强制执行此操作！

那么你能详细说明docker pull --insecure-registry禁止什么吗？

为了详细说明我的第二点，如果不重新思考 docker 的大量工作原理，我不知道您如何锁定它！ 除了能够docker load可以通过编写自己的注册表提取程序获得的 tarball，并使用docker run -v升级 privs 并向守护程序参数添加一些内容之外，还有一种非常简单的方法可以绕过任何“执法”：

$ 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 的大量工作原理，我看不出你会如何锁定它

我完全理解（此时）没有办法锁定它。 有权访问docker.sock具有有效的 root 访问权限，因此可以更改他们喜欢的任何内容。 此外，他们仍然可以更改守护程序标志并重新启动守护程序。

但是，如果docker pull --insecure-registry ..给出错误（“不安全的注册表被禁用”），它_确实_会向用户发出明确的信号，这_会_通知用户这是不需要的，例如，在尝试他们发现的一些示例时某处。

那么，它会涵盖所有情况吗？ 不。会不会_伤害_，我也不这么认为。

我个人认为它弊大于利，仅仅是因为它误导人们认为“哦，看，docker 强制执行此操作”，而实际上它只是一种非常肤浅的保护。 我可以继续，但最终我认为这归结为品味问题。

如果您正在寻找它可能会受到的伤害，只需向上滚动即可。 这种方法存在无数的 UX 问题，这些问题对采用造成了障碍，上面详细介绍了这些问题。

我查看的问题主要是 docker 无法在不杀死 sub 的情况下重新启动
容器。 这使得配置/重新配置变得更加困难。

2015 年 4 月 15 日星期三晚上 8:11，Jan Krueger通知@github.com
写道：

+1

—
直接回复此邮件或在 GitHub 上查看
https://github.com/docker/docker/issues/8887#issuecomment -93362359。

我很失望还没有对这个问题采取一些行动。 这显然引起了许多人的痛苦。

这显然让很多人感到恼火，它现在正在积极地阻止我的工作。 根据您所处的情况，必须重新启动 Docker 守护进程以允许从不安全的注册表中提取从烦人到完全不可能的范围。

不这样做的主要论点似乎是系统管理员应该能够锁定系统并确保只能拉取来自安全存储库的图像。 这个用例绝对是真实的，但我认为它是一个糟糕的默认值。 这似乎是一个很多更合理的做法是可以传递给守护像开始的标志--no-insecure它禁用--insecure-registry在使用pull 。 这样，管理员可以在他/她真的想要锁定的情况下将其锁定。

对于那些非常渴望这种行为的人，我确实提供了以下解决方法。 我知道它对所有用户都不可行，因为它不使用 Docker API 进行拉取。 也是有点慢...

查看我的项目“docker-pull”： https :

你会这样使用它：

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

这些都是很棒的解决方法！

我也希望看到默认的反转。

2015 年 4 月 15 日下午 6:14，Joe Doliner通知@github.com 写道：

我很失望还没有对这个问题采取一些行动。 这显然引起了许多人的痛苦。

这显然让很多人感到恼火，它现在正在积极地阻止我的工作。 根据您所处的情况，必须重新启动 Docker 守护进程以允许从不安全的注册表中提取从烦人到完全不可能的范围。

不这样做的主要论点似乎是系统管理员应该能够锁定系统并确保只能拉取来自安全存储库的图像。 这个用例绝对是真实的，但我认为它是一个糟糕的默认值。 拥有一个可以在启动时传递给守护程序的标志似乎更合理，例如 --no-insecure 禁用 --insecure-registry 在 pull 中的使用。 这样，管理员可以在他/她真的想要锁定的情况下将其锁定。

—
直接回复此邮件或在 GitHub 上查看。

所以这是重新打开的，4 个月后的当前状态什么都不是，作为一种解决方法，使用一堆黑客？ :-/ 其他地方是否有一些关于这个的讨论，或者它只是死了？

是的，+1

+1

+1

我想指出的是，我统计了这个页面上“+1”的实例，到目前为止计数到了31。 这还不包括实际上不包含该确切字符串的其他支持性评论。

这里的问题是在拉取时启用--insecure会将控制权从它所属的系统管理员手中夺走。
安全性很难，做出改变以放松安全性不是一个小决定。
此外，对当前设置非常满意的人也不会来这里和-1 。
另一方面...
重新配置守护进程以启用从注册表中不安全的拉取是微不足道的。
设置一些自签名证书也很简单，甚至不必重新配置 docker。

“系统管理员”是 docker 的一个用例，但我的“开发人员”和“非系统管理员”是同样有效的用例。 对于开发人员，提供--insecure选项可以减少工作流程中的摩擦。

也许我们可以通过提供一个选项来让系统管理员可以指定_拒绝_使用--insecure选项，从而实现两全​​其美。 这样，系统管理员仍然可以完全控制，但非系统管理员案例不必处理工作流程的痛苦。

对于系统管理员来说微不足道的事情对于非系统管理员来说可能会令人惊讶地繁琐。 我不得不帮助近 20 名开发人员在我们的开发小组中使用的 5 个不同操作系统上进行（和重新制作）这种配置更改。 我实际上维护了一个脚本来自动更改我们环境的配置。

我们的系统管理员目前不会为我们的注册表设置自签名证书，无论它是否微不足道。

无论如何，即使这种情况没有改变，最终人们也会适应它们。 我想下次我们的系统管理员对注册表进行维护时，我正在处理的痛苦都会消失，因为那时我们应该能够安装实际的 SSL 证书。 也许这就是重点。 使走安全路径​​比走不安全路径更容易。

:+1: @CleanCut ，其他人都说了。 我只处理开发人员案例，重新配置 docker 守护进程对我们来说只是浪费时间。

如果您今天可以访问 docker 套接字，那么您_是_系统管理员。 你是
root 已经，你有“docker load”并且已经有了解决方法
不安全的注册表拉取。 将图像选项添加到客户端不会
比现状更不安全。

然而，关于有意增加
开发人员试图在其他方面做错误的事情以吸引他们的摩擦
他们做正确的事。
2015 年 6 月 18 日下午 12:41，“Brian Goff”通知@ github.com 写道：

这里的问题是启用 --insecure on pull 会夺走控制权
来自它所属的系统管理员。
安全难，做些改变放松安全不小
决定。
此外，对当前设置非常满意的人不会去
来这里和-1 this 要么。
另一方面...
重新配置守护进程以启用不安全的拉取
注册表。
设置一些自签名证书也很简单，甚至不必
重新配置泊坞窗。

—
直接回复此邮件或在 GitHub 上查看
https://github.com/docker/docker/issues/8887#issuecomment -113213172。

@ewindisch @tiborvass回读，我看到https://github.com/docker/docker/issues/8887#issuecomment -75638745;

意识到这对大量用户来说是一个持续的痛苦，我们正在重新考虑添加 --insecure 来拉取。 @ewindisch和我将致力于一个 PR，我们将链接到这个问题。
抱歉让您久等，并感谢您发表意见并指出您的痛点。

那还是现在的位置吗？ （我认为没有创建 PR）

+1

这每天都继续困扰着我。

:( 悲伤的锥头。

--inscure 从开发人员 POV 来看完全有意义。 它取决于在他们的环境中实施 docker 以确保其安全的人。

+1

：+1：

_用户投票_

_在此讨论中有更改时获得通知的最佳方式是单击右上角的订阅按钮。_

下面列出的人通过随机 +1 对您有意义的讨论表示赞赏：

@justinclayton
@anandkumarpatel
@tangr1
@fred4jupiter
@明芳
@djannot
@Frusty
@tobegit3hub
@testaccountspivey
@mhamrah
@mwhooker
@ryan-无状态
@乔纳森沃恩
@gollawil
@ebartz
@maelp

+1

+1

+1

我们在封闭网络中使用内部注册表，添加这将使我们更容易部署。

+1

如果这个问题在万圣节前仍然开放，我认为所有 +1 的人都应该举办一年淹没在我们的码头悲伤中的周年派对。

+1为悲伤派对！

2015 年 9 月 14 日下午 1:32，戈登通知@github.com 写道：

用户投票

在此讨论中有更改时获得通知的最佳方式是单击右上角的订阅按钮。

下面列出的人通过随机 +1 对您有意义的讨论表示赞赏：

@justinclayton
@anandkumarpatel
@tangr1
@fred4jupiter
@明芳
@djannot
@Frusty
@tobegit3hub
@testaccountspivey
@mhamrah
@mwhooker
@ryan-无状态
@乔纳森沃恩
@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那太棒了。 感谢您简洁地展示了当前限制的无效性。

Docker，请重新包括这个特殊的电池。

+1

我不得不说，对用户的强力鼓励已经严重影响了我使用 docker 的想法。 我完全理解我们可以在启动时将 --insecure-registry 标志添加到守护程序，并且我不会深入探讨所有无法始终工作或不可能的原因。

我有一个问题要问 Docker 开发人员，你们真的认为自己知道什么对最终用户是最好的吗？ 我的注册表根本不需要 SSL，因为它们运行的​​网络已经完全加密。 那么到底为什么我要加密加密流量，除了增加开销和移动部分到已经复杂而庞大的系统之外，这真的有什么作用吗？

是否真的存在人们通过互联网使用私有注册表的用例？ 从这个意义上说，人们对身份验证做了什么？ 难道不能将图像拉下来然后将其撕开吗？ 而不是试图在前往另一台计算机的途中拦截它？

TL;博士+1

+1

@Supernomad说得好。

从 docker 的角度来看：这是一个最好不要正式实施的问题，但有很多可能的解决方法来减轻痛苦。 一些用户大声尖叫仍然没有竞争对手将 docker 标记为“故意不安全”的痛苦，并永远损害其声誉。
话虽如此，+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

为什么我应该用我的 SSL 私钥信任 Docker Registry？

对于其他因这种干预而被遗弃的 CoreOS 用户，
https://coreos.com/os/docs/latest/registry-authentication.html#using -a-registry-without-ssl-configured

@politician我自己说得再好不过了。 可以肯定的是，docker 似乎只是忽略了一个事实，即他们的大部分用户至少不满意。

事实是我正在完全从 docker 迁移，我对这个决定感到非常高兴。 我目前正在使用 git 和 lxc，它不仅比 docker 更快，而且实际上允许我做对我的公司最好的事情，而不是其他公司认为的，尽管完全和完全不正确，但对我来说是最好的。

我强烈建议看一下确实比 docker 更好的替代方案，例如 Rocket、raw lxc、qemu（不一样但仍然更好），仅举几例。

从现在开始，我将向所有我认识的正在考虑使用容器的人强烈建议这一行动方案。 至少直到 docker 的人意识到他们不知道，我强调_绝对_不知道，在安全方面什么对最终用户最好。

我放弃了，买了一个便宜的专用 SSL 证书。 Docker CLI 对 CA 系统的依赖性太强了——自签名证书不仅在操作上令人沮丧，而且根本不起作用。

• docker-machine 在 down/up 之间删除你的 ca.crt 覆盖
• 你的基本图像都不包括像无人机这样的证书制作工具，不可能
• docker CLI 使用一个非标准的证书文件夹，所以这只是要记住的其他事情。
• 即使你在 18 小时后让它工作，你总会有一种唠叨的感觉，那就是别的东西坏了

底线：当尝试使用自签名证书时，Docker 会对您的运维团队造成持续的持续惩罚。

这更令人沮丧，因为curl -k已经存在了永恒。

+1

很遗憾，他们对此毫不在乎。 如果某些开发人员只想摆弄 docker 并托管他自己的环境，通常您不想弄乱 SSL 证书和其他东西。 此外，如果您在家中拥有自己的服务器，而且离公共场所很远，那么您根本不需要 SSL。

@buehler您可以将--insecure-registry选项添加到守护程序的设置或daemon.json配置文件中； 那么你只需要配置一次，拉取无需指定flag

只是我们的更新：我们已经从我们的基础设施中剥离了 Registry，并恢复使用我们自定义的 Dogestry 分支和 Azure Blob 存储支持。 我们发现 Docker Registry 正在复制层，我们的机器磁盘空间不足，导致中断。 注册表对我们来说是一个浪费时间的死胡同。

@buehler只是为了具体化@thaJeztah的提议，将此行添加到配置中：

--insecure-registry 0.0.0.0/0

您将能够访问您想要的任何注册表。 非常适合测试东西。

@politician如果图像被标记为不同的存储库，则会发生重复。 不删除 blob 是一个更大的问题。

@thaJeztah如果这很容易做到，但 80%（不可否认，任意数量）的用户需要这样做，那么请将其设为默认值。

@justinclayton不； 设置该选项基本上是说“忽略与注册表的安全通信的任何问题”，因此允许“开箱即用”的中间人攻击，甚至守护进程回退到非 TLS“http://” . Docker _does_ 已经将它设置为127.x.x.x范围内注册表的默认

如果您有一个本地注册表并且不想为其生成证书，那么在您的守护程序选项中添加--insecure-registry只需不到一分钟的时间。 不过，这应该是一个深思熟虑的动作，而不是默认设置的内容。

@thaJeztah我理解你的论点，但这不能只是结束。 由于这是在守护进程方面，新开发人员的用户体验存在显着差距。 _majority_ 场景是一个痛苦的新开发人员，他们按照 docker.com 上的说明在他们的 Mac 上下载并运行 Docker Toolbox 安装程序。 完成后，他们立即尝试运行docker pull <internally-signed-registry>/foo并遇到错误。 这是真正的问题。 也许这意味着这个问题应该重命名？

还有很多其他方法可以解决这个问题； 我相信社区和公司可以就其中之一达成一致：

• 这个问题的当前名称是“--insecure-registry 应该在“docker pull”上”。 由于这个问题仍然存在，我不得不假设这个选项仍在考虑中。
• 如果提供（并记录）对新手用户来说很简单的单命令解决方案，那将解决这个问题。
• 在我们的例子中，注册表 _is_ 是安全的。 它使用由我们内部 CA 签署的证书，就像我们构建环境中的其他所有内容一样。 这是足够的安全性。 如果守护进程以某种方式能够尊重 MacOS 的证书存储，那么这种头痛也会消失。
• 如果在 Toolbox 安装过程中提示他们添加证书或进行此配置到 docker-machine，那也可能没问题。

请让这个问题的 70 多位参与者知道你打算如何处理这个问题，否则请关闭这个问题，这样我们就不会悬而未决。 谢谢。

@thaJeztah
如果不重新启动所有正在运行的容器，就无法将单个 --insecure-registry 添加到守护进程 opts。 这是主要问题之一。 我们无法在不重新启动的情况下重新加载配置（问题从 2013 年开始），我们无法从其他不安全的注册表中提取图像而无需向守护程序添加选项并重新启动。 现在我们仍然没有解决这个问题的明确路线图。

@apakhomov猜测它可以添加到配置更改列表中，无需重新启动即可更新https://docs.docker.com/engine/reference/commandline/daemon/#configuration -reloading。 你能为此打开一个单独的问题吗？

+1。

一些 PaaS 提供商不授予对守护程序的访问权限并为用户运行专用网络（例如 Jelastic）。

是否可以向 docker 添加多个不安全的注册表？
类似于--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 :

谢谢@mingfang和@thaJeztah

正如@mhamrah和@justinclayton建议的那样，我还建议使用 ssh 和 TLS 的解决方案，类似于 Git 允许使用 ssh 和 TLS 访问存储库的方式。 这可能会利用@justinclayton列出的 ssh 解决方法。

虽然我没有数据来支持我的说法，但我猜想在防火墙后面运行的私有注册表比在开放 Internet 上运行的注册表多得多。 在这种情况下，ssh 更容易配置，并且比 TLS 更安全。

此外，在与docker push和我在内部、足够安全的虚拟机中运行的本地私有注册表（以及更多时间努力创建自签名证书）斗争了几天之后，我真的很感激rkt --insecure-options=image,tls,http 。

很生气，这不是客户端设置。 显然它不应该默认开启，因为这会鼓励不安全的做法。 但是，将设置放在守护程序上对于调试目的或在本地开发环境中非常不切实际。

我当前的用例：使用 docker compose 运行开发环境。 该环境需要一个本地 docker 注册表。 它旨在完全在本地 VM 上运行。

docker 方式：解释如何配置 docker-machine 以在每台开发人员的机器上启用不安全的注册表，如果他们已经拥有一个或手动编辑配置，可能需要他们重新创建他们的 docker-machine。

hacky 解决方案：socat 在需要使用注册表的每个容器中运行，重定向到 localhost。

并不完全使事情变得容易......

+1

真可惜 --insecure 不是客户端配置！
这给我们带来了很多痛苦，也与上面的许多解释非常相似。
请默认设置 --insecure-registry=0.0.0.0/0 pr 提供一种将其传递给 docker 命令以及 docker-compose 配置的方法。

+1

+1

又到一年一度的+1 怜悯派对了吗？

2016年12月13日凌晨1点，沙包妖梦[email protected]发文：

+1

—
您收到此消息是因为您发表了评论。
直接回复此邮件，在 GitHub 上查看，或将线程静音。

如果图像层已签名，则无需使用 CA PKI 来确保安全。 另请参阅 apt/yum 如何工作。 此外，在 LAN 中使用 SSL 意义不大，而在云环境中，这意味着您必须提供 - 除了证书本身 - 以获得良好的随机性源（另请参阅：https://lukehinds.github.io/2015-03 -03-云中熵/)。

长话短说：如果没有必要，不要强加于用户。

我刚刚打开了相关的#29736。

+1，如果没有客户端--insecure-registry标志，则应该有一种方法可以指定用于docker pull和docker push的受信任证书。 并非每个人都可以访问操作系统级别的信任证书，或者可以使用 Docker 守护程序。

托管 CI 服务器（用于构建 docker 映像并推送到私有注册表）是您可能没有该级别访问权限的一个很好的例子。

+1

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

@tiborvass
仅当您具有 sudo 访问权限时才有效...

+1 阻止开发人员使用 docker 的好方法

+1，我也想看到docker login --insecure-registry。

我什至不认为这是一个安全问题，因为您是有意识地这样做的。 如果有人未经授权获得了 root 访问权限，这也不会提供任何安全性。 这种限制实际上有什么好处？

如果你有恶意，你可以将你的恶意docker

+1，坦率地说，这令人难以置信

+1 到疼痛训练。

再加上他妈的一个！

这个有公关吗？

不是AFAIK。 生成上面的链接是因为我自己的一些代码引用了这个问题。 我会拉一段时间的参考，以平息这里的垃圾邮件。

+1 还有...

+1

+1 ，将设置添加到deamon.json并重新启动 docker 非常不方便。

不同的机器有不同的 os 。 有些从yum 、 apt-get安装 docker，有些直接使用 binary 。 所以我必须检测到并正确重启 dockerd .... 那是一场灾难

我只是强调 docker pull 需要--insecure-registry标志！

仅仅过去了三年-让我们现在不要失去希望

磕磕碰碰🤣

+1

+1

认为这鼓励用户将其注册表设置为安全的论点不仅自以为是，而且还缺少一个关键点。 它将操作置于许多人必须有权访问 root 帐户才能执行操作工作的位置，而 docker 注册表经常移动。
从操作安全的角度来看，这种耦合会产生更大的安全风险。

其次，在私有网络中（例如在多层云托管应用程序中），注册表的保护是不必要的，并且进一步使位于顶层的技术实现复杂化，需要安全管理层（以处理自动 docker 身份验证/刷新）在任何使用安全 docker 注册表的地方。

至少，docker 守护进程应该可配置为允许传入不安全的注册表参数。这将安全设计移到适当的位置 - 在管理员手中，在 docker 本身之外。

FWIW 我对“将一些注册表添加到不安全注册表列表中”的命令感到满意，因为从 shell 脚本修补 json 配置是一个主要的痛点。

+1

：+1：+1

+1

+1

+1

+1

许多要求的实现将使使用 Docker 的公司无法遵守 SOC 合规性要求等。

应该有一个解决方案，但我认为没有一个简单的解决方案不会对图像的存储和执行方式进行更剧烈的架构更改。

不过，这应该发生。

我不再参与 Docker 开发，所以我将从提及中删除自己。 祝你好运^_^

SOC 要求是一个很好的点。 在这种情况下，应启用此功能，并在系统范围的 docker 配置中添加一个配置选项。 这样就可以保留 SOC 要求。 类似于“ALLOW_INSECURE_REGISTY_OPTION”之类的东西，它在 docker 命令行上启用 --insecure-registry 标志。

对于 SOC 合规性，不得启用该选项。

+1

仅仅过去了三年-让我们现在不要失去希望

5.

该提案（以目前的形式）不太可能实施，因为各种
原因，其中；

• 它让管理 docker 守护进程的人负责什么连接
  守护进程被允许制作。 请注意，此选项可以“实时重新加载”，
  因此不必重新启动守护程序即可更改配置。
• 每个可能与注册表交互的命令或代码路径都将具有
  待修改； 不只是docker pull ，还有docker build ， docker run ，
  docker plugin 、 docker service和docker stack子命令，以及
  编排器，例如 swarmkit，它从工作节点拉取图像。
• SOC 合规性（如上所述）

至少，docker 守护进程应该可配置为允许不安全
要传入的注册表参数。这将安全设计移动到正确的
地方 - 在管理员手中，在 docker 本身之外。

我认为在这种情况下，管理员将是管理
运行 docker 守护进程的主机，而不是连接到远程的用户
应用程序接口。 这就是此配置成为守护程序配置的原因。

从 shell 脚本修补 json 配置是一个主要的痛点。

这是一个公平的观点，但与本次讨论正交。 这不是_不可能_
修补 JSON 配置，但同意它可能比其他配置更复杂
文件格式。 请注意，此配置也可以设置为通过标志
守护进程，它允许您使用 systemd 插入单元文件来重新配置
守护进程。

类似于“ALLOW_INSECURE_REGISTY_OPTION”之类的东西，它在 docker 命令行上启用 --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