构建dockerfile

Question

我工作的公司（严格监管/审核环境）尚未采用容器，但希望在某些应用中采用它们。有观点认为，当图像构建过程以root身份发出命令（或者可以通过使用USER命令被用户覆盖）时，构建（未运行）容器有效地在构建期间以root身份为用户提供不受限制的访问处理。这对他们来说是一种诅咒，违背了各种公司政策。通过PowerBroker限制对计算机的某些命令的访问，即访问某些命令需要明确的许可并记录/接受审计。

我们需要允许CI / CD系统构建容器映像，并且理想情况下允许开发人员能够在本地构建容器。容器通常在Kubernetes中运行，但可以直接在VM上运行。我希望CI构建代理能够随需应变，因为有很多开发人员，所以我想在Kubernetes中运行构建过程。

在这种环境中构建泊坞容器的最佳做法是什么？我们是否应该限制访问Dockerfile中的命令？

我目前对这种方法的想法：

CI / CD：

1. 定义“公司批准的”图像以充当其中的构建代理 Kubernetes。
2. 构建映像定义构建过程运行的用户（不是 根）。
3. 构建代理映像包含PowerBroker，可启用锁定访问 敏感的命令。
4. 扫描docker文件以使用用户命令并禁止此操作。
5. 构建代理按照此处运行docker-in-docker （https://applatix.com/case-docker-docker-kubernetes-part-2/）。这个 实现多个构建实例之间的隔离，同时确保 所有容器都通过Kubernetes控制。
6. 通过OpenSCAP或类似方法扫描图像以确保安全。 传递扫描是构建过程的一部分。通过扫描 允许将图像标记为合规并推送到注册表。

我对（4）的思考感到不安，因为这似乎有点规则（即它是一种黑名单方法），我相信必须有更好的方法。

开发者的localhost：

1. 定义“公司认可的”基本图像（在a。中标记为“基本图像”） 可信赖的注册局）。
2. Image定义构建过程运行的用户 as（不是root）。
3. 基本映像包含PowerBroker，可启用锁定功能 对敏感命令的访问权限。
4. 在localhost上创建包装docker build的包装器脚本。无法直接访问docker build：用户必须使用脚本。通过PowerBroker保护对脚本的访问。脚本还可以扫描docker文件以使用用户命令并禁止此操作。
5. 将图像推送到注册表需要标记，这需要通过OpenSCAP或类似方法扫描安全合规性。

我想使用OpenSCAP结果和CI系统来创建存在的图像的审计跟踪;类似的部署过程。监视CVE等的安全团队应该能够理解存在和已部署的容器，并能够触发图像的重建以利用更新的库，或者在需要重建/重新部署容器时向开发人员标记。我希望能够证明所有容器都符合本身定义为代码的安全配置策略。

这是一种明智的方式吗？是否存在允许用户无限制地构建（但不运行）容器图像的风险？如果没有，那么确保愚蠢/恶意开发人员没有撤消“已批准的基本映像”中的最佳实践的最佳方法是什么，除了手动代码审查（无论如何都会进行，但可能会遗漏某些内容） ）？

顺便说一句，您必须假设所有代码/图像都在内部/内部托管，即不允许任何内容使用基于云的产品/服务。

Answer 1

当docker build运行时，每个图层都在容器的上下文中执行。因此，该命令执行所带来的风险受到容器可用访问权限的限制。

可以通过限制完成构建的Docker引擎实例可以做什么来锁定构建环境。

确保使用用户名称空间之类的事情可以降低在对环境产生更广泛影响的容器内运行命令的风险。

当然，这并没有减轻开发人员从不受信任的位置肆虐的风险，但是那么阻止在Docker之外完成的工作是什么？ （即在这种情况下使用Docker引入了额外的风险）

例如，如果您有限制外部托管代码的策略，那么一个选项可能只是限制从Docker构建主机到Internet的访问。

如果你正在使用Kubernetes进行构建过程并担心恶意软件在容器中执行，那么值得审查CIS Kubernetes standard并确保你已经锁定了适当地聚集。

Answer 2

  

有观点认为，随着图像构建过程发出命令   root（或者可以通过使用USER命令被用户覆盖），   构建（未运行）容器有效地为用户提供   在构建过程中以root用户自由访问

此观点不正确。构建映像时，您所做的就是创建存储在/var/lib/docker/aufs/layers下的新docker层（文件）。构建docker镜像时，没有任何安全问题。

有一些工具可以分析您已构建的图像的安全性。一个是Dockerhub中内置的图像分析器。