问题描述
初始化对docker内容信任和tuf上的公证的初始信任时，我了解TUF，Notary和Content Trust的工作方式.
When the initial trust on docker content trust with notary on tuf is initialized I understand how TUF, Notary and Content Trust works.
但是我不清楚的是，如何建立初始信任.
But what is not clear to me is, how the initial trust is setup.
我怎么知道，第一个请求不是一个被破坏的请求，并且初始的root.json是值得信任的?
How do I know, that the first pull is not a compromised one and the initial root.json is trustworthy?
因此，例如，如果我在启用内容信任的情况下执行 pull ，我将仅获得签名图像.但是，如何验证此图片是由正确的人签名的?
So for example if I do docker pull with content-trust enabled, I will only get signed images. But how do I verify, that this image is signed by the right person?
推荐答案
此处是公证人的创建者和维护者.贾斯汀已经给出了很好的解释，但我将更广泛地谈谈TUF和Notary中的信任初始化.
Notary creator and maintainer here. Justin has already given a good account but I'll speak to trust initialization in TUF and Notary more broadly.
除非您通过某些带外方法传达信任的根源，否则总会有一个隐式信任的下载点提供信任的根源.一些一般的案例:在下载操作系统(即任何Linux发行版)时，或在公共密钥目录中获取某人的GPG公共密钥时，便会执行此操作.假设资源是通过TLS连接交付的，并且我们认为发布者已经保护了其服务器的安全，我们相信我们会收到合法数据，并以此为基础在以后的所有交互中引导信任.这称为首次使用信任"或"TOFU".
Unless you communicate the root of trust through some out of band method, there will always be a point of download that you implicitly trust to deliver the root of trust. Some general case examples: we do this when we download an OS (i.e. any Linux distro), or grab somebody's GPG public key from a public key directory. Assuming the resources are delivered over a TLS connection and we believe that the publisher has secured their server, we trust we're receiving legitimate data, and use this to bootstrap trust on all future interactions. This is called Trust On First Use, or TOFU.
这里的说法是人们确实保持服务器安全，并且很难进行中间人(MiTM)攻击，尤其是针对TLS安全连接.因此，我们可以信任此初始下载.
The claim here is that people do keep their servers secure, and that it's difficult to perform a Man-in-the-middle (MiTM) attack, especially against a TLS secured connection. Therefore we can trust this initial download.
公证人有几种初始化信任的方法.首先是这种豆腐机制.TUF具有定义的更新流程，可确保在首次下载后对所有后续内容的信任.公证人实施此更新流程，并确保发布者在初次下载后保持一致.
Notary has a few ways one can initialize trust. The first is this TOFU mechanism. TUF has a defined update flow that ensures trust over all subsequent content after the initial download. Notary implements this update flow and ensures the publisher is consistent after the initial download.
如果您要另外确保发布者是特定实体，则Notary提供了三种不同的方式来引导信任.他们是:
If you want to additionally ensure the publisher is a specific entity, Notary provides three different ways to bootstrap that trust. They are:
- 手动将带外获取的root.json放在公证缓存中的正确位置.
- 配置信任固定以信任公证人全球唯一名称(GUN)的特定根密钥ID.
- 配置信任固定以信任特定公证人GUN或GUN前缀的CA.
有关信任固定的更多信息，请参见我们的文档.请注意，所有这三个选项都需要带外通信，在该通信中，您需要获取root.json，根密钥的ID或用于颁发根密钥的CA证书.
More information on trust pinning can be found in our docs. Note all 3 options require an out of band communication in which you acquire either a root.json, the ID of the root key, or the CA certificate that was used to issue the root key.
在 docker trust 命令下实施信任固定在我们的TODO列表中，目前还不存在.但是，您仍然可以将选项1与 docker trust 一起使用.缓存位于〜/.docker/trust/tuf/< GUN>/元数据/
Implementing trust pinning under the docker trust command is in our TODO list, it's not there yet. However you can still use option 1 with docker trust. The cache is located at ~/.docker/trust/tuf/<GUN>/metadata/
选项3的其他上下文:公证人实现一项功能，该功能允许您为GUN或GUN前缀配置CA.在这种情况下，要求将公共根密钥作为x509证书包含在root.json中，该证书链接到已配置的CA.虽然CA可能是一个有争议的话题，但没有人被迫使用此功能，并且在大多数攻击者模型中，它绝对比TOFU更好.另外，TUF明确没有解决如何引导信任.
Additional context on option 3: Notary implements a feature that allows one to configure CAs for GUNs or GUN prefixes. The requirement in this instance is that the public root key is included in the root.json as an x509 certificate that chains to the configured CA. While CAs can be a controversial topic, nobody is forced to use this feature and in most attacker models it's strictly better than TOFU. Additionally TUF explicitly does not address how trust is bootstrapped.
这篇关于Docker信任初始化的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！