☰

如何处理过时的 Docker 镜像？

tag-icon • tag-icon docker container
如何处理过时的 Docker 镜像？

Docker 镜像是在某个时间点构建的，之后这些镜像的用户会获取它们，并基于它们创建容器。看看 Linux 发行版（如 Ubuntu）上更新的频率，这是否意味着这些镜像在发布到镜像存储库后的第二天就过时了？

假设有人为他们的应用程序创建了一个图像：

FROM ubuntu
RUN apt update -y # or whatever the command to update on Ubuntu is

WORKDIR /myapp
COPY ./* ./
# and some other stuff

应用程序在某一天构建完成（ubuntu:latest从那天开始使用），所有最新补丁都通过应用RUN apt update -y，并且镜像被推送到 Docker 存储库。现在，如果第二天在 Ubuntu 的 apt 存储库上发布了一些关键更新（例如一些 openssl 补丁），该怎么办。我的应用程序怎么办？现在不安全了吗，直到我手动决定重建镜像并再次推送它？也许我们实际上不应该关心镜像/容器是否过时，而只担心运行容器的主机是否是最新的？如果是这样，为什么？

答案1

我不会发表评论，而是在答案中总结我的想法：

这些图片在发布到图片库的第二天就过时了

是的，但仅限于对任何操作系统和平台上的任何服务器也适用的情况。可以说，漏洞窗口是平均而言对于容器来说，这个时间更短，因为它们升级基础操作系统层的频率比“普通”服务器更高，但这并不意味着应该忽略它们，当然也不总是如此——很容易想象，有些虚拟机的修补频率比其他容器的重新部署频率更高。

如果您安装常规 Ubuntu VM 并将其放置 30 天，则很可能会有未应用的安全修复。对于部署 30 天的容器也是如此，这意味着两个都在这种情况下，如果您不能确保操作系统级别保持最新（例如，通过从新的操作系统映像重新部署整个容器/虚拟机），则应该制定修补程序。

我的应用程序怎么办？现在是否不安全，直到我手动决定重建映像并再次推送它？

这当然取决于您的应用程序的依赖项。您的应用程序“不安全”的程度与假设的安全修复包对您的应用程序的重要性有关。

如果您正在运行使用 log4j 的 java 应用程序，并且存在一个在 Ubuntu 存储库中已修复的严重漏洞，那么无论您是在容器还是虚拟机上运行，​​您都同样容易受到攻击，直到您更新该软件包 - 无论是通过从apt-get包含新软件包的新操作系统映像重新部署整个虚拟机/容器来完成，都不是重要的部分。

“我的应用程序是否安全或者是否受到过时软件包中的漏洞的影响”这个根本问题实际上并不是 Docker 或 Ubuntu 所特有的，除了虚拟机和容器之间明显不同的一种情况外，这个问题在任何地方都是一样的，即所有容器都与其主机共享一个内核，因此内核漏洞无法从容器内部修补，但直接取决于部署容器的主机上运行的内核版本。

答案2

要点：

  1. 大多数容器镜像都会定期更新以包含更新，包括安全更新。

  2. 容器并不像基础系统那样脆弱，因为：

    • 它们在隔离的环境中运行
    • 他们只使用一部分软件包
    • 内核仍然属于基础系统

  3. 如果你真的担心某个特定的图像，可以自己重建它。Dockerfile可以在 Github 或类似网站上找到。

总体而言，我不会太担心这一点。另一方面，如果你真的依赖第三方提供你的图片，那么一如既往地只信任信誉良好的来源。

对于生产用途，出于同样的原因，通常建议始终构建自己的图像。

相关内容