24、Docker 安全与容器限制全解析

Docker 安全与容器限制全解析

在使用 Docker 时，安全是一个至关重要的方面。以下将详细介绍一系列 Docker 安全措施和容器限制的相关内容。

容器安全基础措施

为了保障容器的安全，可采取以下措施：
- 运行 SELinux ：为容器运行具有特定类型的 SELinux，这是一种有效的安全措施，但需要大量工作，并且仅在使用 devicemapper 存储驱动时才可行。
- 应用进程数量限制 ：对容器用户应用 ulimit 限制进程数量，这能消除将 fork 炸弹用作拒绝服务（DoS）攻击的威胁，但使用起来比听起来更复杂。
- 加密内部通信 ：对内部通信进行加密，使攻击者更难篡改数据。

此外，还应定期对系统进行审计，确保一切都是最新的，并且没有容器占用过多资源。

按主机隔离容器

在多租户环境中，为多个用户运行容器时，应确保每个用户的容器放在单独的 Docker 主机上。这样做虽然效率不如用户共享主机，会导致更多的虚拟机（VM）或物理机，但对安全至关重要，可防止容器逃逸，避免用户访问其他用户的容器或数据。

同样，如果有处理或存储敏感信息的容器，应将其与处理不太敏感信息的容器分开，尤其要远离直接面向终端用户的应用程序容器。例如，处理信用卡详细信息的容器应与运行 Node.js 前端的容器分开。

容器隔离和使用 VM 还能提供额外的 DoS 攻击防护，因为用户无法独占主机内存，从而避免使其他用户的容器资源不足。

在中短期内，绝大多数容器部署将涉及 VM。虽然这不是理想情况，但可以将容器的效率与 VM 的安全性结合起来。

应用更新

快速对运行中的系统应用更新对于维护安全至关重要，特别是当常见实用程序和框架中披露漏洞时。更新容器化系统的大致步骤如下：
1. 识别需要更新的镜像 ：包括基础镜像和所有依赖镜像。可以使用以下命令获取所有运行中镜像的 ID：

$ docker inspect -f "{{.Image}}" $(docker ps -q)

还可以使用更多 shell 技巧获取更多信息：

$ docker images --no-trunc | \
    grep $(docker inspect -f "-e {{.Image}}" $(docker ps -q))

要获取所有镜像及其基础或中间镜像的列表：

$ docker inspect -f "{{.Image}}" $(docker ps -q) | \
    xargs -L 1 docker history -q

2. 获取或创建基础镜像的更新版本 ：将更新后的版本推送到注册表或下载站点。
3. 构建依赖镜像 ：对每个依赖镜像使用 docker build 命令并加上 --no-cache 参数，然后再次推送这些镜像。
4. 拉取最新镜像 ：在每个 Docker 主机上运行 docker pull 以确保拥有最新镜像。
5. 重启容器 ：在每个 Docker 主机上重启容器。
6. 移除旧镜像 ：确定一切正常后，从主机上移除旧镜像，如果可能，也从注册表中移除。

如果使用 Docker Hub 构建镜像，可以设置存储库链接，当任何链接的镜像发生更改时，将触发镜像的构建。

镜像标签

在构建镜像时大量使用标签可以使识别镜像及其内容变得更加容易。可以在 Dockerfile 中添加标签：

FROM debian
LABEL version 1.0
LABEL description "A test image for describing labels"

也可以在运行时为容器添加标签：

$ docker run -d --name label-test \
                      -l group=a debian sleep 100
$ docker inspect -f '{{json .Config.Labels}}' label-test

这在运行时处理某些事件时很有用，例如动态将容器分配到负载均衡器组。

避免使用不支持的驱动

尽管 Docker 还很年轻，但已经经历了几个发展阶段，一些功能已被弃用或不再维护。依赖这些功能存在安全风险，因为它们不会像 Docker 的其他部分那样受到关注和更新。特别是，不要使用旧版 LXC 执行驱动，默认情况下该驱动是关闭的，但应检查守护进程是否使用 -e lxc 参数运行。

