Docker 教程

Docker 安全基础

对于任何部署容器化应用的人来说，理解 Docker 的安全性都是重中之重。因为容器共享宿主机的操作系统内核，一个容器中的漏洞有可能危及整个系统。此外，配置不当的 Dockerfile 或不安全的镜像源可能会从一开始就将漏洞引入你的应用中。

在本章中，我们将深入探讨与 Docker 相关的常见安全风险，并为你后续实施最佳实践以减轻这些风险奠定基础。我们将研究与 Docker 守护进程、容器配置和镜像源相关的漏洞，并学习如何开始思考保障 Docker 部署的安全。

1. 常见的 Docker 安全风险

Docker 的安全风险主要来源于几个方面：Docker 守护进程（Daemon）、容器的配置以及所使用的镜像。了解这些风险是构建安全的容器化应用的关键。

1.1 Docker 守护进程漏洞

管理所有容器的 Docker 守护进程（dockerd）通常以 root 权限运行。如果它被攻破，攻击者可能会获得对宿主机系统的完全控制权。

  • 风险：利用 Docker 守护进程中的已知漏洞。
  • 示例：旧版本的 Docker 存在已知漏洞，允许攻击者“逃逸”出容器并获得宿主机的 root 访问权限。一个假设的场景是：生产服务器上运行着未打补丁的 Docker 守护进程，攻击者利用公开的漏洞利用代码，获得了对服务器的完全控制。
  • 防范措施：
    • 保持 Docker 守护进程更新到最新的安全补丁。
    • 定期审计 Docker 守护进程的配置（例如，不要将 Docker API 暴露在公网上）。
  • 真实案例：2019 年，Docker 使用的容器运行时 runc 中爆出了一个严重的容器逃逸漏洞（CVE-2019-5736）。更新 runc 和 Docker 是解决这个关键问题的唯一途径。

1.2 容器配置问题

配置不当的容器会产生安全漏洞。这些配置包括不安全的默认设置、暴露的端口以及过高的权限。

  • 风险：运行带有不必要权限或随意暴露端口的容器。
  • 示例 1：特权容器 (Privileged Containers)。以特权模式（--privileged）运行容器会赋予它几乎所有宿主机的能力（Capabilities）。这极其危险，因为容器内的任何妥协都会立即转化为对宿主机的妥协。设想一个场景：一个运行着脆弱 Web 应用的特权容器被攻破；攻击者随后可以利用容器的特权来访问和修改宿主机的系统文件。
  • 示例 2：暴露的端口。如果没有适当的防火墙规则，暴露端口可能会允许未经授权的人访问容器内部运行的服务。假设一个数据库容器在没有任何身份验证机制的情况下，将 3306 端口暴露给了公网。攻击者可以直接连接到数据库，并可能窃取或破坏数据。
  • 示例 3：缺少资源限制。未能设置资源限制（CPU、内存）可能导致拒绝服务（DoS）攻击，即一个容器消耗了所有可用资源，导致其他容器甚至宿主机系统饿死。想象一下，容器内一个编写糟糕的应用存在内存泄漏。如果没有资源限制，这个容器可能会耗尽宿主机的所有内存，导致整个系统崩溃。
  • 防范措施：
    • 除非绝对必要，否则避免以特权模式运行容器。如果需要特定权限，请使用 --cap-add 和 --cap-drop 来精确授予必要的 Capabilities。
    • 小心管理端口映射，并使用防火墙（如 iptables 或云安全组）限制对暴露端口的访问。
    • 为容器设置资源限制（CPU、内存），以防止资源耗尽。
  • 真实案例：某公司部署了一个容器化应用，使用了默认且极易猜测的 root 密码。攻击者获得了访问权限，并以此为跳板，横向移动到了网络上的其他系统。

1.3 镜像相关的风险

镜像是容器的基石。与镜像相关的安全风险包括使用不受信任的基础镜像、镜像层中存在漏洞，以及镜像中硬编码了机密信息。

  • 风险：使用存在已知漏洞或包含敏感信息的镜像。
  • 示例 1：脆弱的基础镜像。基础镜像通常包含带有已知漏洞的过时软件包。如果你在脆弱的基础镜像之上构建应用，你的应用就会继承这些漏洞。例如，使用存在未修复安全缺陷的过时 Ubuntu 镜像，会使你的应用面临这些缺陷的风险。
  • 示例 2：镜像中的机密信息 (Secrets)。在 Dockerfile 或应用代码中意外包含了 API 密钥、密码或 SSH 密钥等敏感信息，然后构建镜像，这会将这些机密暴露给任何有权访问该镜像的人。假设开发人员将 AWS API 密钥硬编码到他们的代码中并构建了 Docker 镜像。如果该镜像被推送到公共镜像仓库，任何人都可以提取 API 密钥并访问该公司的 AWS 资源。
  • 示例 3：恶意镜像。从不受信任的来源下载和使用镜像可能会将恶意软件或后门引入你的环境。想象一个开发人员不知不觉地从未知仓库拉取了一个看似合法的镜像。这个镜像可能包含窃取数据或破坏宿主机系统的恶意代码。
  • 防范措施：
    • 使用官方和受信任的基础镜像。
    • 定期使用 Clair、Trivy 或 Anchore 等工具扫描镜像漏洞。
    • 绝不将机密信息嵌入镜像中。应使用环境变量或 Docker Secrets 代替。
    • 实施 Docker 内容信任（Docker Content Trust, DCT）来验证镜像的完整性和真实性。
  • 真实案例：2018 年，一项对 Docker Hub 的分析发现，大量镜像包含恶意软件、加密货币矿机和其他恶意软件。

