限制推拉到docker可信注册表DTR

在docker EE中，是否有一种方法允许从特定机器推拉DTR，同时保持web UI访问与正常情况相同

• 用例是，我们希望仅在docker构建中强制使用DTR中的标准基本映像
• 我们希望仅在启用docker内容信任的标准docker构建机器上强制docker映像构建

• 仅允许以下命令：CI服务器上的docker pull、docker build和docker push

---

有效地强制用户仅使用DTR中的基本图像。如果他们在其他地方构建映像，他们将无法将其推送，如果他们在我们的CI服务器上构建映像，将确保他们只能从DTR而不是从其他地方提取基本映像，这也将确保他们在启用docker内容信任的情况下构建它。

我经历了一个类似的用例，下面我将与您分享我如何限制DTR上的拉、推操作：

• 配置：谁有权在服务器上执行某些操作 注册表对象，并通过UCP web UI加载Docker图像； 这将导致向用户和/或团队提供特定的资助

• 配置：从用户（人类和/或自动化机器人）可以 通过在网络上添加特定的防火墙规则来执行注册表操作 级别由网络管理员决定

• 仅从特定注册表限制拉取操作， 在Docker主机文件系统的以下路径更新文件， /var/lib/docker/daemon.json添加DTR的URL:

    { 
      ... # some your custom Docker daemon configuration
      "registry-mirrors": ["https://your-registry-url"]
      ... # some other custom Docker daemon configuration
    }
  

最后，我得到了：只允许特定用户在DTR存储库中推送Docker图像，并且只允许从网络ACL列出的位置推送Docker图像

一些参考资料：

• 如何配置Docker守护程序：

• RBAC示例：

• Docker EE RBAC支持的DTR默认权限：

---

您好，我们希望所有用户都可以拉和推，但只能从我们的CI服务器上拉和推，但所有用户都应该能够从任何地方浏览DTR UI。也许我们可以在端口80上提供UI，在端口443上提供API？所以我们要做ACL的事情？在每次构建期间，您如何从用户的角度管理CI服务器和DTR之间的交互？例如：用户在推送映像之前是否登录到DTR？用户使用其DTR凭据从CI服务器拉送到DTR，但我们希望确保用户仅从CI服务器推送到DTR。此外，用户应该可以自由地从DTR拉送到任何地方，以便进行部署