作者 | Marius
译者 | 王强
策划 | 闫园园
本文介绍了 12 个优化 Docker 镜像安全性的技巧。每个技巧都解释了底层的攻击载体，以及一个或多个缓解方法。这些技巧包括了避免泄露构建密钥、以非 root 用户身份运行，或如何确保使用最新的依赖和更新等。
1前言
当你是刚开始使用 Docker 的新手时，你很可能会创建不安全的 Docker 镜像，使攻击者很容易借此接管容器，甚至可能接管整个主机，然后渗透到你公司的其他基础设施中。
可以被滥用来接管你的系统的攻击向量有很多，例如：
下面的各个章节讲解了能够优化你的镜像安全性的各种方法。它们是按重要性 / 影响程度排序的，也就是说排名靠前的方法更重要。
2避免泄露构建密钥
构建密钥是只在构建 Docker 镜像时需要的凭证（不是在运行时）。例如，你可能想在你的镜像中包含某个应用程序的一个编译版本，这个应用的源代码是闭源的，并且其 Git 存储库是有访问保护的。在构建镜像时，你需要克隆 Git 存储库（这需要构建密钥，例如该存储库的 SSH 访问密钥），从源代码构建应用程序，然后再删除源代码（和密钥）。
“泄露“构建密钥是说你不小心把这种密钥烘焙到了你的镜像的某个层中。这种情况很严重，因为拉取你的镜像的所有人都可以检索到这些机密。这个问题源于这样一个事实，即 Docker 镜像是以纯粹的加法方式逐层构建的。你在一个层中删除的文件只是被“标记”为已删除，但拉取你镜像的人们仍然可以使用高级工具访问它们。
可以使用以下两种方法之一来避免泄露构建密钥。
多阶段构建
Docker 多阶段构建（官方文档）有许多用例，例如加快你的镜像构建速度，或减少镜像大小。本系列的其他文章会详细介绍其他用例。总之，你也可以通过多阶段构建来避免泄露构建密钥，如下所示：
BuildKit 的密钥
背景知识
如果你使用 docker build 进行构建，可以实际执行构建的后端选项不止一个。其中较新和较快的后端是 BuildKit，你需要在 Linux 上设置环境变量 DOCKER_BUILDKIT=1 来显式启用它。注意，BuildKit 在 Windows/MacOS 的 Docker for Desktop 上是默认启用的。
正如这里的文档所解释的（阅读它们以了解更多细节），BuildKit 构建引擎支持 Dockerfile 中的额外语法。要使用构建密钥，请在你的 Dockerfile 中放入类似下面这样的内容：
RUN --mount=type=secret,id=mysecret,dst=/foobar <command to run>当 RUN 语句被执行时，密钥将对这个构建容器可用，但不会将密钥本身（这里是：/foobar 文件夹）放入构建的镜像中。你需要在运行 docker build 命令时指定密钥的源文件 / 文件夹（位于主机上）的路径，例如：
docker build --secret id=mysecret,src=mysecret.txt -t sometag不过有一点需要注意：你不能通过 docker-compose up –build 来构建需要密钥的镜像，因为 Docker-compose 还不支持用于构建的 –secret 参数，见 GitHub 问题。如果你依赖 docker-compose 的构建，请使用方法 1（多阶段构建）。
题外话：不要推送在开发机上构建的镜像
你应该一直在一个干净的环境中构建和推送镜像（例如 CI/CD 管道），其中构建代理会将你的存储库克隆到一个新目录。
使用本地开发机器进行构建的问题是，你的本地 Git 存储库的“工作树“可能是脏的。例如，它可能包含有开发过程中需要的密钥文件dockerfile生成镜像，例如对中转甚至生产服务器的访问密钥。如果没有通过.dockerignore 排除这些文件，那么 Dockerfile 中的“COPY . .“等语句可能会意外导致这些密钥泄露到最终镜像中。
3以非 root 用户身份运行
默认情况下，当有人通过“docker runyourImage:yourTag“运行你的镜像时，这个容器（以及你在 ENTRYPOINT/CMD 中的程序）会以 root 用户身份运行（在容器和主机上）。这给了一个使用某种漏洞在你的运行容器中获得 shell 权限的攻击者以下权力：
为了避免这种情况，你应该以非 root 用户（你在 docker build 过程中创建的一些用户）的身份运行你的应用程序。在你的 Dockerfile 中的某个地方（通常是在结尾处）放置以下语句：
# Create a new user (including a home-directory, which is optional)RUN useradd --create-home appuser# Switch to this userUSER appuser
Dockerfile 中所有在 USER appuser 语句之后的命令（如 RUN、CMD 或 ENTRYPOINT）都将以这个用户运行。这里有一些需要注意的地方：
4使用最新的基础镜像构建和更新系统包
如果你使用的基础镜像包含了某个真正的 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 build --pull 这可以确保 Docker 在构建镜像之前拉取你的 Dockerfile 中 FROM 语句中提到的镜像的更新。
你还应该注意 Docker 的层缓存机制，它会让你的镜像变得陈旧，因为 RUN 命令的层是缓存的，直到基础镜像维护者发布新版本的基础镜像才刷新。如果你发现基础镜像的发布频率相当低（比如少于一周一次），那么定期（比如每周一次）重建你的镜像并禁用层缓存是个好主意。你可以运行以下命令来做到这一点：
docker build --pull --no-cache 5定期更新第三方依赖
你编写的软件是基于第三方的依赖，也就是由其他人制作的软件。这包括了：
如果你的镜像中的这些依赖过时了dockerfile生成镜像，就会增加攻击面，因为过时的依赖往往有可利用的安全漏洞。
你可以定期使用 SCA（软件组件分析）工具来解决这个问题，比如 Renovate Bot。这些工具（半）自动将你声明的第三方依赖更新为最新版本，例如在你的 Dockerfile、Python 的 requirements.txt、NPM 的 packages.json 等文件中声明的列表。你需要设计你的 CI 管道，使 SCA 工具所做的更改自动触发你的镜像的 re-build。
这种自动触发的镜像重建对于处在只维护模式，但代码仍将被客户在生产环境中使用（客户希望它是安全的）的项目特别有用。在维护期间，你不再开发新的特性，也不会构建新的镜像，因为没有新的提交（由你做出）来触发新的构建。然而，由 SCA 工具做出的提交确实会再次触发镜像构建。
你可以在我的相关博文中找到更多关于 Renovate bot 的细节。
6对你的镜像进行漏洞扫描
即使你执行了上述建议，比如说你的镜像总是使用最新的第三方依赖，它仍然可能是不安全的（例如一个依赖已经被弃用的情况）。在这种情况下，“不安全“意味着一个（或多个）依赖有已知的安全漏洞（在一些 CVE 数据库中注册）。
出于这个原因，你可以给你的 Docker 镜像提供某种工具来扫描所有包含的文件，以找到这种漏洞。这些工具有两种形式：
你显式调用的 CLI 工具（例如在 CI 管道中），比如说 Trivy（OSS，在 CI 管道中非常容易使用，见 Trivy 文档）、Clair（OSS，但设置和使用比 Trivy 更复杂），或 Snyk（通过“docker scan“集成到 Docker CLI 中，见 cheat sheet，但只有有限的免费计划！)
集成到你推送镜像的镜像注册中心的扫描器，如 Harbor（内部使用 Clair 或 Trivy）。还有一些商业产品，如 Anchore。
因为这些扫描器是通用的，它们还试图覆盖一大堆包注册表，所以可能不会特别为你在自己项目中使用的编程语言或包注册表定制。有时，你应该调查你的编程语言生态系统提供了哪些工具。例如，对于 Python 来说就有一个专门针对 Python 包的安全工具。
7扫描你的 Dockerfile 是否违反了最佳实践
有时，问题来自于你在 Dockerfile 中放置的语句，这些语句是不好的实践（但你没有意识到）。为此可以使用诸如 checkov、Conftest、trivy 或 hadolint 等工具，它们是 Dockerfile 的 linter。为了选择正确的工具，你需要查看它的默认规则 / 政策。例如，hadolint 比 checkov 或 conftest 提供的规则更多，因为它是专门针对 Dockerfiles 的。这些工具也是相互补充的，因此在你的 Dockerfiles 上运行多个工具（如 hadolint 和 trivy）确实是有意义的。不过要做好准备，因为你需要维护“忽略文件“，在这个文件中的规则会被忽略——可能是由于误报而有意忽略它们，或者是你准备故意破坏规则。
8不要对 Docker Hub 使用 Docker 内容信任
为了验证你使用的基础镜像确实是由该镜像背后的公司构建和推送的，你可以使用 Docker 内容信任（见官方文档）特性。只需在运行 docker build 或 docker pull 时将 DOCKER_CONTENT_TRUST 环境变量设为“1“即可启用该特性。Docker 守护进程将拒绝提取没有经过发布者签名的镜像。
不幸的是，大约一年前开始社区就不再以这种方式签名镜像了。就连 Docker Inc. 也在 2020 年 12 月停止了签名官方 Docker 镜像，也没有官方解释。问题更大的是如果你使用“docker pull docker:latest”这样的命令，只会下载一个过时很久的镜像。
你可以查看一下镜像签名的其他实现，比如说 cosign（不过我还没试过）。
9扫描你自己的代码是否有安全问题
安全问题通常来源于其他人的代码，也就是流行的第三方依赖。因为它们应用广泛，所以在黑客那里是“有利可图“的。然而，有时是你自己的代码在作怪。例如，你可能不小心实现了 SQL 注入的可能性、堆栈溢出的错误，等等。
为了找到这些问题，你可以使用所谓的 SAST（静态应用安全测试）工具。一方面，有一些特定于编程语言的工具（你必须单独研究），如 Python 的 bandit，或 Java 的 Checkstyle/Spotbugs。另一方面，还有一些支持多种编程语言和框架的工具套件（其中一些是非免费 / 商业的），如 SonarQube（对于它还有 SonarLint IDE 插件）。
在实践中，安全扫描有两种基本方法：
连续（自动）扫描：你创建一个 CI 作业，在每次推送时扫描你的代码。这可以让你的代码安全性保持在一个较高的水平上，但你必须弄清楚如何忽略误报（这是一项持续的维护工作）。如果你使用 GitLab，可能还会发现 GitLab 的免费 SAST 功能很有趣。
不定期（手动）扫描：团队中一些有安全意识的成员在本地运行安全检查，例如每月一次或每次发布前，并手动查看结果。
10使用 docker-slim 来删除不必要的文件
docker-slim 工具可以获取大型 Docker 镜像，临时运行它们，分析哪些文件在临时容器中是被真正使用的，然后生成一个新的、单层的 Docker 镜像——其中所有未使用的文件都会被删除。这样做有两个好处：
———END———
限 时 特 惠：本站每日持续更新海量各大内部创业教程，一年会员只需128元，全站资源免费下载点击查看详情
站 长 微 信：jiumai99
×