存储驱动也是一个主要的发展和变化领域，目前 Docker 正在从 AUFS 转向 Overlay 作为首选存储驱动，AUFS 驱动正在从内核中移除，不再进行开发，建议 AUFS 用户在不久的将来迁移到 Overlay。

镜像来源验证

为了安全地使用镜像，需要确保其来源，即知道它们来自哪里以及谁创建了它们。要确保获得的是原始开发者测试的完全相同的镜像，并且在存储或传输过程中没有人篡改它。如果无法验证这一点，镜像可能已损坏，甚至更糟的是，可能已被恶意替换。

建立软件或数据来源的主要工具是安全哈希。安全哈希就像数据的指纹，是一个相对较小的字符串，对于给定的数据是唯一的。任何数据更改都会导致哈希值改变。常见的安全哈希算法有 SHA（有多个变体）和 MD5（存在根本问题，应避免使用）。

通过加密签名和公钥/私钥对，可以进一步验证工件发布者的身份。如果发布者使用其私钥对工件进行签名，任何接收者都可以使用发布者的公钥检查签名，从而验证工件来自发布者且未被篡改。

在 Docker 中，安全哈希被称为摘要（digest），是文件系统层或清单（manifest）的 SHA256 哈希，清单是描述 Docker 镜像组成部分的元数据文件。如果能验证清单未被篡改，就可以安全地下载和信任所有层，即使通过不可信的通道（如 HTTP）。

Docker 内容信任

Docker 在 1.8 版本引入了内容信任机制，允许发布者对其内容进行签名，完善了可信分发机制。当用户从存储库中拉取镜像时，会收到包含发布者公钥的证书，从而验证镜像来自发布者。

启用内容信任后，Docker 引擎只会处理已签名的镜像，拒绝运行签名或摘要不匹配的镜像。例如：

$ export DOCKER_CONTENT_TRUST=1 
$ docker pull debian:wheezy
$ docker pull amouat/identidock:unsigned

可以看到，官方签名的 Debian 镜像可以成功拉取，而未签名的镜像则被拒绝。

推送签名镜像也相对简单：

$ docker push amouat/identidock:newest

首次使用内容信任推送到存储库时，Docker 会创建新的根签名密钥和标签密钥。要特别注意保护根密钥的安全，因为如果丢失，存储库的所有用户在不手动移除旧证书的情况下将无法拉取新镜像或更新现有镜像。

可以使用内容信任下载镜像：

$ docker rmi amouat/identidock:newest
$ docker pull amouat/identidock:newest

如果之前没有从给定存储库下载过镜像，Docker 会首先通过 HTTPS 获取发布者的证书，后续拉取可以使用现有证书进行验证。

备份签名密钥

Docker 会对所有密钥进行静态加密，并确保私有材料不会写入磁盘。由于密钥非常重要，建议将其备份到两个加密的 USB 存储棒上，并保存在安全的位置。可以使用以下命令创建包含密钥的 TAR 文件：

$ umask 077
$ tar -zcvf private_keys_backup.tar.gz \
               ~/.docker/trust/private
$ umask 022

根密钥仅在创建或撤销密钥时需要，不使用时应离线存储。

标签密钥管理

每个发布者拥有的存储库都会生成一个标签密钥，该密钥由根密钥签名，任何拥有发布者证书的用户都可以验证。标签密钥可以在组织内共享，用于对该存储库的任何镜像进行签名。生成标签密钥后，根密钥应离线安全存储。

如果标签密钥被泄露，仍然可以通过旋转标签密钥来恢复，这个过程对用户是透明的，也可以主动进行以防止未检测到的密钥泄露。

