探索Docker的新内容信任功能

现代发展越来越多地涉及利用第三方。 无论是使用Azure和AWS之类的平台从npm或GitHub等存储库中编程库，还是从Stack Overflow复制代码示例，都可以公平地说，应用程序中使用的大多数代码将由主要开发人员以外的其他人编写。

Docker将第三方添加到开发人员可以在其流程中使用的第三方。 具体来说，Docker Hub提供了一种快速启动并运行各种应用程序的好方法。

信任

使用第三方会带来一个不可避免的问题：“我相信这个来源吗？”

听起来很简单的问题实际上很难回答。 对于初学者来说，“信任”是什么意思？ 借助Docker Hub之类的软件存储库，我们希望确保作者提供的软件与从存储库中获得的软件相同，因此我们可以相信，在将软件存储在存储库中时，它没有被无意或恶意修改。回购。

对于应用程序存储库，解决信任问题的主要方法是考虑允许开发人员对他们托管在系统上的内容进行签名。 正确实施的数字签名可以帮助确保用户使用的内容与原始开发人员创建的内容相同，并且实质上从信任图片中删除了存储库。

内容信任

因此，让我们用1.8 Docker Content Trust附带的功能来讨论该原理的Docker实现。 这样，Docker实施了许多安全控件，使开发人员可以确认他们使用的映像尚未被Docker修改，并且他们正在获取最新的可用版本。

在实现内容信任时，Docker从The Update Framework中汲取了想法， 该框架是一个开放规范，旨在解决代码存储库受损的风险。 已经为Python库包装之类的东西实现了许多实现，但是通过Content Trust，Docker可能是迄今为止最主流的实现。

实施内容信任

因此，从理论上讲，这都是好东西，但实际上，这实际上意味着什么？ 它是如何实现的，对用户的Docker映像管理生命周期有什么作用？

首先要注意的是，实施内容信任会限制将映像部署到Docker Hub的方式。 常用的自动构建方法不适用于Content Trust，因为使用此方法创建映像的不是存储库的所有者，而是Docker Hub本身。 显然，如果集线器进行了构建，则很难阻止集线器对其进行修改！

因此，如果您打算实施内容信任，则需要采取创建映像并将其从系统推送到Docker Hub的方法。

像大多数新概念一样，解释内容信任的最好方法可能是逐步研究一个可行的示例。 如果要尝试此操作，则需要在Docker Hub上有一个帐户，并设置了最新（1.8+）的Docker安装程序才能登录到它。

为了使本示例更简单，我将使用一个基本的Dockerfile进行工作，默认文件名位于我所在的目录中。

首先，让我们启用内容信任，因为默认情况下未启用它。 为此，请运行：

export DOCKER_CONTENT_TRUST=1

这只会为当前的bash会话设置它。 如果要永久设置它，请确保为登录时推送到存储库的用户设置了环境变量。

接下来，我们将要构建图像并向其添加标签，以便将其推到集线器上。 在这里，我们指定用户的名称，存储库和要设置的标签。 然后，我们将基于默认名称Dockerfile进行构建。

docker build -t raesenecttest/sign_test:latest .

现在我们准备好映像了，下一步是将映像推送到存储库中。 在这里，事情与通常的工作流程有所不同。

现在，我们使用以下标准命令将映像推送到Docker Hub：

docker push raesenecttest/sign_test:latest

这将看起来像任何其他推送一样，但是随后您将获得类似于我接下来显示的内容的文本。 系统将要求您为“离线”键和“标记”键创建密码短语。

Signing and pushing trust metadata
You are about to create a new root signing key passphrase. This passphrase
will be used to protect the most sensitive key in your signing system. Please
choose a long, complex passphrase and be careful to keep the password and the
key file itself secure and backed up. It is highly recommended that you use a
password manager to generate the passphrase and keep it safe. There will be no
way to recover this key. You can find the key in your config directory.
Enter passphrase for new offline key with id 2772ef5:
Repeat passphrase for new offline key with id 2772ef5:
Enter passphrase for new tagging key with id docker.io/raesenecttest/sign_test (7ca517e):
Repeat passphrase for new tagging key with id docker.io/raesenecttest/sign_test (7ca517e):
Finished initializing "docker.io/raesenecttest/sign_test"

显然，在这里创建一个强大而独特的密码短语是一个好主意。 对密钥的访问将使攻击者能够像自己一样对图像进行签名，这在很大程度上违反了内容信任的目的。 这确实给某些部署过程带来了一些麻烦。 例如，如果您要自动创建新的版本，则需要能够提供密钥的密码短语以对图像进行签名。 Docker确实提供了一种使用环境变量来执行此操作的机制，但是在执行此操作时，您需要非常确定构建主机的安全性。 显然，任何可以读取用于此操作的环境变量的人都将获得您的密码！

密钥管理

这里涉及的密钥是内容信任过程中非常重要的一部分，因此在这一点上值得讨论密钥管理。

操作密码学最困难的部分之一是很好地管理密钥。 密钥的丢失可能对加密系统造成灾难性的影响，不仅破坏安全性和/或使其无法操作，还需要进行大量的修复工作。

对于Docker Content Trust系统，需要对已生成的两个密钥进行一些区别对待。

仅在为帐户创建新存储库时才需要脱机密钥，并且顾名思义，脱机密钥在不使用时应保持脱机状态。 从安全角度来看，这样做的原因是，即使使用了适当的密码短语，您也希望减少密钥被泄露的风险。 通过访问密钥，可能可以计算出密码短语（通过键盘记录或蛮力攻击），这将使攻击者可以自己签名图像。

密钥可以在〜/ .docker / trust / private / root_keys中找到。 为了保护它，像加密的USB密钥（或两个，取决于密钥的重要性）之类的东西可能是个好主意。

创建的另一个密钥是标记密钥。 它存储在：

~/.docker/trust/private/tuf_keys/docker.io/<reponame>

该密钥也应备份，但更可能保持在线状态。 您将比脱机密钥更频繁地需要它，而且从丢失密钥中恢复也更容易。

因此，既然我们已经拥有签名的图像，这实际上意味着什么？ 好吧，对于图像用户，他们可以启用Docker Content Trust。 他们将确保下载图像时，自开发人员推动该图像以来，该图像未被篡改，并且该图像是该标签的新图像。

使用内容信任

但是，目前，启用Content Trust可能会使用户感到沮丧，因为它有助于阻止您提取未签名的任何标签。 如果您启用了Content Trust，并且尝试提取未签名的存储库，则将收到以下消息，并且不会得到图像：

Using default tag: latest
no trust data available

希望随着更多的存储库启用Content Trust，这将不再是问题。 但是，如果要在启用它的情况下运行并且仍使用未签名的标签，则可以将–disable-content-trust开关传递给Docker命令以在未启用Content Trust的情况下执行单个操作。

结论

总体而言，如果您要基于Docker构建受信任的映像，则Docker Content Trust是一项非常有用的功能。 它解决了一个关键的安全问题，该问题可能使开源软件存储库黯然失色。 希望它会在Docker Hub的用户中广受欢迎。

翻译自: https://www.javacodegeeks.com/2015/10/exploring-dockers-new-content-trust-feature.html