Docker容器化2023版本——Docker中的安全性

良好的安全性是建立在层级和深度防御的基础上的。Docker支持所有主要的Linux安全技术，以及许多自己的安全技术。

在本章中，我们将探讨一些使容器运行非常安全的技术。

本章的大部分内容将与Linux有关。然而，Docker安全技术部分是跨平台的，同样适用于Linux和Windows。

Docker中的安全性 - 简介

安全性是建立在层级之上的，更多的层级意味着更安全。幸运的是，我们可以为Docker应用许多层级的安全性。图15.1显示了本章中我们将介绍的一些与安全性相关的技术。

在Linux上，Docker利用了大多数常见的Linux安全性和工作负载隔离技术。这些技术包括命名空间、控制组、功能、强制访问控制（MAC）和seccomp。对于每一项技术，Docker都提供了"合理的默认值"，以实现适度安全的开箱即用体验。然而，您可以根据自己的具体需求自定义每一项技术。

Docker还添加了一些自己的出色安全技术。关于Docker安全技术的最好之处之一是它们非常容易使用。

Docker Swarm模式默认是安全的。您可以从中获得以下所有内容：加密节点ID、相互认证、自动CA配置、自动证书轮换、加密集群存储、加密网络等等。

镜像漏洞扫描分析镜像，检测已知的漏洞，并提供详细的报告和修复方法。

Docker Content Trust（DCT）允许我们签名自己的镜像，并验证我们使用的镜像的完整性和发布者。

Docker秘密允许我们安全地与应用程序共享敏感数据。它们存储在加密的集群存储中，在网络上传输时进行加密，在使用时存储在内存文件系统中，并采用最小权限模型。

还有其他技术存在，但需要知道的重要事情是，Docker可以使用主要的Linux安全技术，同时提供其自己丰富且不断增长的安全技术。尽管Linux安全技术往往较为复杂，但Docker的本地安全技术通常较为简单。

Docker中的安全性 - 深入探讨

当Docker决定将安全性融入到平台中时，他们决定使其简单易用。他们知道，如果安全性很难，人们就不会使用它。因此，Docker平台提供的大多数安全技术都很容易使用。它们还提供了合理的默认设置，这意味着我们可以零成本获得一个相当安全的平台。当然，这些默认设置并不完美，但它们是一个很好的起点。

我们将按以下方式组织本章的其余部分：

• Linux安全技术
• 命名空间
• 控制组
• 功能
• 强制访问控制
• seccomp
• Docker平台安全技术
• Swarm模式
• 漏洞扫描
• Docker内容信任
• Docker秘密

Linux安全技术

所有良好的容器平台都使用命名空间和cgroups来构建容器。最佳的容器平台还与其他Linux安全技术集成，例如功能、强制访问控制系统（如SELinux和AppArmor）以及seccomp。不出所料，Docker与它们都集成在一起。

在本节中，我们将简要介绍Docker使用的一些主要Linux安全技术。我们不会详细介绍，因为我希望本章的重点是Docker添加的安全技术。

Namespaces

内核命名空间是构建容器的主要技术。

它们虚拟化操作系统构造，如进程树和文件系统，就像虚拟化程序虚拟化物理资源，如CPU和磁盘一样。在虚拟机（VM）模型中，虚拟化程序通过组合虚拟CPU、虚拟磁盘和虚拟网络适配器等组件来创建虚拟机。每个虚拟机看起来、感觉和操作方式都与物理机器完全相同。在容器模型中，命名空间通过组合虚拟进程树、虚拟文件系统和虚拟网络接口等组件来创建虚拟操作系统。每个虚拟操作系统都被称为容器，看起来、感觉和操作方式都与常规操作系统完全相同。

这个虚拟操作系统（"容器"）让我们能够做一些非常酷的事情，比如在同一台主机上运行多个Web服务器而不会出现端口冲突。它还允许我们在同一台主机上运行多个应用程序，而不会因它们争夺共享配置文件和共享库而产生冲突。

以下是一些快速示例：

