我们希望避免在dockerfiile中包含"yum update"，因为它可以根据docker映像的构建时间生成不同的容器，但显然，如果需要更新基本系统，这可能会带来一些安全问题。拥有组织范围的基本系统映像并对其进行更新真的是最佳选择吗？问题是，每次应用安全更新时，都需要在整个组织中重建和部署所有应用程序。
对我来说似乎有点不合时宜的另一种方法是简单地忽略容器中的安全更新，只担心主机上的更新。这里的思考过程是，要让攻击者进入容器，主机上需要有一个漏洞，docker引擎中的另一个漏洞才能进入容器，然后是一个额外的漏洞来利用容器中的某些东西，这似乎是一系列不太可能的事件。随着用户名间距和 seccomp 配置文件的引入，这似乎进一步降低了风险。
无论如何，我如何处理容器中的安全更新，同时将对 CI/CD 管道的影响降至最低，或者理想情况下不必经常重新部署整个基础结构？
您可以通过引入中间更新层来减少构建的不可重复性。
创建如下图像：
FROM centos:latest
RUN yum update -y
构建映像，标记并推送映像。现在，除非您决定更改它们，否则您的构建不会更改。
一旦您决定这样做，您可以将其他 Dockerfile 指向myimage:latest以获取自动更新，也可以指向特定版本。
我设置 CI 系统的方式是，使用更新成功（手动）构建基础映像会触发依赖于它的任何映像的构建。
报告安全问题？检查更新的软件包是否可用或在 Dockerfile 中执行临时修复。触发生成。一段时间后，您将准备好部署所有应用程序的固定版本。
大多数主要发行版会经常发布新的基础映像，其中包括最新的关键更新和安全修复程序。这意味着您只需拉取最新的基础映像即可获取这些修复并重新生成映像。
但是，由于您的容器使用的是 yum，因此您可以利用 yum 来控制更新哪些包。Yum 允许您设置发布版本，以便您可以将更新固定到特定的操作系统版本。
例如，如果您使用的是 RHEL 7.2，则可能有一个如下所示的 Dockerfile：
FROM rhel:7.2
RUN echo "7.2" > /etc/yum/vars/releasever
RUN yum update -y && yum clean all
这可确保您将保留在 RHEL 7.2 上，并且只接收关键的软件包更新，即使您执行完整的 yum 更新也是如此。
有关可用的 yum 变量或其他配置选项的更多信息，请查看"yum.conf"手册页。
此外，如果您需要对更新进行更精细的控制，您可以查看"yum-plugin-versionlock"包，但这很可能对您的需求来说是矫枉过正的。