本文介绍了 12 个优化 Docker 镜像安全性的技巧。每个技巧都解释了底层的攻击载体，以及一个或多个缓解方法。这些技巧包括了避免泄露构建密钥、以非 root 用户身份运行，或如何确保使用最新的依赖和更新等。
前言
当你是刚开始使用 Docker 的新手时，你很可能会创建不安全的 Docker 镜像，使攻击者很容易借此接管容器，甚至可能接管整个主机，然后渗透到你公司的其他基础设施中。
可以被滥用来接管你的系统的攻击向量有很多，例如：
启动的应用程序（在你 Dockerfile 的 ENTRYPOINT 中指定）以 root 用户身份运行。这样以来，一旦攻击者利用了一个漏洞并获得了 shell 权限，他们就可以接管 Docker 守护程序所运行的主机。
你的镜像是基于一个过时的和/或不安全的基础镜像，其中包含（现在）众所周知的安全漏洞。
你的镜像包含了一些工具（如 curl、apt 等），一旦攻击者获得了某种访问权，就可以通过这些工具将恶意软件加载到容器中。
下面的各个章节讲解了能够优化你的镜像安全性的各种方法。它们是按重要性/影响程度排序的，也就是说排名靠前的方法更重要。
避免泄露构建密钥
构建密钥是只在构建 Docker 镜像时需要的凭证（不是在运行时）。例如，你可能想在你的镜像中包含某个应用程序的一个编译版本，这个应用的源代码是闭源的，并且其 Git 存储库是有访问保护的。在构建镜像时，你需要克隆 Git 存储库（这需要构建密钥，例如该存储库的 SSH 访问密钥），从源代码构建应用程序，然后再删除源代码（和密钥）。
“泄露“构建密钥是说你不小心把这种密钥烘焙到了你的镜像的某个层中。这种情况很严重，因为拉取你的镜像的所有人都可以检索到这些机密。这个问题源于这样一个事实，即 Docker 镜像是以纯粹的加法方式逐层构建的。你在一个层中删除的文件只是被“标记”为已删除，但拉取你镜像的人们仍然可以使用高级工具访问它们。
可以使用以下两种方法之一来避免泄露构建密钥。
多阶段构建
Docker 多阶段构建（官方文档）有许多用例，例如加快你的镜像构建速度，或减少镜像大小。本系列的其他文章会详细介绍其他用例。总之，你也可以通过多阶段构建来避免泄露构建密钥，如下所示：
创建一个阶段 #A，将凭证复制到其中，并使用它们来检索其他工件（例如上述例子中的 Git 存储库）和执行进一步的步骤（例如编译一个应用程序）。阶段 #A 的构建确实包含了构建的密钥！
创建一个 #B 阶段，其中你只从 #A 阶段复制非加密的工件，例如一个已编译的应用程序。
只发布/推送阶段 #B 的镜像
BuildKit 的密钥
背景知识
如果你使用 docker build 进行构建，可以实际执行构建的后端选项不止一个。其中较新和较快的后端是 BuildKit，你需要在 Linux 上设置环境变量 DOCKER_BUILDKIT=1 来显式启用它。注意，BuildKit 在 Windows/MacOS 的 Docker for Desktop 上是默认启用的。
正如这里的文档所解释的（阅读它们以了解更多细节），BuildKit 构建引擎支持 Dockerfile 中的额外语法。要使用构建密钥，请在你的 Dockerfile 中放入类似下面这样的内容：
当 RUN 语句被执行时，密钥将对这个构建容器可用，但不会将密钥本身（这里是：/foobar 文件夹）放入构建的镜像中。你需要在运行 docker build 命令时指定密钥的源文件/文件夹（位于主机上）的路径，例如：
不过有一点需要注意：你不能通过 docker-compose up --build 来构建需要密钥的镜像，因为 Docker-compose 还不支持用于构建的--secret 参数，见 GitHub问题。如果你依赖 docker-compose 的构建，请使用方法 1（多阶段构建）。
题外话：不要推送在开发机上构建的镜像
你应该一直在一个干净的环境中构建和推送镜像（例如 CI/CD 管道），其中构建代理会将你的存储库克隆到一个新目录。
使用本地开发机器进行构建的问题是，你的本地 Git 存储库的“工作树“可能是脏的。例如，它可能包含有开发过程中需要的密钥文件，例如对中转甚至生产服务器的访问密钥。如果没有通过.dockerignore 排除这些文件，那么 Dockerfile 中的“COPY . .“等语句可能会意外导致这些密钥泄露到最终镜像中。
以非 root 用户身份运行
默认情况下，当有人通过“docker run <more arguments> yourImage:yourTag“运行你的镜像时，这个容器（以及你在 ENTRYPOINT/CMD 中的程序）会以 root 用户身份运行（在容器和主机上）。这给了一个使用某种漏洞在你的运行容器中获得 shell 权限的攻击者以下权力：
对主机上所有显式挂载到容器中的目录的无限制写权限（因为是 root）。
能够在容器中做 Linux 根用户可以做的一切事情。例如，攻击者可以安装他们需要的额外工具来加载更多的恶意软件，比如说通过 apt-get install（非 root 用户无法做到这一点）。
如果你的镜像容器是用 docker run --privileged 启动的，攻击者甚至可以接管整个主机。
为了避免这种情况，你应该以非 root 用户（你在 docker build 过程中创建的一些用户）的身份运行你的应用程序。在你的 Dockerfile 中的某个地方（通常是在结尾处）放置以下语句：
Dockerfile 中所有在 USER appuser 语句之后的命令（如 RUN、CMD 或 ENTRYPOINT）都将以这个用户运行。这里有一些需要注意的地方：
在切换到非 root 用户之前，你通过 COPY 复制到镜像中的文件（或由某些 RUN 命令创建的文件）是由 root 用户拥有的，因此以非 root 用户身份运行的应用程序无法写入。为了解决这个问题，请把创建和切换到非 root 用户的代码移到 Dockerfile 的开头。
如果这些文件是在 Dockerfile 的开头以根用户身份创建的（存储在/root/下面，而不是/home/appuser/下面），那么你的程序期望在用户的主目录中的某个地方（例如~/.cache）的文件，现在从应用程序的视角来看可能突然消失了。
如果你的应用程序监听一个 TCP/UDP 端口，就必须使用大于 1024 的端口。小于等于 1024 的端口只能以 root 用户身份使用，或者以一些高级 Linux 能力来使用，但你不应该仅仅为了这个目的而给你的容器这些能力。
使用最新的基础镜像构建和更新系统包
如果你使用的基础镜像包含了某个真正的 Linux 发行版（如 Debian、Ubuntu 或 alpine 镜像）的全部工具集，其中包括一个软件包管理器，建议使用该软件包管理器来安装所有可用的软件包更新。
背景知识
基础镜像是由某人维护的，他配置了 CI/CD 管道计划来构建基础镜像，并定期推送到 Docker Hub。你无法控制这个时间间隔，而且经常发生的情况是，在该管道将更新的 Docker 镜像推送到 Docker Hub 之前，Linux 发行版的包注册表（例如通过 apt）中已经有了安全补丁。例如，即使基础镜像每周推送一次，也有可能在最近的镜像发布几小时或几天后出现安全更新。
因此，最好总是运行更新本地软件包数据库和安装更新的包管理器命令，采用无人值守模式（不需要用户确认）。每个 Linux 发行版的这个命令都不一样。
例如，对于 Ubuntu、Debian 或衍生的发行版，使用 RUN apt-get update && apt-get -y upgrade
另一个重要的细节是，你需要告诉 Docker（或你使用的任何镜像构建工具）来刷新基础镜像。否则，如果你引用一个基础镜像，比如 python:3（而 Docker 在其本地镜像缓存中已经有了这样一个镜像），Docker 甚至不会检查 Docker Hub 上是否存在更新的 python:3 版本。为了摆脱这种行为，你应该使用这个命令：
这可以确保 Docker 在构建镜像之前拉取你的 Dockerfile 中 FROM 语句中提到的镜像的更新。
你还应该注意 Docker 的层缓存机制，它会让你的镜像变得陈旧，因为 RUN <install apt/etc. updates>命令的层是缓存的，直到基础镜像维护者发布新版本的基础镜像才刷新。如果你发现基础镜像的发布频率相当低（比如少于一周一次），那么定期（比如每周一次）重建你的镜像并禁用层缓存是个好主意。你可以运行以下命令来做到这一点：
定期更新第三方依赖
你编写的软件是基于第三方的依赖，也就是由其他人制作的软件。这包括了：
你的镜像下面的基础 Docker 镜像，或
你作为自己应用程序的一部分使用的第三方软件组件，例如通过 pip/npm/gradle/apt/……安装的组件。
如果你的镜像中的这些依赖过时了，就会增加攻击面，因为过时的依赖往往有可利用的安全漏洞。
你可以定期使用 SCA（软件组件分析）工具来解决这个问题，比如Renovate Bot。这些工具（半）自动将你声明的第三方依赖更新为最新版本，例如在你的 Dockerfile、Python 的 requirements.txt、NPM 的 packages.json 等文件中声明的列表。你需要设计你的 CI 管道，使 SCA 工具所做的更改自动触发你的镜像的 re-build。
这种自动触发的镜像重建对于处在只维护模式，但代码仍将被客户在生产环境中使用（客户希望它是安全的）的项目特别有用。在维护期间，你不再开发新的特性，也不会构建新的镜像，因为没有新的提交（由你做出）来触发新的构建。然而，由 SCA 工具做出的提交确实会再次触发镜像构建。
你可以在我的相关博文中找到更多关于 Renovate bot 的细节。
对你的镜像进行漏洞扫描
即使你执行了上述建议，比如说你的镜像总是使用最新的第三方依赖，它仍然可能是不安全的（例如一个依赖已经被弃用的情况）。在这种情况下，“不安全“意味着一个（或多个）依赖有已知的安全漏洞（在一些 CVE 数据库中注册）。
出于这个原因，你可以给你的 Docker 镜像提供某种工具来扫描所有包含的文件，以找到这种漏洞。这些工具有两种形式：
你显式调用的 CLI 工具（例如在 CI 管道中），比如说Trivy（OSS，在 CI 管道中非常容易使用，见 Trivy文档）、Clair（OSS，但设置和使用比 Trivy 更复杂），或Snyk（通过“docker scan“集成到 Docker CLI 中，见cheat sheet，但只有有限的免费计划！)
集成到你推送镜像的镜像注册中心的扫描器，如 Harbor（内部使用 Clair 或 Trivy）。还有一些商业产品，如Anchore。
因为这些扫描器是通用的，它们还试图覆盖一大堆包注册表，所以可能不会特别为你在自己项目中使用的编程语言或包注册表定制。有时，你应该调查你的编程语言生态系统提供了哪些工具。例如，对于 Python 来说就有一个专门针对 Python 包的安全工具。
扫描你的 Dockerfile 是否违反了最佳实践
有时，问题来自于你在 Dockerfile 中放置的语句，这些语句是不好的实践（但你没有意识到）。为此可以使用诸如checkov、Conftest、trivy或hadolint等工具，它们是 Dockerfile 的 linter。为了选择正确的工具，你需要查看它的默认规则/政策。例如，hadolint 比 checkov 或 conftest 提供的规则更多，因为它是专门针对 Dockerfiles 的。这些工具也是相互补充的，因此在你的 Dockerfiles 上运行多个工具（如 hadolint 和 trivy）确实是有意义的。不过要做好准备，因为你需要维护“忽略文件“，在这个文件中的规则会被忽略——可能是由于误报而有意忽略它们，或者是你准备故意破坏规则。
不要对 Docker Hub 使用 Docker 内容信任
为了验证你使用的基础镜像确实是由该镜像背后的公司构建和推送的，你可以使用 Docker 内容信任（见官方文档）特性。只需在运行 docker build 或 docker pull 时将 DOCKER_CONTENT_TRUST 环境变量设为“1“即可启用该特性。Docker 守护进程将拒绝提取没有经过发布者签名的镜像。
不幸的是，大约一年前开始社区就不再以这种方式签名镜像了。就连 Docker Inc.也在 2020 年 12 月停止了签名官方 Docker镜像，也没有官方解释。问题更大的是如果你使用“docker pull docker:latest”这样的命令，只会下载一个过时很久的镜像。
你可以查看一下镜像签名的其他实现，比如说cosign（不过我还没试过）。
扫描你自己的代码是否有安全问题
安全问题通常来源于其他人的代码，也就是流行的第三方依赖。因为它们应用广泛，所以在黑客那里是“有利可图“的。然而，有时是你自己的代码在作怪。例如，你可能不小心实现了 SQL 注入的可能性、堆栈溢出的错误，等等。
为了找到这些问题，你可以使用所谓的 SAST（静态应用安全测试）工具。一方面，有一些特定于编程语言的工具（你必须单独研究），如 Python 的bandit，或 Java 的Checkstyle/Spotbugs。另一方面，还有一些支持多种编程语言和框架的工具套件（其中一些是非免费/商业的），如SonarQube（对于它还有SonarLintIDE 插件）。这里是 SAST 工具列表。
在实践中，安全扫描有两种基本方法：
连续（自动）扫描：你创建一个 CI 作业，在每次推送时扫描你的代码。这可以让你的代码安全性保持在一个较高的水平上，但你必须弄清楚如何忽略误报（这是一项持续的维护工作）。如果你使用 GitLab，可能还会发现 GitLab 的免费 SAST功能很有趣。
不定期（手动）扫描：团队中一些有安全意识的成员在本地运行安全检查，例如每月一次或每次发布前，并手动查看结果。
使用 docker-slim 来删除不必要的文件
docker-slim工具可以获取大型 Docker 镜像，临时运行它们，分析哪些文件在临时容器中是被真正使用的，然后生成一个新的、单层的 Docker 镜像——其中所有未使用的文件都会被删除。这样做有两个好处：
镜像被缩小
镜像变得更加安全，因为不需要的工具被删除了（例如 curl 或包管理器）。
请参考我之前文章中的 Docker slim部分以了解更多细节。
使用最小的基础镜像
一个镜像中存储的软件（如 CLI 工具等）越多，攻击面就越大。使用“最小“的镜像是一个很好的实践，它越小越好（无论如何这是一个很好的优势），并且应该包含尽可能少的工具。最小的镜像甚至超越了“优化体积“的镜像（如alpine或<something>:<version>-slim，如 python:3.8-slim）：前者没有任何包管理器。这使攻击者很难加载额外的工具。
最安全的最小基础镜像是SCRATCH，它完全不包含任何东西。只有当你在镜像中放置自包含的二进制文件时，才能用 FROM SCRATCH 启动你的 Dockerfile——这些二进制文件烘焙进了所有的依赖（包括 C-runtimes）。
如果 SCRATCH 不适合你，谷歌的无发行版（distroless）镜像可以是一个很好的选择，特别是当你正在为常见的编程语言（如 Python 或 Node.js）构建应用程序，或者需要一个最小的 Debian 基础镜像时。
不幸的是，最小镜像有几个需要注意的地方：
无发行版的注意事项：
不建议使用谷歌在 gcr.io 上发布的针对特定编程语言的镜像，因为那里只有一个 latest 版本标签，以及 major 版本的标签（例如 python 的“3“，或 Node 的“12“）。你无法控制具体的语言运行时版本（例如是否使用 Python 3.8.3 或 3.8.4 等），这破坏了你的镜像构建的可重用性。
定制（和构建你自己的）无发行版镜像是相当复杂的：你需要熟悉 Bazel 的构建系统并自己构建镜像。
注意：如果你唯一需要的定制是“以非 root 用户身份运行代码”，那么每个无发行版基础镜像中都有一个默认的非 root 用户，详见这里。
最小基础镜像的常规注意事项：
使用最小基础镜像调试容器是很棘手的，因为有用的工具（比如/bin/sh）现在不见了。
对于 Docker，你可以运行第二个调试容器（它确实有一个 shell 和调试工具，例如 alpine:latest），并使其共享你的最小容器的 PID 命名空间，例如通过 docker run -it --rm --pid=container:<minimal-container-id> --cap-add SYS_PTRACE alpine sh
对于 Kubernetes，你可以使用短期容器，见这里的例子
使用受信任的基础镜像
一个受信任的镜像指的是经过某人（要么是你自己的组织，要么是其他人）按照比如说某种安全级别审核的镜像。这对具有高安全要求和规定的受管制行业（银行、航空航天等）来说可能特别重要。
虽然你自己可以通过从头开始建立可信的镜像来完成审计工作，但这是不可取的。因为你（这个镜像的构建者）必须确保所有与审计有关的任务都已完成，并有正确的记录（例如记录镜像中的包列表、执行的 CVE 检查及其结果等等）。这项任务非常繁重。相反，我们建议将这项工作外包出去，使用商业性的“可信注册表“——它提供了一套选定的可信镜像，如 RedHat 的通用基础镜像（UBI）。RedHat 的 UBI 现在也可以在 Docker Hub 上免费获取。
背景知识
在 Docker Hub 上托管的镜像没有经过审计。它们是“按原样“提供的。它们可能是不安全的（甚至包含恶意软件），而且没有人会通知你这一点。因此，使用 Docker Hub 中不安全的基础镜像也会让你的镜像变得不安全。
另外，你不应该把审计和上面提到的 Docker 的内容信任混为一谈！内容信任只确认来源（镜像上传者）的身份，并不会确认与镜像安全性有关的任何事实。
测试你的镜像是否能在降低能力的情况下工作
Linux capabilities 是 Linux 内核的一个特性，它允许你控制一个应用程序可以使用哪些内核特性，例如一个进程是否可以发送信号（如 SIGKILL）、配置网络接口、挂载磁盘，或调试进程等。完整的列表见这里。一般来说，你的应用程序需要的功能越少越好。
启动你的镜像容器的所有人都可以给予（或拿走）这些能力，例如通过调用“docker run --cap-drop=ALL <image>“。默认情况下 Docker 会放弃所有能力，除了这里定义的那些以外。你的应用程序可能不需要所有这些功能。
作为一个最佳实践，你可以尝试启动你的镜像容器，放弃所有能力（使用--cap-drop=ALL），看看它是否仍然正常工作。如果不能，请搞清楚哪些功能是缺失的，并且你是否真的需要它们。然后请记录你的镜像需要哪些功能（以及为什么），这会给运行你镜像的用户带去更多信心。
总结
提升你的镜像安全性并非闲庭信步。你需要花时间来评估和实施每一种实践。本文中的列表应该可以节省你的时间，因为收集和排序重要步骤的工作已经为你做好了。
所幸，提升你的应用程序的安全性是一个迭代过程。你可以从小处着手，每次实施一个步骤。不过你确实需要得到管理层的支持。这有时是很难办的，特别是有时你的经理会对建议有抵触情绪，他们可能倾向于从过去的经验来做推断（“我们，或我们的客户，以前从未被黑过，那么为什么这种问题现在会发生在我们身上？我们需要的是特性！“）。你有几个选择：可以说服你的经理为安全性分配资源。例如，如果你有一个直接接触客户的渠道（你在为其构建软件），那么可以说服他们，让他们要求把安全性作为一个“特性“。或者在你的行业中寻找安全漏洞的报告（例如一个直接的竞争对手受到了影响），以证明黑客攻击确实发生了，甚至你的行业也出了问题，而且它们有严重的（财务）影响。
原文链接：https://www.augmentedmind.de/2022/02/20/optimize-docker-image-security/
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论