• 命名空间允许我们在单个主机上的单个操作系统上运行多个Web服务器，每个Web服务器都在端口443上运行。为了实现这一点，我们在每个Web服务器内部运行它自己的网络命名空间。这是因为每个网络命名空间都有自己的IP地址和完整的端口范围。您可能需要将每个端口映射到Docker主机上的不同端口，但每个端口都可以在不需要重新编写或重新配置以使用不同端口的情况下运行。
• 我们可以运行多个应用程序，每个应用程序都有自己的共享库版本和配置文件。为了实现这一点，我们在每个应用程序内部运行它自己的挂载命名空间。这是因为每个挂载命名空间都可以拥有其自己的独立副本，比如/etc、/var或/dev等目录。

图15.2显示了在单个主机上运行两个Web服务器应用程序的高级示例，它们都使用端口443。每个Web服务器应用程序都在自己的网络命名空间内运行。

直接使用命名空间是困难的。幸运的是，Docker为我们做了所有繁重的工作，并将所有复杂性隐藏在docker run命令和易于使用的API后面。

Linux上的Docker目前使用以下内核命名空间：

• 进程ID（pid）
• 网络（net）
• 文件系统/挂载（mnt）
• 进程间通信（ipc）
• 用户（user）
• UTS 我们将在一会儿解释每个命名空间的作用。然而，最重要的理解是，容器是命名空间的有组织集合。例如，每个容器都有自己的pid、net、mnt、ipc、uts和可能的用户命名空间。实际上，这些命名空间的有组织集合就是我们所谓的"容器"。图15.3显示了单个Linux主机运行两个容器。主机有自己的一组命名空间，我们称之为"根命名空间"。每个容器都有自己的一组隔离的命名空间。

让我们简要地看一下Docker如何使用每个命名空间：

• 进程ID命名空间：Docker使用pid命名空间为每个容器提供隔离的进程树。这意味着每个容器都有自己的PID 1。这还意味着一个容器无法看到或访问其他容器中运行的进程。容器也无法看到或访问主机上运行的进程。
• 网络命名空间：Docker使用net命名空间为每个容器提供独立的网络堆栈。这个堆栈包括接口、IP地址、端口范围和路由表。例如，每个容器都有自己的eth0接口，具有自己独特的IP和端口范围。
• 挂载命名空间：每个容器都有自己独特的隔离根（/）文件系统。这意味着每个容器可以有自己的/etc、/var、/dev和其他重要的文件系统结构。容器内的进程无法访问主机或其他容器上的文件系统，它们只能看到和访问自己隔离的文件系统。
• 进程间通信命名空间：Docker使用ipc命名空间来实现容器内的共享内存访问。它还将容器与容器外的共享内存隔离开来。
• 用户命名空间：Docker允许您使用用户命名空间将容器内的用户映射到Linux主机上的不同用户。一个常见的示例是将容器的根用户映射到Linux主机上的非根用户。
• UTS命名空间：Docker使用uts命名空间为每个容器提供自己的主机名。

请记住，一个容器是一组看起来像常规操作系统的命名空间，而Docker使其非常容易使用。

控制组

如果说命名空间关注的是隔离，那么控制组（cgroups）关注的是限制。

将容器类比为酒店中的房间。尽管每个房间可能看起来是隔离的，但它们共享一组共同的基础设施资源，例如供水、电力供应、共用游泳池、共用健身房、共用电梯、共用早餐吧... Cgroups让我们可以设置限制，以确保（按照酒店的类比）没有单个容器可以使用所有的水或吃掉早餐吧上的所有食物。

在现实世界中，容器之间是隔离的，但它们都共享一组共同的资源，例如CPU、内存、网络和磁盘I/O。Cgroups让我们可以设置限制，以防止单个容器占用所有资源并引发拒绝服务（DoS）攻击。

能力

