diff --git a/_data/toc.yaml b/_data/toc.yaml index 099ca5d77e..6e430855cb 100644 --- a/_data/toc.yaml +++ b/_data/toc.yaml @@ -2195,10 +2195,6 @@ manuals: section: - path: /ee/dtr/user/manage-images/sign-images/ title: Sign an image - - path: /ee/dtr/user/manage-images/sign-images/delegate-image-signing/ - title: Delegate image signing - - path: /ee/dtr/user/manage-images/sign-images/manage-trusted-repositories/ - title: Manage trusted repositories - path: /ee/dtr/user/manage-images/sign-images/trust-with-remote-ucp/ title: Trust with a Remote UCP - sectiontitle: Promotion policies and mirroring diff --git a/ee/dtr/images/delegate-image-signing-1.svg b/ee/dtr/images/delegate-image-signing-1.svg deleted file mode 100644 index 73ffb9a892..0000000000 --- a/ee/dtr/images/delegate-image-signing-1.svg +++ /dev/null @@ -1,179 +0,0 @@ - - - - - -delegate-image-signing-1 -Created with Sketch. - - - - - - - - IT ops team - - - QA team - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - dev/node - - - - dev/java - - - - dev/nginx - - - - - - - diff --git a/ee/dtr/images/sign-an-image-3.png b/ee/dtr/images/sign-an-image-3.png index c8253b31a6..a5c2030356 100644 Binary files a/ee/dtr/images/sign-an-image-3.png and b/ee/dtr/images/sign-an-image-3.png differ diff --git a/ee/dtr/user/access-dtr/configure-your-notary-client.md b/ee/dtr/user/access-dtr/configure-your-notary-client.md deleted file mode 100644 index e2880b9cb3..0000000000 --- a/ee/dtr/user/access-dtr/configure-your-notary-client.md +++ /dev/null @@ -1,141 +0,0 @@ ---- -title: Configure your Notary client -description: Learn how to configure your Notary client to push and pull images from Docker Trusted Registry. -keywords: registry, notary, trust ---- - -The Docker CLI client makes it easy to sign images but to streamline that -process it generates a set of private and public keys that are not tied -to your UCP account. This means that you'll be able to push and sign images to -DTR, but UCP won't trust those images since it doesn't know anything about -the keys you're using. - -So before signing and pushing images to DTR you should: - -* Configure the Notary CLI client -* Import your UCP private keys to the Notary client - -This allows you to start signing images with the private keys in your UCP -client bundle, that UCP can trace back to your user account. - -## System requirements - -The version of Notary you install, depends on the version of the Docker CLI -you're using: - -* Docker CLI 17.08 or older, use Notary 0.4.3. -* Docker CLI 17.09 or newer, use Notary 0.6.0. - -## Download the Notary CLI client - -If you're using Docker Desktop for Mac or Docker Desktop for Windows, you already have the -`notary` command installed. - -If you're running Docker on a Linux distribution, you can [download -Notary from Github](https://github.com/docker/notary/releases). As an example: - -```bash -# Get the latest binary -curl -L -o notary - -# Make it executable -chmod +x notary - -# Move it to a location in your path. Use the -Z option if you're using SELinux. -sudo mv -Z notary /usr/bin/ -``` - -## Configure the Notary CLI client - -Before you use the Notary CLI client, you need to configure it to make it -talk with the Notary server that's part of DTR. - -There's two ways to do this, either by passing flags to the notary command, -or using a configuration file. - -### With flags - -Run the Notary command with: - -```bash -notary --server https:// --trustDir ~/.docker/trust --tlscacert --help -``` - -Here's what the flags mean: - -| Flag | Purpose | -|:--------------|:----------------------------------------------------------------------------------------------------------------------------------| -| `--server` | The Notary server to query | -| `--trustDir` | Path to the local directory where trust metadata will be stored | -| `--tlscacert` | Path to the DTR CA certificate. If you've configured your system to trust the DTR CA certificate, you don't need to use this flag | - -To avoid having to type all the flags when using the command, you can set an -alias: - - - -
-
-``` -alias notary="notary --server https:// --trustDir ~/.docker/trust --tlscacert " -``` -
-
-
-``` -set-alias notary "notary --server https:// --trustDir ~/.docker/trust --tlscacert " -``` -
-
-
- -### With a configuration file - -You can also configure Notary by creating a `~/.notary/config.json` file with -the following content: - -```json -{ - "trust_dir" : "~/.docker/trust", - "remote_server": { - "url": "https://:", - "root_ca": "" - } -} -``` - -To validate your configuration, try running the `notary list` command on a -DTR repository that already has signed images: - -```bash -notary list // -``` - -The command should print a list of digests for each signed image on the -repository. - -## Import your UCP key - -The last step in configuring the Notary CLI client is to import the private -key of your UCP client bundle. -[Get a new client bundle if you don't have one yet](/datacenter/ucp/2.2/guides/user/access-ucp/cli-based-access.md). - -Import the private key in your UCP bundle into the Notary CLI client: - -```bash -notary key import -``` - -The private key is copied to `~/.docker/trust`, and you'll be prompted for a -password to encrypt it. - -You can validate what keys Notary knows about by running: - -```bash -notary key list -``` - -The key you've imported should be listed with the role `delegation`. diff --git a/ee/dtr/user/manage-images/sign-images/delegate-image-signing.md b/ee/dtr/user/manage-images/sign-images/delegate-image-signing.md deleted file mode 100644 index ae4813fcfa..0000000000 --- a/ee/dtr/user/manage-images/sign-images/delegate-image-signing.md +++ /dev/null @@ -1,71 +0,0 @@ ---- -title: Delegate image signing -description: Learn how to grant permission for others to sign images in Docker Trusted Registry. -keywords: registry, sign, trust ---- - -Instead of signing all the images yourself, you can delegate that task -to other users. - -A typical workflow looks like this: - -1. A repository owner creates a repository in DTR, and initializes the trust -metadata for that repository -3. Team members download a UCP client bundle and share their public key -certificate with the repository owner -4. The repository owner delegates signing to the team members -5. Team members can sign images using the private keys in their UCP client -bundles - -In this example, the IT ops team creates and initializes trust for the -`dev/nginx`. Then they allow users in the QA team to push and sign images in -that repository. - -![teams](../../../images/delegate-image-signing-1.svg) - -## Create a repository and initialize trust - -A member of the IT ops team starts by configuring their -[Notary CLI client](../../access-dtr/configure-your-notary-client.md). - -Then they create the `dev/nginx` repository, -[initialize the trust metadata](index.md) for that repository, and grant -write access to members of the QA team, so that they can push images to that -repository. - -## Ask for the public key certificates - -The member of the IT ops team then asks the QA team for their public key -certificate files that are part of their UCP client bundle. - -If they don't have a UCP client bundle, -[they can download a new one](/ee/ucp/user-access/cli.md). - -## Delegate image signing - -When delegating trust, you associate a public key certificate with a role name. -UCP requires that you delegate trust to two different roles: - -* `targets/releases` -* `targets/`, where `` is the UCP team the user belongs to - -In this example we'll delegate trust to `targets/releases` and `targets/qa`: - -```bash -# Delegate trust, and add that public key with the role targets/releases -notary delegation add dtr.example.org/dev/nginx targets/releases \ - --all-paths --publish - -# Delegate trust, and add that public key with the role targets/admin -notary delegation add dtr.example.org/dev/nginx targets/qa \ - --all-paths --publish -``` - -Now members from the QA team just have to [configure their Notary CLI client -with UCP private keys](../../access-dtr/configure-your-notary-client.md) -to be able to [push and sign images](index.md) into the `dev/nginx` repository. - - -## Where to go next - -- [Manage trusted repositories](manage-trusted-repositories.md) diff --git a/ee/dtr/user/manage-images/sign-images/index.md b/ee/dtr/user/manage-images/sign-images/index.md index c0166a9e76..a26f42cc9d 100644 --- a/ee/dtr/user/manage-images/sign-images/index.md +++ b/ee/dtr/user/manage-images/sign-images/index.md @@ -2,175 +2,245 @@ title: Sign an image description: Learn how to sign the images you push to Docker Trusted Registry. keywords: registry, sign, trust +redirect_from: +- /ee/dtr/user/manage-images/sign-images/delegate-image-signing/ +- /ee/dtr/user/manage-images/sign-images/manage-trusted-repositories/ --- -By default, when you push an image to DTR, the Docker CLI client doesn't -sign the image. +2 Key components of the Docker Trusted Registry is the Notary Server and Notary +Signer. These 2 containers give us the required components to use Docker Content +Trust right out of the box. [Docker Content +Trust](/engine/security/trust/content_trust/) allows us to sign image tags, +therefore whoever pulls the image can validate that they are getting the image +you create, or a forged one. + +As part of Docker Trusted Registry both the Notary server and the Registry +server are accessed through a front end Proxy, with both components sharing the +UCP's RBAC Engine. Therefore no additional configuration of the Docker Client +is required to use trust. + +Docker Content Trust is integrated into the Docker CLI, allowing you to +configure repositories, add signers and sign images all through the `$ docker +trust` command. ![image without signature](../../../images/sign-an-image-1.svg) -You can configure the Docker CLI client to sign the images you push to DTR. -This allows whoever pulls your image to validate if they are getting the image -you created, or a forged one. - -To sign an image, you can run: - -```bash -export DOCKER_CONTENT_TRUST=1 -docker push //: -``` - -This pushes the image to DTR and creates trust metadata. It also creates -public and private key pairs to sign the trust metadata, and pushes that metadata -to the Notary Server internal to DTR. - -![image with signature](../../../images/sign-an-image-2.svg) - - ## Sign images that UCP can trust -With the command above you'll be able to sign your DTR images, but UCP won't -trust them because it can't tie the private key you're using to sign the images -to your UCP account. +UCP has a feature which will prevent [untrusted +images](/ee/ucp/admin/configure/run-only-the-images-you-trust/) from being +deployed on the cluster. To use this feature, we first need to upload and sign +images into DTR. To tie the signed images back to UCP, we will actually sign the +images with private keys of UCP users. Inside of a UCP Client bundle the +`key.pem` can be used a User's private key, with the `cert.pem` being a public +key within a x509 certificate. To sign images in a way that UCP trusts them, you need to: -* Configure your Notary client -* Initialize trust metadata for the repository -* Delegate signing to the keys in your UCP client bundle +1. Download a Client Bundle for a User you want to use to sign the images. +2. Load the private key of the User into your workstations trust store. +3. Initialize trust metadata for the repository. +4. Delegate signing for that repository to the UCP User. +5. Sign the Image. -In this example we're going to pull an NGINX image from Docker Hub, -re-tag it as `dtr.example.org/dev/nginx:1`, push the image to DTR and sign it -in a way that is trusted by UCP. If you manage multiple repositories, you'll -have to do the same procedure for every one of them. +In this example we're going to pull a nginx image from the Docker Hub, re-tag it +as `dtr.example.com/dev/nginx:1`, push the image to DTR and sign it in a way +that is trusted by UCP. If you manage multiple repositories, you'll have to do +the same procedure for each repository. -### Configure your Notary client +### Import a UCP User's Private Key -Start by [configuring your Notary client](../../access-dtr/configure-your-notary-client.md). -This ensures the Docker an Notary CLI clients know about your UCP private keys. - -### Initialize the trust metadata - -Then you need to initialize the trust metadata for the new repository, and -the easiest way to do it is by pushing an image to that repository. Navigate to -the **DTR web UI**, and create a repository for your image. -In this example we've created the `dev/nginx` repository. - -From the Docker CLI client, pull an NGINX image from Docker Hub, -re-tag it, sign and push it to DTR. +Once you have download and extracted a UCP User's client bundle into your local +directory, you need to load the Private key into the local Docker trust store +`(~/.docker/trust)`. The name used here is purely metadata to help keep track of +which keys you have imported. ```bash -# Pull NGINX from Docker Hub -docker pull nginx:latest - -# Re-tag NGINX -docker tag nginx:latest dtr.example.org/dev/nginx:1 - -# Log into DTR -docker login dtr.example.org - -# Sign and push the image to DTR -export DOCKER_CONTENT_TRUST=1 -docker push dtr.example.org/dev/nginx:1 +$ docker trust key load --name jeff key.pem +Loading key from "key.pem"... +Enter passphrase for new jeff key with ID a453196: +Repeat passphrase for new jeff key with ID a453196: +Successfully imported key from key.pem ``` -This pushes the image to DTR and initializes the trust metadata for that -repository. +### Initialize the trust metadata and add the Public Key + +Next, we need to initiate trust metadata for a DTR repository. If you have not +done so already, navigate to the **DTR web UI**, and create a repository for +your image. In this example we've created the `prod/nginx` repository. + +As part of initiating the repository, we will add the public key of the UCP User +as a signer. You will be asked for a number of passphrases to protect the keys. +Please keep note of these passphrases, and to learn more about managing keys +head to the Docker Content Trust documentation +[here](/engine/security/trust/trust_delegation/#managing-delegations-in-a-notary-server). + + +```bash +$ docker trust signer add --key cert.pem jeff dtr.example.com/prod/nginx +Adding signer "jeff" to dtr.example.com/prod/nginx... +Initializing signed repository for dtr.example.com/prod/nginx... +Enter passphrase for root key with ID 4a72d81: +Enter passphrase for new repository key with ID e0d15a2: +Repeat passphrase for new repository key with ID e0d15a2: +Successfully initialized "dtr.example.com/prod/nginx" +Successfully added signer: jeff to dtr.example.com/prod/nginx +``` + +We can inspect the trust metadata of the repository to make sure the User has +been added correctly. + +```bash +$ docker trust inspect --pretty dtr.example.com/prod/nginx + +No signatures for dtr.example.com/prod/nginx + +List of signers and their keys for dtr.example.com/prod/nginx + +SIGNER KEYS +jeff 927f30366699 + +Administrative keys for dtr.example.com/prod/nginx + + Repository Key: e0d15a24b741ab049470298734397afbea539400510cb30d3b996540b4a2506b + Root Key: b74854cb27cc25220ede4b08028967d1c6e297a759a6939dfef1ea72fbdd7b9a +``` + +### Sign the Image + +Finally, we will sign an image tag. These steps download the Image from the +Docker Hub, retag the Image to the DTR repository, push the image up to DTR, as +well as signing the tag with the UCP User's keys. + +```bash +$ docker pull nginx:latest + +$ docker tag nginx:latest dtr.example.com/prod/nginx:1 + +$ docker trust sign dtr.example.com/prod/nginx:1 +Signing and pushing trust data for local image dtr.example.com/prod/nginx:1, may overwrite remote trust data +The push refers to repository [dtr.example.com/prod/nginx] +6b5e2ed60418: Pushed +92c15149e23b: Pushed +0a07e81f5da3: Pushed +1: digest: sha256:5b49c8e2c890fbb0a35f6050ed3c5109c5bb47b9e774264f4f3aa85bb69e2033 size: 948 +Signing and pushing trust metadata +Enter passphrase for jeff key with ID 927f303: +Successfully signed dtr.example.com/prod/nginx:1 +``` + +We can inspect the trust metadata again to make sure the image tag has been +signed successfully. + +```bash +$ docker trust inspect --pretty dtr.example.com/prod/nginx:1 + +Signatures for dtr.example.com/prod/nginx:1 + +SIGNED TAG DIGEST SIGNERS +1 5b49c8e2c890fbb0a35f6050ed3c5109c5bb47b9e774264f4f3aa85bb69e2033 jeff + +List of signers and their keys for dtr.example.com/prod/nginx:1 + +SIGNER KEYS +jeff 927f30366699 + +Administrative keys for dtr.example.com/prod/nginx:1 + + Repository Key: e0d15a24b741ab049470298734397afbea539400510cb30d3b996540b4a2506b + Root Key: b74854cb27cc25220ede4b08028967d1c6e297a759a6939dfef1ea72fbdd7b9a +``` + +Or we can have a look at the signed image from within the **DTR UI**. ![DTR](../../../images/sign-an-image-3.png){: .with-border} -DTR shows that the image is signed, but UCP won't trust the image -because it doesn't have any information about the private keys used to sign -the image. +### Adding Additional Delegations -### Delegate trust to your UCP keys +If you wanted to sign this image with multiple UCP Users, maybe if you had a use +case where an image needed to be signed by a member of the `Security` team and a +member of the `Developers` team. Then you can add multiple signers to a +repository. -To sign images in a way that is trusted by UCP, you need to delegate trust, so -that you can sign images with the private keys in your UCP client bundle. - -When delegating trust you associate a public key certificate with a role name. -UCP requires that you delegate trust to two different roles: - -* `targets/releases` -* `targets/`, where `` is the UCP team the user belongs to - -In this example we'll delegate trust to `targets/releases` and `targets/admin`: +To do so, first load a private key from a UCP User of the Security Team's in to +the local Docker Trust Store. ```bash -# Delegate trust, and add that public key with the role targets/releases -notary delegation add --publish \ - dtr.example.org/dev/nginx \ - targets/releases \ - --all-paths - -# Delegate trust, and add that public key with the role targets/admin -notary delegation add --publish \ - dtr.example.org/dev/nginx \ - targets/admin \ - --all-paths +$ docker trust key load --name security key.pem +Loading key from "key.pem"... +Enter passphrase for new security key with ID 5ac7d9a: +Repeat passphrase for new security key with ID 5ac7d9a: +Successfully imported key from key.pem ``` -To push the new signing metadata to the Notary server, you'll have to push -the image again: +Upload the Public Key to the Notary Server and Sign the Image. You will be asked +for both the Developers passphrase, as well as the Security Users passphrase to +sign the tag. -```none -docker push dtr.example.org/dev/nginx:1 +```bash +$ docker trust signer add --key cert.pem security dtr.example.com/prod/nginx +Adding signer "security" to dtr.example.com/prod/nginx... +Enter passphrase for repository key with ID e0d15a2: +Successfully added signer: security to dtr.example.com/prod/nginx + +$ docker trust sign dtr.example.com/prod/nginx:1 +Signing and pushing trust metadata for dtr.example.com/prod/nginx:1 +Existing signatures for tag 1 digest 5b49c8e2c890fbb0a35f6050ed3c5109c5bb47b9e774264f4f3aa85bb69e2033 from: +jeff +Enter passphrase for jeff key with ID 927f303: +Enter passphrase for security key with ID 5ac7d9a: +Successfully signed dtr.example.com/prod/nginx:1 ``` -## Under the hood +Finally, we can check the tag again to make sure it is now signed by 2 +signatures. -Both Docker and Notary CLI clients interact with the Notary server to: +```bash +$ docker trust inspect --pretty dtr.example.com/prod/nginx:1 -* Keep track of the metadata of signed images -* Validate the signatures of the images you pull +Signatures for dtr.example.com/prod/nginx:1 -This metadata is also kept locally in `~/.docker/trust`. +SIGNED TAG DIGEST SIGNERS +1 5b49c8e2c890fbb0a35f6050ed3c5109c5bb47b9e774264f4f3aa85bb69e2033 jeff, security -```none -. -|-- private -| |-- root_keys -| | `-- 993ad247476da081e45fdb6c28edc4462f0310a55da4acf1e08404c551d94c14.key -| `-- tuf_keys -| `-- dtr.example.org -| `-- dev -| `-- nginx -| |-- 98a93b2e52c594de4d13d7268a4a5f28ade5fc1cb5f44cc3a4ab118572a86848.key -| `-- f7917aef77d0d4bf8204af78c0716dac6649346ebea1c4cde7a1bfa363c502ce.key -`-- tuf - `-- dtr.example.org - `-- dev - `-- nginx - |-- changelist - `-- metadata - |-- root.json - |-- snapshot.json - |-- targets.json - `-- timestamp.json +List of signers and their keys for dtr.example.com/prod/nginx:1 + +SIGNER KEYS +jeff 927f30366699 +security 5ac7d9af7222 + +Administrative keys for dtr.example.com/prod/nginx:1 + + Repository Key: e0d15a24b741ab049470298734397afbea539400510cb30d3b996540b4a2506b + Root Key: b74854cb27cc25220ede4b08028967d1c6e297a759a6939dfef1ea72fbdd7b9a ``` -The `private` directory contains the private keys the Docker CLI client uses -to sign the images. Make sure you create backups of this directory so that -you don't lose your signing keys. +For more advanced use cases like this, more information can be found [here](/engine/security/trust/trust_delegation/) -The Docker and Notary CLI clients integrate with Yubikey. If you have a Yubikey -plugged in when initializing trust for a repository, the root key is stored on -the Yubikey instead of in the trust directory. -When you run any command that needs the `root` key, Docker and Notary CLI -clients look on the Yubikey first, and use the trust directory as a fallback. +## Delete trust data -The `tuf` directory contains the trust metadata for the images you've -signed. For each repository there are four files. +If an Administrator wants to delete a DTR repository that contains Trust +metadata, they will be prompted to delete the trust metadata first before the +repository can be removed. -| File | Description | -|:-----------------|:--------------------------------------------------------------------------------------------------------------------------| -| `root.json` | Has data about other keys and their roles. This data is signed by the root key. | -| `targets.json` | Has data about the digest and size for an image. This data is signed by the target key. | -| `snapshot.json` | Has data about the version number of the root.json and targets.json files. This data is signed by the snapshot key. | -| `timestamp.json` | Has data about the digest, size, and version number for the snapshot.json file. This data is signed by the timestamp key. | +To delete trust metadata we need to use the Notary CLI. For information on how +to download and configure the Notary CLI head +[here](/engine/security/trust/trust_delegation/#configuring-the-notary-client) -[Learn more about trust metadata](/notary/service_architecture.md). + +```bash +$ notary delete dtr.example.com/prod/nginx --remote +Deleting trust data for repository dtr.example.com/prod/nginx +Enter username: admin +Enter password: +Successfully deleted local and remote trust data for repository dtr.example.com/prod/nginx +``` + +If you don't include the `--remote` flag, Notary deletes local cached content +but will not delete data from the Notary server. ## Where to go next -* [Delegate image signing](delegate-image-signing.md) +* [Automating Docker Content + Trust](/engine/security/trust/trust_automation/) +* [Using Docker Content Trust with a Remote UCP](./trust-with-remote-ucp.md) \ No newline at end of file diff --git a/ee/dtr/user/manage-images/sign-images/manage-trusted-repositories.md b/ee/dtr/user/manage-images/sign-images/manage-trusted-repositories.md deleted file mode 100644 index 2cee2d83d0..0000000000 --- a/ee/dtr/user/manage-images/sign-images/manage-trusted-repositories.md +++ /dev/null @@ -1,156 +0,0 @@ ---- -title: Manage trusted repositories -description: Learn how to use the Notary CLI client to manage trusted repositories -keywords: dtr, trust, notary, security ---- - -Once you -[configure the Notary CLI client](../../access-dtr/configure-your-notary-client.md), -you can use it to manage your private keys, list trust data from any repository -you have access to, authorize other team members to sign images, and rotate -keys if a private key has been compromised. - -## List trust data - -List the trust data for a repository by running: - -```bash -notary list // -``` - -You can get one of the following errors, or a list with the images that have -been signed: - -| Message | Description | -|:--------------------------------------------|:-----------------------------------------------------------------------------------------------------------------| -| `fatal: client is offline` | Either the repository server can't be reached, or your Notary CLI client is misconfigured | -| `fatal: does not have trust data` | There's no trust data for the repository. Either run `notary init` or sign and push an image to that repository. | -| `No targets present in this repository` | The repository has been initialized, but doesn't contain any signed images | - -## Initialize trust for a repository - -There's two ways to initialize trust data for a repository. You can either -sign and push an image to that repository: - -```bash -export DOCKER_CONTENT_TRUST=1 -docker push // -``` - -or - -``` -notary init // --publish -``` - -## Manage staged changes - -The Notary CLI client stages changes before publishing them to the server. -You can manage the changes that are staged by running: - -```bash -# Check what changes are staged -notary status // - -# Unstage a specific change -notary status // --unstage 0 - -# Alternatively, unstage all changes -notary status // --reset -``` - -When you're ready to publish your changes to the Notary server, run: - -```bash -notary publish // -``` - -## Delete trust data - -Administrator users can remove all signatures from a trusted repository by -running: - -```bash -notary delete // --remote -``` - -If you don't include the `--remote` flag, Notary deletes local cached content -but will not delete data from the Notary server. - - -## Change the passphrase for a key - -The Notary CLI client manages the keys used to sign the image metadata. To -list all the keys managed by the Notary CLI client, run: - -```bash -notary key list -``` - -To change the passphrase used to encrypt one of the keys, run: - -```bash -notary key passwd -``` - -## Rotate keys - -If one of the private keys is compromised you can rotate that key, so that -images that were signed with the key stop being trusted. - -For keys that are kept offline and managed by the Notary CLI client, such the -keys with the root, targets, and snapshot roles, you can rotate them with: - -```bash -notary key rotate // -``` - -The Notary CLI client generates a new key for the role you specified, and -prompts you for a passphrase to encrypt it. -Then you're prompted for the passphrase for the key you're rotating, and if it -is correct, the Notary CLI client contacts the Notary server to publish the -change. - -You can also rotate keys that are stored in the Notary server, such as the keys -with the snapshot or timestamp role. For that, run: - -```bash -notary key rotate // --server-managed -``` - -## Manage keys for delegation roles - -To delegate image signing to other UCP users, get the `cert.pem` file that's -included in their client bundle and run: - -```bash -notary delegation add \ - // targets/ user1.pem user2.pem \ - --all-paths --publish -``` - -You can also remove keys from a delegation role: - -```bash -# Remove the given keys from a delegation role -notary delegation remove \ - // targets/ \ - --publish - -# Alternatively, you can remove keys from all delegation roles -notary delegation purge // --key --key -``` - -## Troubleshooting - -Notary CLI has a `-D` flag that you can use to increase the logging level. You -can use this for troubleshooting. - -Usually most problems are fixed by ensuring you're communicating with the -correct Notary server, using the `-s` flag, and that you're using the correct -directory where your private keys are stored, with the `-d` flag. - -## Where to go next - -- [Learn more about Notary](/notary/advanced_usage.md) -- [Notary architecture](/notary/service_architecture.md) diff --git a/ee/dtr/user/manage-images/sign-images/trust-with-remote-ucp.md b/ee/dtr/user/manage-images/sign-images/trust-with-remote-ucp.md index 9453807aea..393bfd313b 100644 --- a/ee/dtr/user/manage-images/sign-images/trust-with-remote-ucp.md +++ b/ee/dtr/user/manage-images/sign-images/trust-with-remote-ucp.md @@ -148,14 +148,14 @@ head to the Docker Content Trust documentation ``` -$ docker trust signer add --key cert.pem cluster2admin dtr.example.com/admin/trustdemo:1 -Adding signer "cluster2admin" to dtr.example.com/admin/trustdemo:1... -Initializing signed repository for dtr.example.com/admin/trustdemo:1... +$ docker trust signer add --key cert.pem cluster2admin dtr.example.com/admin/trustdemo +Adding signer "cluster2admin" to dtr.example.com/admin/trustdemo... +Initializing signed repository for dtr.example.com/admin/trustdemo... Enter passphrase for root key with ID 4a72d81: Enter passphrase for new repository key with ID dd4460f: Repeat passphrase for new repository key with ID dd4460f: -Successfully initialized "dtr.example.com/admin/trustdemo:1" -Successfully added signer: cluster2admin to dtr.example.com/admin/trustdemo:1 +Successfully initialized "dtr.example.com/admin/trustdemo" +Successfully added signer: cluster2admin to dtr.example.com/admin/trustdemo ``` Finally we will sign an image tag. This pushes the image up to DTR, as well as diff --git a/engine/security/trust/trust_delegation.md b/engine/security/trust/trust_delegation.md index 2aa6e46973..23fddeb322 100644 --- a/engine/security/trust/trust_delegation.md +++ b/engine/security/trust/trust_delegation.md @@ -2,6 +2,8 @@ description: Delegations for content trust keywords: trust, security, delegations, keys, repository title: Delegations for content trust +redirect_from: +- /ee/dtr/user/access-dtr/configure-your-notary-client/ --- Delegations in Docker Content Trust (DCT) allow you to control who can and cannot sign