对高级用户使用公证人客户端
预计阅读时间：11分钟
本页为正在运行自己的Notary服务的用户说明Notary客户端的高级用法。在继续之前，请确保您已先阅读并理解如何 运行自己的公证服务。
有关示例的重要说明
本文档的命令示例省略了-s和-d标志。如果您不知道这些选项的作用，请阅读“入门”文档或运行notary --help后再继续。了解这些标志的作用后，在阅读本文档时，必须为这些选项提供自己的值。您也可以配置这些选项，
有关更多信息，请参见高级配置选项。
初始化可信集合
在将内容添加到集合中并对其进行签名之前，必须首先初始化该集合。
$ notary init example.com/collection
No root keys found. Generating a new root key...
You are about to create a new root signing key passphrase. This passphrase
is used to protect the most sensitive key in your signing system.
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 is no
way to recover this key. You can find the key in your config directory.
Enter passphrase for new root key with ID 1f54328:
Repeat passphrase for new root key with ID 1f54328:
Enter passphrase for new targets key with ID 1df39fc (example.com/collection):
Repeat passphrase for new targets key with ID 1df39fc (example.com/collection):
初始化受信任的集合将生成以下各项；所有密钥都使用非对称算法，但不要求它们都使用相同的 算法：
- 如果找不到根密钥，
root则会生成一个初始密钥。该密钥用作所有受信任集合的默认信任根。 - 一个
targets钥匙和一个snapshot钥匙。相同的密码会加密这两者，因为它们的安全性配置文件（当两者均由受信任集合的作者持有时）是相同的。这就是为什么不提示您输入快照密钥密码的原因。 - 一把
timestamp钥匙 它是由服务器根据客户端的请求生成的，仅返回公共密钥。服务器持有私钥并代表用户签名时间戳。 - 存根签名的公证元数据。这将为集合暂存信任元数据的基本版本。它在发布到服务器时完成。
添加和删除目标
要将目标添加到使用公证CLI的受信任集合中，请执行以下操作：
$ notary add example.com/collection v1 my_file.txt
这会将my_file.txt目标名称下的本地文件（相对于当前工作目录必须存在）添加v1到example.com/collection我们设置的
集合中。本地文件的内容实际上并未添加到集合中-“目标”由文件路径和内容的一个或多个校验和组成。
这是一个脱机命令，我们必须运行a
notary publish example.com/collection才能使添加生效。
要删除目标，我们使用notary remove命令，指定GUN和目标名称。
$ notary remove example.com/collection v1
删除目标也是一种脱机命令，需要使a
notary publish example.com/collection生效。
管理金钥
默认情况下，公证客户端负责管理根，目标，快照角色的私钥。在初始化新的受信任集合时，默认情况下会生成所有这些密钥。密钥位于公证trust_dir
目录中。此外，如果存在委派角色，则公证客户端还将管理这些角色的密钥。
公证服务器始终负责管理时间戳记密钥。但是，如果快照密钥从公证客户端旋转到服务器，则公证服务器可以管理快照密钥，如以下小节所述。
旋转键
万一有潜在的威胁，公证人会提供用于旋转密钥的CLI命令。您可以使用该notary key rotate命令旋转目标或快照键。
默认情况下，快照密钥由公证客户端管理，请使用该notary key
rotate snapshot -r命令将快照密钥旋转到服务器，以便公证服务器可以对快照进行签名。在将委托与受信任的集合一起使用时，这特别有用，这样，委托就不再需要访问快照密钥即可将其更新推送到集合。
默认情况下，由Docker 1.11 Engine客户端创建的新集合导致服务器管理快照密钥。要在客户端上收回对快照密钥的控制，请使用notary key rotate不带-r标志的命令。
必须对目标密钥进行本地管理-要旋转目标密钥（例如，在受到威胁的情况下），请使用notary key rotate targets不带-r标志的命令。
使用Yubikey
当Yubikey启用CCID模式时，可以通过PKCS11接口将公证人与Yubikey 4键一起使用 。Yubikey具有存储根密钥的优先级，并且需要用户触摸输入进行签名。Yubikey支持包含在Docker Engine 1.11客户端中，可与Docker Content Trust一起使用。
要获得Yubikey的支持，必须 在标准库位置提供Yubico PIV库（与PIV工具捆绑在一起）。
使用委派角色
委托角色简化了公证受信任集合中的协作者工作流程，并且还允许跨委托在集合内容中获得细粒度的权限。本质上，委托角色是目标角色的受限版本，仅允许在某些文件路径内对目标进行签名。
委托角色具有自己的密钥，这样每个协作者都可以保留自己的私钥，而管理员不必共享目标密钥或允许协作者对集合的所有目标进行写访问。
在添加任何委托之前，应将快照密钥旋转到服务器。默认情况下，这是对使用Docker Engine 1.11客户端创建的新集合进行的。委派角色不需要快照密钥即可将其自己的目标发布到集合中，因为服务器可以使用委派目标发布有效的快照：
$ notary key rotate example.com/collection snapshot -r
在此，-r指定将密钥旋转到远程服务器。
添加委派时，您必须使用要委派给其的用户的公钥来获取x509证书。承担此委派角色的用户必须持有私钥才能与公证人签署内容。
获得委托人的x509证书后，可以为该用户添加委托：
$ notary delegation add example.com/collection targets/releases cert.pem --paths="delegation/path"
前面的示例说明了将委托添加targets/releases到GUN的请求
example.com/collection。targets/由于所有委托都是目标角色的受限制版本，因此委托名称必须以有效前缀为前缀。该命令将x509证书中包含的公钥添加cert.pem到targets/releases委托中。
为了使targets/releases委派角色能够签名内容，委派用户必须拥有与该公钥相对应的私钥。此命令限制此委派只能发布以前缀的路径名下的内容
delegation/path。使用给定的路径“ delegation / path”，该targets/releases
角色可以签署诸如“ delegation / path / content.txt”，“ delegation / path_file.txt”和“ delegation / path.txt”之类的路径。您可以在下方的逗号分隔列表中添加更多路径，也可以
--paths传递该--all-paths标志，以允许此委派以任何路径名发布内容。
发布后，可以使用list命令查看委托：
$ notary delegation list example.com/collection
ROLE PATHS KEY IDS THRESHOLD
---------------------------------------------------------------------------------------------------------------
targets/releases delegation/path 729c7094a8210fd1e780e7b17b7bb55c9a28a48b871b07f65d97baf93898523a 1
您可以看到targets/releases及其路径和密钥ID。如果您希望修改这些字段，则可以使用此角色上的其他命令notary delegation add或notary delegation remove命令来进行修改。
阈值1表示仅KEY IDS需要指定中的键之一才能发布到此委托。当前不支持非1的阈值。要完全删除委派角色，或仅删除单个键和/或路径，请使用以下notary delegation remove命令：
$ notary delegation remove example.com/user targets/releases
Are you sure you want to remove all data for this delegation? (yes/no)
yes
Forced removal (including all keys and paths) of delegation role targets/releases to repository "example.com/user" staged for next publish.
您可以通过传递键作为参数和/或--paths标记下的路径来删除单个键和/或路径。使用--all-paths以清除这个角色的所有路径。如果指定了委派角色中当前的所有密钥ID，则将其完全删除。
要将目标添加到指定的委派角色，我们可以将notary add
命令与--roles标志一起使用。
您必须为此角色导入适当的委派密钥。为此，您可以notary key import <KEY_FILE> --role user使用私钥PEM文件运行，也可以private/tuf_keys像<KEY_ID>.key将rolePEM标头设置为一样放下私钥PEM user。
$ notary add example/collections delegation/path/target delegation_file.txt --roles=targets/releases
在前面的示例中，您将目标添加delegation/path/target到example/collections为下一次发布而暂存的集合中。该文件
delegation_file.txt是delegation/path/target使用委托角色的目标targets/releases。该目标的路径是有效的，因为它以委托角色的有效路径为前缀。
该notary list和notary remove命令也可以采取--roles标志，以避免指定角色列表或删除目标。默认情况下，此操作基于基本targets角色。
要从我们的委托中删除此目标，请使用notary remove带有相同标志的命令：
$ notary remove example/collections delegation/path/target --roles=targets/releases
对内容信任使用委托
Docker Engine 1.10及更高版本支持将targets/releases
委托用作受信任图像标签的规范来源（如果存在）。
docker pull在Docker Engine 1.10上与Docker Content Trust一起运行时，Docker尝试在targets/releases角色中搜索签名的图像标签，targets如果不存在，则会退回到默认角色。在搜索默认targets角色时，Docker 1.10可能会拾取其他非targets/releases授权角色的已签名图像（如果该标签存在）。在Docker 1.11中，此行为已更改，以使所有docker pull使用Docker Content Trust的命令都必须提取仅由targets/releases委托角色或targets基本角色签名的标签。
在docker push使用Docker Content Trust运行时，Docker Engine 1.10会尝试使用targets/releases委派角色进行签名和推送（如果存在），否则会退回到该targets角色。在Docker 1.11中，docker push
尝试直接在用户具有其签名密钥的目标（例如：targets/role但不存在targets/nested/role）下使用所有委派角色进行签名和推送。如果存在委派角色，但用户没有签名密钥，则推送失败。如果不存在委托角色，则推送尝试使用基本targets角色进行签名。
要使用targets/releases具有内容信任关系的角色来推送和拉取图像，请按照上述步骤添加和发布具有公证人的委托角色。添加委托时，--all-paths应使用该标志允许对所有标签进行签名。
磁盘上的文件和状态
公证人将状态存储在其trust_dir目录中，这是~/.notary默认设置，或者通常~/.docker/trust在启用docker内容信任时使用。在此目录中，trusted_certificates将用于引导信任的证书存储在集合中，tuf存储将应用于GUN的TUF元数据和更改列表，并private存储私钥。
内的root_keys子目录private存储根私钥，而
tuf_keys存储目标，快照和委托私钥。