1.4 内核级别的利用

由于容器共享宿主机的内核，内核中的漏洞可能会影响该宿主机上运行的所有容器。

  • 风险：内核漏洞影响多个容器。
  • 示例：假设在 Linux 内核中发现了一个零日（Zero-day）漏洞。攻击者可以利用此漏洞获得对宿主机操作系统的控制权，从而控制在其上运行的所有容器。
  • 防范措施：
    • 保持宿主机操作系统内核更新到最新的安全补丁。
    • 考虑使用专门为安全性设计的容器优化操作系统（如 Flatcar Container Linux 或 Bottlerocket）。
  • 真实案例：脏牛（Dirty COW, CVE-2016-5195）是一个关键的 Linux 内核漏洞，允许提权。及时给内核打补丁是降低此风险的必要条件。

1.5 网络安全隐患

容器通过网络相互通信并与外界通信。配置不当的网络可能导致安全漏洞。

  • 风险：未经授权访问容器网络。
  • 示例 1：桥接网络 (Bridge Network) 漏洞。当容器连接到默认的桥接网络时，它们之间的流量通常是未加密的。获得一个容器访问权限的攻击者可能会窃听或拦截同一网络上其他容器之间的流量。
  • 示例 2：主机网络 (Host Network) 漏洞。使用 host 网络模式会绕过 Docker 的网络隔离，将容器直接暴露在宿主机的网络接口上。虽然这可以提高性能，但也意味着容器容易受到针对宿主机的基于网络的攻击。如果宿主机受损，容器也会受损。
  • 示例 3：缺乏网络隔离 (Network Segmentation)。如果没有适当的网络隔离，所有容器可能都在同一个网络上，这扩大了攻击面。如果一个容器被攻破，攻击者可以轻易访问其他容器。设想 Web 应用和数据库运行在同一个网络上，没有任何防火墙规则。如果 Web 应用被攻破，攻击者可以直接连接数据库。
  • 防范措施：
    • 使用自定义的 Docker 网络（用户自定义桥接网络）来隔离不同组的容器。
    • 避免使用 host 网络模式，除非绝对必要。
    • 对于跨主机的敏感流量，使用加密的 Overlay 网络（如使用 Docker Swarm 时配合 IPSec）。
  • 真实案例：一家公司遭遇了数据泄露，起因是攻击者利用了 Web 应用容器中的漏洞，然后利用受损的容器访问了同一网络上的数据库容器。

2. 识别和应对风险的最佳实践总结

识别和应对 Docker 安全风险是一个持续的过程，需要结合主动预防和被动响应措施。

  • 定期更新 Docker：保持 Docker 处于最新状态，确保你拥有最新的安全补丁和功能。
  • 使用精简的基础镜像：较小的镜像可以减少攻击面（即包含的无用软件包越少，潜在的漏洞就越少）。Alpine Linux 是构建精简基础镜像的热门选择。
  • 扫描镜像漏洞：在部署镜像之前，使用 Trivy 或 Clair 等工具扫描镜像中的已知漏洞。
  • 实施最小权限原则：尽量不要以 root 用户身份在容器内运行应用。在 Dockerfile 中创建专用用户和组，并仅赋予运行应用所需的最低权限。
  • 使用资源限制：设置 CPU 和内存限制，防止资源耗尽和 DoS 攻击。
  • 安全的网络配置：使用 Docker 网络隔离容器，并限制不必要的端口暴露。
  • 机密管理 (Secrets Management)：避免在镜像中嵌入密码或密钥。使用环境变量（对于非极度敏感的数据）或专用的机密管理工具（如 HashiCorp Vault、Docker Secrets 或云提供商的 KMS）来管理敏感信息。
  • 启用 Docker 内容信任 (DCT)：开启 DCT 以强制验证镜像签名，确保你拉取的是由受信任发布者签名的原始镜像。
  • 监控和日志记录：实施健壮的监控和日志记录（如收集容器日志和 Docker daemon 日志），以便检测和响应安全事件。