伸手党的容器镜像加固流程

人在江湖飘，哪能不挨刀

说了好几期 CIS 之类的运行时安全问题，K8s 在运行过程中，还有个常见的安全威胁就是镜像漏洞，不少同学都有在实施过程中因为镜像漏洞问题被吊打的经验，今天就结合个人经验，说说镜像漏洞修复的一般流程。

这里主要指的是第三方镜像的修复过程，Scratch 不在此列。

开局一张图：

graph TD
  start(修复任务) --> base_or_app{基础/应用}
  base_or_app-->|业务漏洞|official_image{官方镜像}
  base_or_app-->|基底漏洞|os_updated{底层更新}
  os_updated-->|是|reos_pass{底层扫描}
  os_updated-->|否|change_os(更换底层)
  change_os-->reos_pass
  reos_pass-->|已解决|can_build
  reos_pass-->|未解决|change_os
  official_image --> |是|image_updated{是否已更新?}
  official_image --> |否|can_build{源码齐全}
  image_updated --> |是|rescan_pass{重新扫描通过}
  rescan_pass --> |是|fin(结案)
  rescan_pass --> |否|start
  image_updated -->|否|can_build
  can_build --> |是|docker_build(docker build)
  can_build --> |否|docker_cp(docker cp/commit)
  docker_cp --> rescan_pass
  docker_build --> rescan_pass
  change_os --> rescan_pass

修复任务分析

通常扫描报告会明确指明确切的问题源头、相关软件包、问题版本、修复版本等，首先要根据报告判断修复的目标。修复目标并不一定是固定的，有些情况下可能仅需要修复公开的高危漏洞，有些可能要求更多。

我们都知道，容器镜像是个分层结构，底层通常由操作系统（例如 debian:buster-slim）或者特定运行时（例如 openjdk:16）构成；另外可能构建应用程序，或者直接通过 COPY/ADD 的方式加入应用程序；另外还会通过 CMD、ENV 等指令设置运行环境等。软件漏洞多发于底层和应用程序层，因此这里需要根据扫描报告，确认我们的修复目标。

软件配置问题也可能造成漏洞，可以另行讲解。

应用层漏洞

如果要修复的问题是处于应用层，就要判断该镜像是否为官方镜像，如果答案是肯定的，则可以直接更新官方镜像，通常同一个大版本下的小版本更新，都是兼容的，可以更新之后直接进行测试和复查。

如果官方没有针对性的修复，或者镜像并未更新，就可能需要自己构建镜像了。

如果是开源软件，强烈建议提交 Issue 或者 PR

基础层漏洞

如果是基础层漏洞，除了可以像应用层修复一样，检查版本更新之外，还有另一个选项，就是更换不同的基础层，例如从 Debian 更换为 Ubuntu，这种方式对于 all-in-one 形式的应用（例如大多数用 golang 构建的应用）尤其有效，如果应用程序依赖众多，就不合适了。另外众所周知，Alpine 和我们常用的发行版差异较大，因此也不太合适直接切换。

镜像构建

是不是就一个 docker build 就可以了？多数时候是的。不过要分成几种情况。

• 有 Dockerfile 的情况

  • 官方已经发布二进制物料：这种情况通过修改 Dockerfile 加入更新的二进制文件之后，执行 docker build 即可。

  • 官方未发布二进制物料：这种就需要根据源码进行构建，然后再生成 Docker 镜像。

• 没有 Dockerfile 的情况

  • 有的软件源码中通过 Makefile 等方式提供了从二进制到镜像的构建方法，通常需要在 README.md 或者 BUILD.md 中查找线索。

  • 更换底层的情况，通常需要自己照猫画虎，重新编写 Dockerfile。

  • 还有一种比较尴尬的情况——有二进制物料，但是没 Dockerfile，这种我通常会使用 docker cp->docker commit 的不入流方式。

  • 另外一种尴尬情况就是，官方只提供了 Docker 镜像，但是我们想要换掉基础层，这种情况和上面类似，用 docker cp 把官方镜像中的应用文件复制出来即可。

复测

在完成修复步骤之后，可以针对性地进行复测，查看修复情况，循环往复直到完成目标为止。