在Linux系统中以root身份运行容器是一个不好的主意------root是Linux系统中最强大的用户帐户，因此非常危险。然而，将容器仅仅以普通非root用户身份运行也不是那么简单。例如，在大多数Linux系统上，非root用户往往无能为力，几乎无法做任何有用的事情。所需的是一种方法，可以挑选并选择容器需要的特定root权限，以便运行。

这就是能力的用武之地！

在底层，Linux root用户是一长串能力的组合。其中一些能力包括：

• CAP_CHOWN：允许您更改文件所有者。
• CAP_NET_BIND_SERVICE：允许您绑定套接字到低编号的网络端口。
• CAP_SETUID：允许您提升进程的权限级别。
• CAP_SYS_BOOT：允许您重新启动系统。 等等，列表还很长。

Docker使用能力，以便您可以以root身份运行容器，但剥夺掉不需要的所有能力。例如，如果一个容器唯一需要的root能力是绑定到低编号的网络端口的能力，我们会启动一个容器，删除所有root能力，然后只添加CAP_NET_BIND_SERVICE能力。

这是实施最小特权的一个很好的例子------我们获得了一个只具有我们实际需要的能力的容器。Docker还会强制限制容器无法重新添加已删除的能力。

虽然这很好，但配置正确的能力集需要大量的工作和测试。

强制访问控制系统（MAC）

Docker与主要的Linux强制访问控制（MAC）技术，如AppArmor和SELinux，配合使用。

根据您使用的Linux发行版，Docker会为所有新容器应用默认的策略配置文件。根据Docker的文档，这些默认配置文件是"适度保护但提供广泛的应用兼容性"。

Docker还允许您启动没有策略的容器，并提供了自定义策略以满足特定要求的能力。这非常强大，但也可能非常复杂。

seccomp

Docker使用seccomp来限制容器对主机内核的系统调用。在撰写本文时，Docker的默认seccomp配置文件禁用了44个系统调用。现代Linux系统有超过300个系统调用。

根据Docker的安全理念，所有新容器都会获得一个默认的seccomp配置文件，其中包含明智的默认设置。与MAC策略一样，默认的seccomp策略旨在提供适度的安全性，同时不影响应用程序的兼容性。

与前面提到的许多技术一样，seccomp非常强大。然而，Linux的系统调用表很长，配置适当的seccomp策略可能非常复杂。

关于Linux安全技术的最后思考

Docker支持大多数重要的Linux安全技术，并提供明智的默认设置，以增加安全性但不会过于限制。图15.4展示了这些技术如何帮助构建深度防御的

其中一些技术可能会很复杂，因为它们需要对Linux内核的工作方式有深入的了解才能自定义。它们的配置变得越来越简单，许多平台，包括Docker，在出厂时都带有良好的默认配置，是一个很好的起点。

Docker安全技术

让我们看一下Docker提供的一些主要安全技术。

Swarm Mode中的安全性

Docker Swarm允许您集群多个Docker主机并以声明性方式部署应用程序。每个Swarm包括管理节点和工作节点，可以是Linux或Windows。管理节点托管控制平面，负责配置集群并分派工作任务。工作节点是运行应用程序容器的节点。

如预期的那样，Swarm模式包括许多安全功能，这些功能在默认情况下启用并具有合理的默认值。这些功能包括：

• 密码学节点ID
• 用于互相认证的TLS
• 安全的加入令牌
• 具有自动证书轮换的CA配置
• 加密的集群存储
• 加密网络

让我们逐步介绍构建安全Swarm并配置一些安全方面的过程。

要完整地执行所有示例，您需要三个Docker主机。示例使用三个名为"mgr1"、"mgr2"和"wrk1"的主机。这三个主机之间存在网络连接，它们可以通过名称相互ping通。

配置安全的Swarm

从您希望成为新Swarm中的第一个管理节点的节点运行以下命令。我们将从mgr1运行示例。

$ docker swarm init

Swarm initialized: current node (7xam...662z) is now a manager.
To add a worker to this swarm, run the following command:

    docker swarm join --token \
     SWMTKN-1-1dmtwu...r17stb-ehp8g...hw738q 172.31.5.251:2377

