伸手党的容器镜像加固流程
人在江湖飘，哪能不挨刀
说了好几期 CIS 之类的运行时安全问题，K8s 在运行过程中，还有个常见的安全威胁就是镜像漏洞，不少同学都有在实施过程中因为镜像漏洞问题被吊打的经验，今天就结合个人经验，说说镜像漏洞修复的一般流程。
这里主要指的是第三方镜像的修复过程，Scratch 不在此列。
开局一张图：
修复任务分析
通常扫描报告会明确指明确切的问题源头、相关软件包、问题版本、修复版本等，首先要根据报告判断修复的目标。修复目标并不一定是固定的，有些情况下可能仅需要修复公开的高危漏洞，有些可能要求更多。
我们都知道，容器镜像是个分层结构，底层通常由操作系统（例如 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把官方镜像中的应用文件复制出来即可。
复测
在完成修复步骤之后，可以针对性地进行复测，查看修复情况，循环往复直到完成目标为止。