内容信任还提供了新鲜度保证，以防止重放攻击。重放攻击是指攻击者用以前有效的工件替换当前工件，例如用旧的、已知有漏洞的版本替换二进制文件。为避免这种情况，内容信任使用与每个存储库关联的时间戳密钥对存储库的元数据进行签名，元数据有较短的过期日期，需要经常重新签名。Docker 客户端在下载镜像前验证元数据未过期，就可以确保收到的是最新的镜像。时间戳密钥由 Docker Hub 管理，发布者无需进行任何交互。

一个存储库可以包含签名和未签名的镜像，如果启用了内容信任并想下载未签名的镜像，可以使用 --disable-content-trust 标志：

$ docker pull amouat/identidock:unsigned
$ docker pull --disable-content-trust amouat/identidock:unsigned

Notary 项目

Docker Notary 项目是一个通用的服务器 - 客户端框架，用于以可信和安全的方式发布和访问内容。它基于 The Update Framework 规范，为内容分发和更新提供了安全设计。

Docker 的内容信任框架本质上是 Notary 与 Docker API 的集成。通过运行注册表和 Notary 服务器，组织可以为用户提供可信镜像。Notary 设计为独立的，可用于广泛的场景。

一个主要的使用场景是提高常见的 curl | sh 方法的安全性和可信度。例如，当前 Docker 安装说明使用的 curl -sSL https://get.docker.com/ | sh 命令，如果下载过程在服务器端或传输过程中被篡改，攻击者可以在受害者的计算机上运行任意命令。使用 Notary 的等效示例如下：

$ curl http://get.docker.com/ | notary verify docker.com/scripts v1 | sh

调用 notary 会将脚本的校验和与 Notary 中 docker.com 的可信集合中的校验和进行比较，如果匹配，则验证脚本确实来自 docker.com 且未被篡改；如果不匹配， notary 会退出，不会将数据传递给 sh 。值得注意的是，脚本本身可以通过不安全的通道（如 HTTP）传输，因为如果脚本在传输过程中被更改，校验和会改变， notary 会抛出错误。

即使使用未签名的镜像，也可以通过按摘要拉取镜像来验证镜像，而不是按名称和标签拉取。例如：

$ docker pull debian@sha256:f43366bc755696485050ce14e1429c481b6f0ca04505c4a3093d\
fdb4fafb899e

这样可以确保总是拉取完全相同的镜像（如果存在）。如果摘要可以通过某种方式安全传输和验证（例如通过受信任方的 PGP 签名电子邮件发送），就可以保证镜像的真实性。即使启用了内容信任，仍然可以按摘要拉取镜像。

综上所述，通过采取上述一系列安全措施和管理方法，可以有效提高 Docker 环境的安全性，确保容器化应用的稳定运行。

Docker 安全与容器限制全解析

安全措施总结与对比

为了更清晰地了解各项 Docker 安全措施，下面通过表格进行总结对比：
| 安全措施 | 优点 | 缺点 | 适用场景 |
| — | — | — | — |
| 运行 SELinux | 有效增强容器安全 | 工作量大，仅适用于 devicemapper 存储驱动 | 对安全要求极高的企业级应用 |
| 应用进程数量限制 | 防止 DoS 攻击 | 使用较复杂 | 多租户环境，防止单个用户过度占用资源 |
| 加密内部通信 | 防止数据篡改 | 增加通信开销 | 涉及敏感数据传输的场景 |
| 按主机隔离容器 | 防止容器逃逸，保护用户数据 | 资源利用率低 | 多租户或处理敏感信息的场景 |
| 应用更新 | 及时修复漏洞 | 操作步骤复杂，可能导致停机 | 发现软件漏洞时 |
| 镜像标签 | 方便识别镜像 | 需额外管理标签 | 镜像数量多，需要分类管理的场景 |
| 避免使用不支持的驱动 | 降低安全风险 | 可能需要迁移驱动 | 旧版本 Docker 或使用不支持驱动的环境 |
| Docker 内容信任 | 确保镜像来源和完整性 | 需要管理密钥，首次使用较复杂 | 对镜像安全性要求高的场景 |
| Notary 项目 | 提高内容分发安全性 | 需要额外部署 Notary 服务器 | 对内容分发安全有严格要求的场景 |

