12 个优化 Docker 镜像安全性的技巧( 四 ) _Docker

为了找到这些问题，你可以使用所谓的 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 上免费获取。