To add a manager to this swarm, run 'docker swarm join-token manager'
and follow the instructions.

就是这样！这确实是配置安全Swarm所需做的一切。

mgr1被配置为Swarm的第一个管理节点，同时也是根证书颁发机构（CA）。Swarm本身已经获得了一个加密的集群ID。mgr1已经为自己颁发了一个客户端证书，用于标识自己是一个管理节点，证书轮换已经配置为默认值90天，并配置了一个集群数据库并进行了加密。一组安全令牌也已创建，以便可以安全地加入其他管理节点和工作节点。所有这些都可以通过单个命令完成！

图15.5展示了实验室的当前状态。您的实验室中可能有一些不同的细节。

让我们将mgr2加入作为额外的管理节点。

加入新的管理节点到一个Swarm是一个两步骤的过程。第一步是提取令牌。第二步运行docker swarm join命令在我们要添加的节点上。只要我们将管理节点加入令牌作为命令的一部分，mgr2将加入Swarm作为一个管理节点。

从mgr1运行以下命令来提取管理节点加入令牌。

$ docker swarm join-token manager
To add a manager to this swarm, run the following command:

    docker swarm join --token \
    SWMTKN-1-1dmtwu...r17stb-2axi5...8p7glz \
    172.31.5.251:2377

输出提供了在节点上运行的确切命令，以将它们加入作为管理节点。在您的实验室中，加入令牌和IP地址将会不同。

加入命令的格式如下：

docker swarm join --token : 令牌的格式如下：

SWMTKN-1-- 复制该命令并在"mgr2"上运行：

$ docker swarm join --token SWMTKN-1-1dmtwu...r17stb-2axi5...8p7glz \
> 172.31.5.251:2377

This node joined a swarm as a manager.

mgr2已加入Swarm作为附加的管理节点。在生产集群中，您应该始终运行3或5个管理节点以实现高可用性。

通过在两个管理节点中的任何一个上运行docker node ls来验证它已成功添加。

$ docker node ls
ID                HOSTNAME   STATUS    AVAILABILITY    MANAGER STATUS
7xamk...ge662z    mgr1       Ready     Active          Leader
i0ue4...zcjm7f *  mgr2       Ready     Active          Reachable

输出显示mgr1和mgr2都是Swarm的一部分，都是管理节点。更新后的配置如图15.6所示。

将Swarm工作节点添加到Swarm是一个类似的两步过程 - 提取加入令牌并在节点上运行命令。

在两个管理节点中的任何一个上运行以下命令以公开工作节点加入令牌。

$ docker swarm join-token worker

To add a worker to this swarm, run the following command:

    docker swarm join --token \
    SWMTKN-1-1dmtw...17stb-ehp8g...w738q \
    172.31.5.251:2377

如下图所示，复制该命令并在wrk1上运行：

$ docker swarm join --token SWMTKN-1-1dmtw...17stb-ehp8g...w738q \
> 172.31.5.251:2377

This node joined a swarm as a worker.

从任何一个管理节点运行另一个docker node ls命令。

$ docker node ls
ID                 HOSTNAME     STATUS     AVAILABILITY   MANAGER STATUS
7xamk...ge662z *   mgr1         Ready      Active         Leader
ailrd...ofzv1u     wrk1         Ready      Active
i0ue4...zcjm7f     mgr2         Ready      Active         Reachable

现在我们有一个包含两个管理节点和一个工作节点的Swarm。管理节点已配置为高可用性（HA），并且集群存储已复制到两个管理节点。最终的配置如图15.7所示。

深入了解Swarm安全性背后的情况

现在我们已经构建了一个安全的Swarm，让我们花点时间来了解一下背后涉及的一些安全技术。

Swarm加入令牌

每个swarm都维护两个不同的加入令牌：

1. 用于加入新的管理器
2. 用于加入新的工作节点

每个加入令牌由4个不同的字段组成，用短横线（-）分隔：

• 前缀（PREFIX） - 版本（VERSION） - Swarm ID - 令牌（TOKEN）

