![如何处理过时的 Docker 镜像?](https://linux22.com/image/949895/%E5%A6%82%E4%BD%95%E5%A4%84%E7%90%86%E8%BF%87%E6%97%B6%E7%9A%84%20Docker%20%E9%95%9C%E5%83%8F%EF%BC%9F.png)
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
要点:
大多数容器镜像都会定期更新以包含更新,包括安全更新。
容器并不像基础系统那样脆弱,因为:
- 它们在隔离的环境中运行
- 他们只使用一部分软件包
- 内核仍然属于基础系统
如果你真的担心某个特定的图像,可以自己重建它。
Dockerfile
可以在 Github 或类似网站上找到。
总体而言,我不会太担心这一点。另一方面,如果你真的依赖第三方提供你的图片,那么一如既往地只信任信誉良好的来源。
对于生产用途,出于同样的原因,通常建议始终构建自己的图像。