Docker 信任初始化

Question

当对 docker content trust 与 notary on tuf 的初始信任初始化时，我了解 TUF、Notary 和 Content Trust 的工作原理。

但我不清楚的是，初始信任是如何建立的。

我怎么知道第一个 pull 不是一个被破坏的 pull 并且初始的 root.json 是值得信赖的？

因此，例如，如果我docker pull启用内容信任，我将只获得签名图像。但是我如何验证这个图像是否由正确的人签名？

Answer 1

公证创建者和维护者在这里。Justin 已经给出了一个很好的解释，但我会更广泛地谈谈 TUF 和 Notary 中的信任初始化。

除非您通过某种带外方法传达信任根，否则总会有一个您隐含信任的下载点来传递信任根。一些一般案例：我们在下载操作系统（即任何 Linux 发行版）或从公钥目录中获取某人的 GPG 公钥时执行此操作。假设资源通过 TLS 连接交付，并且我们相信发布者已经保护了他们的服务器，我们相信我们正在接收合法数据，并使用它来引导对所有未来交互的信任。这称为首次使用信任，或 TOFU。

这里的说法是，人们确实确保了他们的服务器安全，并且很难执行中间人 (MiTM) 攻击，尤其是针对 TLS 安全连接。因此我们可以信任这个初始下载。

Notary 有几种方法可以初始化信任。首先是这个TOFU机制。TUF 具有定义的更新流程，可确保初始下载后对所有后续内容的信任。Notary 实施此更新流程并确保发布者在初始下载后保持一致。

如果您还想确保发布者是特定实体，Notary 提供了三种不同的方式来引导这种信任。他们是：

1. 手动将带外获取的 root.json 放置在公证缓存中的正确位置。
2. 配置信任锁定以信任公证人全球唯一名称 (GUN) 的特定根密钥 ID。
3. 配置信任锁定以信任特定 Notary GUN 或 GUN 前缀的 CA。

有关信任锁定的更多信息，请参阅我们的文档。请注意，所有 3 个选项都需要带外通信，您可以在其中获取 root.json、根密钥的 ID 或用于颁发根密钥的 CA 证书。

在docker trust命令下实现信任锁定在我们的 TODO 列表中，它还没有。但是，您仍然可以将选项 1 与docker trust. 缓存位于~/.docker/trust/tuf/<GUN>/metadata/

选项 3 的附加上下文：Notary 实现了一项功能，允许为 GUN 或 GUN 前缀配置 CA。此实例中的要求是公共根密钥作为 x509 证书包含在 root.json 中，该证书链接到配置的 CA。尽管 CA 可能是一个有争议的话题，但没有人被迫使用此功能，并且在大多数攻击者模型中，它绝对优于 TOFU。此外，TUF 没有明确说明信任是如何引导的。