前缀始终是SWMTKN。这允许您进行模式匹配，防止人们意外地将其公开发布。版本字段表示swarm的版本。Swarm ID字段是swarm证书的哈希值。令牌字段是工作节点或管理器令牌。

如下所示，Swarm的管理器和工作节点加入令牌除了最后的令牌字段之外是相同的：

• 管理器：SWMTKN-1-1dmtwusdc...r17stb-2axi53zjbs45lqxykaw8p7glz
• 工作节点：SWMTKN-1-1dmtwusdc...r17stb-ehp8gltji64jbl45zl6hw738q

如果您怀疑您的任何加入令牌已被泄露，您可以通过一条命令吊销它们并发放新的令牌。以下示例吊销现有的管理器加入令牌并发放一个新的：

$ docker swarm join-token --rotate manager

Successfully rotated manager join token.

您无需更新现有的管理器，但任何新的管理器都需要使用新的令牌添加。

请注意，旧令牌和新令牌之间唯一的区别是最后一个字段。Swarm ID的哈希值保持不变。

加入令牌存储在默认情况下加密的集群存储中。

TLS 和双向身份验证

加入Swarm的每个管理节点和工作节点都会收到一个客户端证书，用于进行相互认证。该证书标识了节点的身份、所属的Swarm集群，以及它是管理节点还是工作节点。

您可以使用以下Linux命令检查节点的客户端证书。

$ sudo openssl x509 \
  -in /var/lib/docker/swarm/certificates/swarm-node.crt \
  -text

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            7c:ec:1c:8f:f0:97:86:a9:1e:2f:4b:a9:0e:7f:ae:6b:7b:b7:e3:d3
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN = swarm-ca
        Validity
            Not Before: May 23 08:23:00 2023 GMT
            Not After : Aug 21 09:23:00 2023 GMT
        Subject: O = tcz3w1t7yu0s4wacovn1rtgp4, OU = swarm-manager, 
            CN = 2gxz2h1f0rnmc3atm35qcd1zw
        Subject Public Key Info:
<SNIP>

输出中的主题数据使用标准的O、OU和CN字段来指定Swarm ID、节点的角色和节点ID。

• 组织（O）字段存储了Swarm ID
• 组织单位（OU）字段存储了节点在Swarm中的角色
• 规范名称（CN）字段存储了节点的加密ID。

如图15.8所示。

您还可以在"有效性"部分中看到证书轮换周期。

您可以将这些值与docker info命令的输出中显示的相应值进行匹配。

$ docker info
<SNIP>
 Swarm: active
  NodeID: 2gxz2h1f0rnmc3atm35qcd1zw     # Relates to the CN field
  Is Manager: true                      # Relates to the OU field
  ClusterID: tcz3w1t7yu0s4wacovn1rtgp4  # Relates to the O field
 <SNIP>
  CA Configuration:
  Expiry Duration: 3 months             # Relates to validity field
  Force Rotate: 0
  Root Rotation In Progress: false
 <SNIP>

配置一些CA设置

您可以使用docker swarm update命令来配置Swarm的证书轮换周期。以下示例将证书轮换周期更改为30天。

$ docker swarm update --cert-expiry 720h

Swarm允许节点提前续订证书，以便所有节点不会同时尝试更新。

您可以通过在docker swarm init命令中传递--external-ca标志来创建新Swarm时配置外部CA。

docker swarm ca命令还可用于管理与CA相关的配置。运行该命令并带上--help标志以查看它可以执行的操作列表。

$ docker swarm ca --help

Usage:  docker swarm ca [OPTIONS]

Display and rotate the root CA

Options:
      --ca-cert pem-file          Path to the PEM-formatted root CA
                                  certificate to use for the new cluster
      --ca-key pem-file           Path to the PEM-formatted root CA
                                  key to use for the new cluster
      --cert-expiry duration      Validity period for node certificates
                                  (ns|us|ms|s|m|h) (default 2160h0m0s)
  -d, --detach                    Exit immediately instead of waiting for
                                  the root rotation to converge
      --external-ca external-ca   Specifications of one or more certificate
                                  signing endpoints
  -q, --quiet                     Suppress progress output
      --rotate                    Rotate the swarm CA - if no certificate
                                  or key are provided, new ones will be generated