安全措施实施流程

下面通过 mermaid 流程图展示 Docker 安全措施的整体实施流程：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([开始]):::startend --> B{是否多租户环境}:::decision
    B -->|是| C(按主机隔离容器):::process
    B -->|否| D(正常部署容器):::process
    C --> E(应用基础安全措施):::process
    D --> E
    E --> F(定期审计系统):::process
    F --> G{是否有漏洞披露}:::decision
    G -->|是| H(应用更新):::process
    G -->|否| I(继续运行):::process
    H --> J(验证更新效果):::process
    J --> K{更新是否成功}:::decision
    K -->|是| I
    K -->|否| H
    I --> L{是否需要管理镜像}:::decision
    L -->|是| M(使用镜像标签):::process
    L -->|否| N(继续运行):::process
    M --> N
    N --> O{是否关注镜像来源安全}:::decision
    O -->|是| P(启用 Docker 内容信任):::process
    O -->|否| Q(继续运行):::process
    P --> R(管理签名密钥):::process
    R --> S(按规则拉取和推送镜像):::process
    S --> Q
    Q --> T{是否需要提高内容分发安全}:::decision
    T -->|是| U(使用 Notary 项目):::process
    T -->|否| V([结束]):::startend
    U --> V

常见问题及解决方案

在实施上述 Docker 安全措施过程中，可能会遇到一些常见问题，下面为大家提供相应的解决方案：
1. 更新镜像时遇到问题
- 问题描述 ：在更新镜像时，可能会出现拉取失败、构建失败等问题。
- 解决方案 ：
- 检查网络连接是否正常，确保可以访问镜像仓库。
- 检查镜像仓库的状态，是否存在服务中断等问题。
- 查看 docker build 命令的输出信息，根据错误提示进行修复，如缺少依赖项等。
2. 密钥管理问题
- 问题描述 ：忘记密钥密码、密钥丢失等。
- 解决方案 ：
- 对于忘记密钥密码的情况，如果有备份，可以尝试使用备份密钥；如果没有备份，可能需要重新生成密钥，但这可能会影响已有的签名镜像。
- 对于密钥丢失的情况，及时按照安全流程重新生成密钥，并通知相关用户更新证书。
3. Notary 服务器部署问题
- 问题描述 ：部署 Notary 服务器时遇到配置错误、服务无法启动等问题。
- 解决方案 ：
- 仔细检查 Notary 服务器的配置文件，确保各项参数设置正确。
- 查看服务器日志文件，根据错误信息进行排查和修复。

未来发展趋势

随着 Docker 技术的不断发展，其安全方面也会有一些新的发展趋势：
- 自动化安全管理 ：未来可能会出现更多自动化工具，帮助用户更轻松地管理 Docker 安全，如自动检测漏洞、自动更新镜像等。
- 与云原生安全融合 ：随着云原生技术的发展，Docker 安全将与云原生安全更加紧密地融合，提供更全面的安全防护。
- 零信任架构的应用 ：零信任架构强调“默认不信任，始终验证”，未来 Docker 可能会更多地应用零信任架构，进一步提高安全级别。

总结

Docker 安全是一个复杂而重要的领域，涉及多个方面的措施和技术。通过合理运用本文介绍的安全措施，如按主机隔离容器、应用更新、使用镜像标签、启用 Docker 内容信任和 Notary 项目等，可以有效提高 Docker 环境的安全性，保护容器化应用的稳定运行。同时，要关注常见问题的解决方案和未来发展趋势，不断提升 Docker 安全管理水平。在实际应用中，应根据具体的业务需求和安全要求，选择合适的安全措施进行实施。