集群存储

集群存储是存储群集配置和状态的地方。它对于 Docker 的其他技术，比如覆盖网络和秘密等，也非常重要。这就是为什么对于许多高级和与安全相关的功能，需要使用 swarm 模式的原因。

该存储目前基于流行的 etcd 分布式数据库，并自动配置为在所有管理器之间进行复制。它还默认启用了加密。

日常维护由 Docker 自动处理。但在生产环境中，您应该建立强大的备份和恢复解决方案。

现在关于 swarm 模式的安全性已经讲得足够多了。本章的其余部分将重点介绍不需要 swarm 模式的 Docker 相关安全技术。

镜像漏洞扫描

漏洞扫描是应对镜像中的漏洞和安全问题的重要手段。

扫描器的工作方式是建立镜像中所有软件的列表，然后将这些软件与已知漏洞的数据库进行比较。大多数漏洞扫描器会对漏洞进行排名，并提供修复建议和帮助。

尽管漏洞扫描非常有用，但重要的是要了解其局限性。例如，扫描侧重于镜像，不会检测网络、节点或编排器的安全问题。此外，并非所有的镜像扫描器都相同，有些会执行深度的二进制级扫描以检测软件包，而其他一些只查看软件包名称，不会深入检查内容。

在撰写本文时，Docker Hub 提供了某些付费账户的镜像扫描功能。这可能会在未来发生变化。一些本地私有仓库提供内置的扫描功能，还有第三方服务提供镜像扫描服务。Docker Desktop 也支持扫描镜像的扩展。

图15.9显示了在Docker Hub上的扫描结果是什么样子的，图15.10显示了Trivy Docker Desktop扩展的扫描结果。

总之，镜像漏洞扫描可以是一个深度检查已知漏洞的镜像的强大工具。不过要注意，知识越多责任越大------一旦你意识到了漏洞，你就有责任予以缓解或修复。

使用Docker内容信任（Docker Content Trust）进行镜像签名和验证

Docker Content Trust（DCT）使得验证镜像的完整性和发布者变得简单而易于实现。这在从不受信任的网络（如互联网）上拉取镜像时尤其重要。

在高层次上，DCT允许开发人员在将镜像推送到Docker Hub或其他容器仓库时对其进行签名。然后，在拉取和运行这些镜像时，可以进行验证。这个高层次的过程如图15.11所示。

DCT还可以用于提供上下文信息。这包括镜像是否已经签名以在特定环境（如"prod"或"dev"）中使用，或者镜像是否已被更新版本取代，因此已经过时。

以下步骤将引导您完成配置Docker Content Trust、签名和推送镜像，然后拉取已签名的镜像。

要跟随操作，您需要一个用于签名镜像的密钥对。如果您还没有一个，您可以使用docker trust命令生成一个。以下命令生成一个名为"nigel"的新密钥对，并将其加载到本地信任存储中，准备好供使用。

$ docker trust key generate nigel
Generating key for nigel...
Enter passphrase for new nigel key with ID 1f78609: 
Repeat passphrase for new nigel key with ID 1f78609: 
Successfully generated and loaded private key.... public key available: /root/nigel.pub

如果您已经有一个密钥对，您可以使用以下命令导入和加载它：docker trust key load key.pem --name nigel。

现在，我们已经加载了一个有效的密钥对，我们将把它与我们将推送已签名镜像的镜像仓库关联起来。此示例使用Docker Hub上的nigelpoulton/ddd-trust仓库和在前一步中创建的nigel.pub密钥。您的密钥文件和仓库将不同，而且在运行命令之前，仓库不必存在。

$ docker trust signer add --key nigel.pub nigel nigelpoulton/ddd-trust
Adding signer "nigel" to nigelpoulton/dct...
Initializing signed repository for nigelpoulton/dct...
Enter passphrase for root key with ID aee3314: 
Enter passphrase for new repository key with ID 1a18dd1: 
Repeat passphrase for new repository key with ID 1a18dd1: 
Successfully initialized "nigelpoulton/dct"
Successfully added signer: nigel to nigelpoulton/dct

以下命令将签名nigelpoulton/ddd-trust:signed镜像并将其推送到Docker Hub。您需要在您的系统上使用刚刚与密钥对关联的仓库名称对镜像进行标记。我将推送已签名的镜像。

$ docker trust sign nigelpoulton/ddd-trust:signed
docker trust sign nigelpoulton/ddd-trust:signed
Signing and pushing trust data for local image nigelpoulton/ddd-trust:signed...
The push refers to repository [docker.io/nigelpoulton/ddd-trust]
94dd7d531fa5: Mounted from library/alpine
signed: digest: sha256:30e6d35703c578e...4fcbbcbb0f281 size: 528
Signing and pushing trust metadata
Enter passphrase for nigel key with ID 4d6f1bf:
Successfully signed docker.io/nigelpoulton/ddd-trust:signed

推送操作将在Docker Hub上创建仓库并推送镜像。您可以使用以下命令检查其签名数据。

$ docker trust inspect nigelpoulton/ddd-trust:signed --pretty

Signatures for nigelpoulton/ddd-trust:signed
  SIGNED TAG   DIGEST                                                             SIGNERS
  signed       30e6d35703c578ee...4fcbbcbb0f281   nigel

List of signers and their keys for nigelpoulton/ddd-trust:signed
  SIGNER    KEYS
  nigel     4d6f1bf55702

Administrative keys for nigelpoulton/ddd-trust:signed
  Repository Key:	5e72e54afafb8444f...6b2744b32010ad22
  Root Key:	40418fc47544ca630...69a2cb89028c22092

您可以通过导出DOCKER_CONTENT_TRUST环境变量并将其值设置为1，来强制Docker主机始终签名和验证镜像的推送和拉取操作。在实际环境中，您会希望将其设置为Docker主机的更加永久的特性。

$ export DOCKER_CONTENT_TRUST=1

一旦启用了 Docker Content Trust（DCT），您将无法再拉取和使用未签名的镜像。您可以尝试拉取一个未签名的镜像来测试这种行为。

Docker Content Trust 是帮助您验证从容器仓库拉取的镜像的重要技术。在其基本形式下，它很容易配置，但更高级的功能，如上下文，可能会更复杂。

Docker Secrets

许多应用程序包含诸如密码、证书和SSH密钥等敏感数据。

早期版本的Docker没有一种安全地向应用程序提供此类敏感数据的方法。我们通常通过明文环境变量将它们插入到应用程序中（我们都这样做过）。幸运的是，现代的Docker安装支持Docker Secrets（Docker 机密）。

注意：机密需要使用集群存储（cluster store）的Swarm功能。

在幕后，机密在静态存储时是加密的，在网络上传输时也是加密的，通过内存文件系统挂载到容器中，并采用最低权限模型，只会提供给已明确授予访问权限的服务。甚至有一个docker secret子命令。

图15.12显示了一个高级工作流程：

以下步骤介绍了图15.12所示的工作流程。机密以密钥符号显示，虚线表示的容器图标不属于具有对机密访问权限的服务。

1. 创建并发布机密到Swarm。
2. 机密存储在加密的集群存储中。
3. 创建服务并将机密附加到该服务。
4. 机密在传递到服务副本时通过网络进行加密。
5. 机密以未加密的文件形式挂载到服务副本中，存储在内存文件系统中。
6. 一旦副本完成，内存文件系统将被销毁，并且机密将从节点中刷新。虚线绘制的容器不属于同一服务，无法访问机密。

机密以未加密的形式挂载的原因是应用程序可以使用它们而无需密钥进行解密。

您可以使用docker secret命令创建和管理机密，然后通过将--secret标志传递给docker service create命令将它们附加到服务。