diff --git a/_data/toc.yaml b/_data/toc.yaml
index b37d0bb743..beb81c3955 100644
--- a/_data/toc.yaml
+++ b/_data/toc.yaml
@@ -1201,19 +1201,11 @@ manuals:
- path: /datacenter/ucp/2.1/guides/admin/configure/restrict-services-to-worker-nodes/
title: Restrict services to worker nodes
- path: /datacenter/ucp/2.1/guides/admin/configure/use-domain-names-to-access-services/
+ title: Run only the images you trust
+ - path: /datacenter/ucp/2.1/guides/admin/configure/run-only-the-images-you-trust/
title: Use domain names to access services
- path: /datacenter/ucp/2.1/guides/admin/configure/external-auth/
title: Integrate with LDAP
- - sectiontitle: Content trust
- section:
- - path: /datacenter/ucp/2.1/guides/admin/configure/content-trust/
- title: Only allow running signed images
- - path: /datacenter/ucp/2.1/guides/admin/configure/content-trust/admin_tasks/
- title: Configure the UCP and DTR servers for content trust
- - path: /datacenter/ucp/2.1/guides/admin/configure/content-trust/client_configuration/
- title: Configure the Docker client to sign images
- - path: /datacenter/ucp/2.1/guides/admin/configure/use-trusted-images-for-ci/
- title: Use trusted images for continuous integration
- sectiontitle: Manage users
section:
- path: /datacenter/ucp/2.1/guides/admin/manage-users/
@@ -1386,6 +1378,8 @@ manuals:
section:
- path: /datacenter/dtr/2.2/guides/user/access-dtr/
title: Configure your Docker Engine
+ - path: /datacenter/dtr/2.2/guides/user/access-dtr/configure-your-notary-client.md
+ title: Configure your Notary client
- path: /datacenter/dtr/2.2/guides/user/access-dtr/use-a-cache/
title: Use a cache
- sectiontitle: Manage images
@@ -1398,8 +1392,14 @@ manuals:
title: Delete images
- path: /datacenter/dtr/2.2/guides/user/manage-images/scan-images-for-vulnerabilities/
title: Scan images for vulnerabilities
- - path: /datacenter/dtr/2.2/guides/user/manage-images/manage-trusted-repositories/
- title: Manage trusted repositories
+ - sectiontitle: Sign images
+ section:
+ - path: /datacenter/dtr/2.2/guides/user/manage-images/sign-images/
+ title: Sign an image
+ - path: /datacenter/dtr/2.2/guides/user/manage-images/sign-images/delegate-image-signing/
+ title: Delegate image signing
+ - path: /datacenter/dtr/2.2/guides/user/manage-images/sign-images/manage-trusted-repositories/
+ title: Manage trusted repositories
- path: /datacenter/dtr/2.2/guides/user/create-and-manage-webhooks/
title: Create and manage webhooks
- path: /datacenter/dtr/2.2/reference/api/
diff --git a/datacenter/dtr/2.2/guides/images/delegate-image-signing-1.svg b/datacenter/dtr/2.2/guides/images/delegate-image-signing-1.svg
new file mode 100644
index 0000000000..e3e5239efe
--- /dev/null
+++ b/datacenter/dtr/2.2/guides/images/delegate-image-signing-1.svg
@@ -0,0 +1,81 @@
+
+
\ No newline at end of file
diff --git a/datacenter/dtr/2.2/guides/images/sign-an-image-1.svg b/datacenter/dtr/2.2/guides/images/sign-an-image-1.svg
new file mode 100644
index 0000000000..f172feea36
--- /dev/null
+++ b/datacenter/dtr/2.2/guides/images/sign-an-image-1.svg
@@ -0,0 +1,156 @@
+
+
\ No newline at end of file
diff --git a/datacenter/dtr/2.2/guides/images/sign-an-image-2.svg b/datacenter/dtr/2.2/guides/images/sign-an-image-2.svg
new file mode 100644
index 0000000000..c3028766b9
--- /dev/null
+++ b/datacenter/dtr/2.2/guides/images/sign-an-image-2.svg
@@ -0,0 +1,166 @@
+
+
\ No newline at end of file
diff --git a/datacenter/dtr/2.2/guides/images/sign-an-image-3.png b/datacenter/dtr/2.2/guides/images/sign-an-image-3.png
new file mode 100644
index 0000000000..c8253b31a6
Binary files /dev/null and b/datacenter/dtr/2.2/guides/images/sign-an-image-3.png differ
diff --git a/datacenter/dtr/2.2/guides/user/access-dtr/configure-your-notary-client.md b/datacenter/dtr/2.2/guides/user/access-dtr/configure-your-notary-client.md
new file mode 100644
index 0000000000..490fcbd45c
--- /dev/null
+++ b/datacenter/dtr/2.2/guides/user/access-dtr/configure-your-notary-client.md
@@ -0,0 +1,123 @@
+---
+title: Configure your Notary client
+description: Learn how to configure your Notary client to push and pull images from Docker Trusted Registry.
+keywords: docker, 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.
+
+## Download the Notary CLI client
+
+If you're using Docker for Mac or Docker for Windows, you already have the
+`notary` command installed.
+
+If you're running Docker on a Linux distribution, you can [download the
+latest version](https://github.com/docker/notary/releases). As an example:
+
+```bash
+# Get the latest binary
+curl -o notary
+
+# Make it executable
+chmod +x notary
+
+# Move it to a location in your path
+sudo mv 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
+```
+
+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:
+
+```none
+# Bash
+alias notary="notary --server https:// --trustDir ~/.docker/trust --tlscacert "
+
+# PowerShell
+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": "",
+ "root_ca": ""
+ }
+}
+```
+
+To validate your configuration, try running the `notary list` command on a
+DTR repository that already has signed images:
+
+```none
+# Assumes you've configured notary
+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.1/guides/user/access-ucp/cli-based-access.md).
+
+Import the private key in your UCP bundle into the Notary CLI client:
+
+```none
+# Assumes you've configured notary
+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:
+
+```none
+notary key list
+```
+
+The key you've imported should be listed with the role `delegation`.
diff --git a/datacenter/dtr/2.2/guides/user/access-dtr/index.md b/datacenter/dtr/2.2/guides/user/access-dtr/index.md
index 1b11f1bab1..65d8f870d7 100644
--- a/datacenter/dtr/2.2/guides/user/access-dtr/index.md
+++ b/datacenter/dtr/2.2/guides/user/access-dtr/index.md
@@ -27,13 +27,26 @@ system to trust that certificate.
In your browser navigate to `https:///ca` to download the TLS
certificate used by DTR. Then
-[add that certificate to the macOS trust store](https://support.apple.com/kb/PH18677?locale=en_US).
+[add that certificate to macOS Keychain](https://support.apple.com/kb/PH20129).
+
+After adding the CA certificate to Keychain, restart Docker for Mac.
### Windows
In your browser navigate to `https:///ca` to download the TLS
-certificate used by DTR. Then
-[add that certificate to the Windows trust store](https://technet.microsoft.com/en-us/library/cc754841(v=ws.11).aspx).
+certificate used by DTR. Open Windows Explorer, right-click the
+file you've downloaded, and choose **Install certificate**.
+
+Then, select the following options:
+
+* Store location: local machine
+* Check 'place all certificates in the following store'
+* Click 'Browser', and select 'Trusted Root Certificate Authorities'
+* Click 'Finish'
+
+[Learn more about managing TLS certificates](https://technet.microsoft.com/en-us/library/cc754841(v=ws.11).aspx).
+
+After adding the CA certificate to Windows, restart Docker for Windows.
### Ubuntu/ Debian
@@ -95,7 +108,7 @@ $ sudo /bin/systemctl restart docker.service
sudo /etc/init.d/docker restart
```
-## Login into DTR
+## Log into DTR
To validate that your Docker daemon trusts DTR, trying authenticating against
DTR.
diff --git a/datacenter/dtr/2.2/guides/user/manage-images/sign-images/delegate-image-signing.md b/datacenter/dtr/2.2/guides/user/manage-images/sign-images/delegate-image-signing.md
new file mode 100644
index 0000000000..af08c38e90
--- /dev/null
+++ b/datacenter/dtr/2.2/guides/user/manage-images/sign-images/delegate-image-signing.md
@@ -0,0 +1,72 @@
+---
+title: Delegate image signing
+description: Learn how to grant permission for others to sign images in Docker Trusted Registry.
+keywords: docker, 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.
+
+
+
+## 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](/datacenter/ucp/2.1/guides/user/access-ucp/cli-based-access.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`:
+
+```none
+# 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/qa \
+ --all-paths
+```
+
+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/datacenter/dtr/2.2/guides/user/manage-images/sign-images/index.md b/datacenter/dtr/2.2/guides/user/manage-images/sign-images/index.md
new file mode 100644
index 0000000000..c192109ea8
--- /dev/null
+++ b/datacenter/dtr/2.2/guides/user/manage-images/sign-images/index.md
@@ -0,0 +1,170 @@
+---
+title: Sign an image
+description: Learn how to sign the images you push to Docker Trusted Registry.
+keywords: docker, registry, sign, trust
+---
+
+By default, when you push an image to DTR, the Docker CLI client doesn't
+sign the image.
+
+
+
+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:
+
+```none
+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 push that metadata
+to the Notary Server internal to DTR.
+
+
+
+
+## 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.
+
+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
+
+In this example we're going to pull an NGINX image from Docker Store,
+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.
+
+### Configure your Notary client
+
+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 Store,
+re-tag it, sign and push it to DTR.
+
+```bash
+# Pull NGINX from Docker Store
+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
+```
+
+This pushes the image to DTR and initializes the trust metadata for that
+repository.
+
+{: .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.
+
+### Delegate trust to your UCP keys
+
+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`:
+
+```none
+# 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
+```
+
+To push the new signing metadata to the Notary server, you'll have to push
+the image again:
+
+```none
+docker push dtr.example.org/dev/nginx:1
+```
+
+## Under the hood
+
+Both Docker and Notary CLI clients interact with the Notary server to:
+
+* Keep track of the metadata of signed images
+* Validate the signatures of the images you pull
+
+This metadata is also kept locally in `~/.docker/trust`.
+
+```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
+```
+
+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.
+
+The Docker and Notary CLI clients integrates 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 uses the trust directory as a fallback.
+
+The `tuf` directory contains the trust metadata for the images you've
+signed. For each repository there are four files.
+
+| 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. |
+
+[Learn more about trust metadata](/notary/service_architecture.md).
diff --git a/datacenter/dtr/2.2/guides/user/manage-images/manage-trusted-repositories.md b/datacenter/dtr/2.2/guides/user/manage-images/sign-images/manage-trusted-repositories.md
similarity index 63%
rename from datacenter/dtr/2.2/guides/user/manage-images/manage-trusted-repositories.md
rename to datacenter/dtr/2.2/guides/user/manage-images/sign-images/manage-trusted-repositories.md
index d5326dfc67..61d7e5c281 100644
--- a/datacenter/dtr/2.2/guides/user/manage-images/manage-trusted-repositories.md
+++ b/datacenter/dtr/2.2/guides/user/manage-images/sign-images/manage-trusted-repositories.md
@@ -1,20 +1,48 @@
---
-description: Learn how to use the Notary CLI client to manage trusted repositories
-keywords: dtr, trust, notary, registry, security
title: Manage trusted repositories
+description: Learn how to use the Notary CLI client to manage trusted repositories
+keywords: dtr, trust, notary, security
+redirect_from:
+ - /datacenter/dtr/2.2/guides/user/manage-images/manage-trusted-repositories/
---
-Once you install the Notary CLI client, you can use it to manage your signing
-keys, authorize other team members to sign images, and rotate the keys if
-a private key has been compromised.
+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.
-When using the Notary CLI client you need to specify where is Notary server
-you want to communicate with, and where to store the private keys and cache for
-the CLI client.
+## List trust data
-```bash
-# Create an alias to always have the notary client talking to the right server
-$ alias notary="notary -s https:// -d ~/.docker/trust"
+List the trust data for a repository by running:
+
+```none
+$ 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:
+
+```none
+export DOCKER_CONTENT_TRUST=1
+docker push //
+```
+
+or
+
+```
+notary init --publish //
```
## Manage staged changes
@@ -122,5 +150,5 @@ directory where your private keys are stored, with the `-d` flag.
## Where to go next
-* [Run only the images you trust](index.md)
-* [Get started with Notary](/notary/getting_started.md)
+* [Learn more about Notary](/notary/advanced_usage.md)
+* [Notary architecture](/notary/service_architecture.md)
diff --git a/datacenter/images/dtr_repo_find_gun.png b/datacenter/images/dtr_repo_find_gun.png
deleted file mode 100644
index dd1c66516f..0000000000
Binary files a/datacenter/images/dtr_repo_find_gun.png and /dev/null differ
diff --git a/datacenter/images/signed_image_in_dtr.png b/datacenter/images/signed_image_in_dtr.png
deleted file mode 100644
index 28d8c46174..0000000000
Binary files a/datacenter/images/signed_image_in_dtr.png and /dev/null differ
diff --git a/datacenter/images/ucp_content_trust_detail.png b/datacenter/images/ucp_content_trust_detail.png
deleted file mode 100644
index 5775540ef9..0000000000
Binary files a/datacenter/images/ucp_content_trust_detail.png and /dev/null differ
diff --git a/datacenter/images/ucp_content_trust_settings.png b/datacenter/images/ucp_content_trust_settings.png
deleted file mode 100644
index e3d328704e..0000000000
Binary files a/datacenter/images/ucp_content_trust_settings.png and /dev/null differ
diff --git a/datacenter/ucp/2.1/guides/admin/configure/content-trust/admin_tasks.md b/datacenter/ucp/2.1/guides/admin/configure/content-trust/admin_tasks.md
deleted file mode 100644
index 4ed0592c00..0000000000
--- a/datacenter/ucp/2.1/guides/admin/configure/content-trust/admin_tasks.md
+++ /dev/null
@@ -1,387 +0,0 @@
----
-title: Configure the UCP and DTR servers for content trust
-description: Configuration tasks for using content trust on UCP and DTR servers
----
-
-These tasks allow an administrator to set up the UCP and DTR servers to require
-content trust and to delegate the ability to sign images to UCP users. For an
-overview of content trust in UCP, see [Run only the images you trust](index.md).
-
-After completing these steps, continue to
-[Client configuration for content trust in UCP](client_configuration.md).
-
-## Prerequisites
-
-Before completing these tasks, set up the teams for signing and add users to
-them. For instance, if your business requirement is that images need to be
-signed by `engineering`, `security`, and `quality` teams, set up those teams and
-add the appropriate users to them. See
-[Set up teams](/datacenter/ucp/2.1/guides/admin/manage-users/create-and-manage-teams.md)
-and
-[Create and manage users](/ucp/2.1/guides/admin/manage-users/create-and-manage-users.md).
-
-## Overview
-
-The administrator needs to complete the following tasks to configure UCP and DTR
-for image signing.
-
-2. [Configure UCP](#configure-ucp) to only allow signed images to be used.
-
-3. [Set up the Docker Notary CLI client](#set-up-the-docker-notary-client)
- locally so that the administrator can initialize the trusted image
- repository.
-
-4. [Initialize the trusted image repository](#initialize-the-trusted-image-repository)
- which will store trusted images.
-
-5. [Delegate image signing](#delegate-image-signing) so that the appropriate
- users are able to sign images. This step is optional, and assumes that the
- UCP administrator will not be the only one signing images.
-
-## Configure UCP
-
-This step configures UCP to only allow deployment of signed images, as well as
-the teams that must sign an image before it can be trusted. Set up the users
-and groups before starting this step.
-
-1. Go to the **UCP web UI**, navigate to the **Admin Settings** page, and click
- the **Content Trust** menu item.
-
- 
-
-2. Select the **Only run signed images** option.
-
- Click the **REQUIRE SIGNATURE FROM ALL OF THESE TEAMS** field and choose
- one or more teams. DDC will consider an image to be trustworthy only if it
- is signed by a member of _every team_ you select. The requirement can be
- fulfilled by a single user who is a member of all the teams, or by a signer
- in each team.
-
- > **Note**: If you don't specify any team (by leaving the field blank), an
- > image will be trusted as long as it is signed by any UCP user whose keys
- > are [configured in the Notary client](#set-up-the-docker-notary-client).
-
- The following screenshot shows a configuration that requires images to be
- signed by a member of the `engineering` team.
-
- 
-
-3. Click **Update** to apply the changes.
-
-UCP is now configured to only allow use of signed images, but you don't have the
-ability to sign images yet. Next,
-[set up the Docker Notary CLI client](#set-up-the-docker-notary-client).
-
-## Set up the Docker Notary CLI client
-
-After [configuring UCP](#configure-ucp), you need to specify which Docker images
-can be trusted, using the Docker Notary server that is built into Docker Trusted
-Registry (DTR). The following procedure configures the Notary server to store
-signed metadata about the Docker images you trust. This set-up step only needs
-to be done on the client of an administrator responsible for setting up
-repositories and delegating the ability to sign images.
-
-1. **If you are on a Linux client**, install the Notary binary. If you use Docker
- for Mac or Docker for Windows, the Notary client is included in your
- installation.
-
- - [Download the latest client archive](https://github.com/docker/notary/releases).
- - Extract the archive.
- - Rename the binary to `notary` and set it to executable. Either move it to
- a location in your path or modify the examples below to include the full
- path to the binary.
-
-2. Configure the Notary client to communicate with the DTR server and store
- its metadata in the correct location. You can either use a
- [Notary configuration file](/notary/reference/client-config.md) or manually
- specify the following flags when you run the `notary` command.
-
- |Flag |Purpose |
- |-------------------|------------------------------------------------------|
- | `-s ` | The hostname or IP address of the DTR server |
- | `-d ` | The path to the local directory where trust metadata will be stored |
- | `--tlscacert ` | The path to the trust certificate for DTR. Only required if your DTR registry is not using certificates signed by a globally trusted certificate authority, such as self-signed certificates. Download the trust certificate from `https:///ca` either from your browser or using `curl` or `wget`.|
-
- > **Tip**: If you don't want to provide the `-s`, `-d`, and `--tlscacert`
- > parameters each time you run a Nptary command, you can set up an alias in
- > Bash (Linux or macOS) or PowerShell (Windows) to save some typing. The
- > following examples do not include the `--tlscacert` flag, but you can add
- > it if necessary. All of the `notary` commands in the rest of this topic
- > assume that you have set up the alias.
- >
- > - **Bash**: Type the following, or add it to your `~/.profile` file to make
- > it permanent. Replace `` with the hostname or IP address of your
- > DTR instance.
- >
- > alias notary="notary -s https:// -d ~/.docker/trust"
- >
- > - **PowerShell**: Type the following, or add it to your `profile.ps1` to
- > make it permanent.
- >
- > PS C:\> set-alias notary "notary -s https:// -d ~/.docker/trust"
- >
- >
- > After setting up the alias, you only need to type `notary` and the server
- > and destination directory will be included in the command automatically.
- {: id="notary_alias_config_note" }
-
-3. Find the _globally unique name (GUN)_ for your repository. The GUN
- is the `/` string, such as
- `dtr-example.com/engineering/my-repo`. You can find the GUN for a repository
- by browsing to it in the DTR web UI and copying the part of the
- **Pull command** after `docker pull`.
-
-Next, [initialize a trusted image repository](#set-up-a-trusted-image-repository).
-
-## Initialize the trusted image repository
-
-> **Tip - Yubikey integration**: Notary supports integration with Yubikey. If
-> you have a Yubikey plugged in when you initialize a repository with Notary,
-> the root key is stored on the Yubikey instead of in the trust directory. When
-> you run any command that needs the `root` key, Notary looks on the Yubikey
-> first, and uses the trust directory as a fallback.
-
-This procedure needs to be done on the client of an administrator responsible for
-setting up repositories. It needs to be done once per signing repository.
-
-In these examples, add the `-s`, `-d`, and `--tlscacert` parameters you need
-before `` if you decided not to configure Notary using a
-[configuration file](/notary/reference/client-config.md){: target="_blank" class="_" }
-or a [terminal alias](#notary_alias_config_note").
-
-1. In the DTR web UI, create a new repository or browse to an existing
- repository that you want to reconfigure as a trusted image repository.
- Make a note of the GUN for the repository by copying the contents of the
- **Pull command** field after `docker pull`.
-
- 
-
-2. At the command line on your client, check whether Notary has information
- about the repository. Most likely if you are performing this task for the
- first time, the repository is not initialized.
-
- ```bash
- $ notary list
- ```
-
- The response may be one of the following:
-
- - `fatal: client is offline`: Either the repository server can't be reached,
- or DTR is using certificates which are not signed by a globally trusted
- certificate authority, such as self-signed certificates. Run `notary list`
- again, adding the `--tlscacert` flag, with the path to the certificate
- authority for DTR. To get the certificate, download `https:///ca`
- from your browser or using `curl` or `wget`. This certificate is
- different from the UCP trust certificate in the UCP client bundle.
-
- - `fatal: does not have trust data for ddc-staging-dtr.qa.aws.dckr.io/engineering/redis`:
- The repository has not yet been initialized and you need to run
- `notary init`. Continue to step 2.
-
- - `No targets present in this repository.`: The repository has been
- initialized, but contains no signed images. You do not need to do step 2.
-
- - A list of signed image tags, their digests, and the role of the private
- key used to sign the metadata. This indicates that the repository is configured
- correctly and images have been signed and uploaded. You do not need to do
- step 2.
-
-2. To initialize the repository, run `notary init`, setting the `-p` flag to
- the GUN of the repository. You will be prompted to set passphrases for
- three different keys:
-
- - The `root` key is used to sign the `targets` and `snapshot` keys.
- - The `targets` key will be used to sign the keys of users authorized to sign
- images and designate them as trusted.
- - The `snapshot` key is used for snapshotting the repository, which is an
- optimization for updating the trust data.
-
- ```bash
- $ notary init
-
- No root keys found. Generating a new root key...
- 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 root key with ID 717fa4b:
- Repeat passphrase for new root key with ID 717fa4b:
- Enter passphrase for new targets key with ID 776d924 ():
- Repeat passphrase for new targets key with ID 776d924 ():
- Enter passphrase for new snapshot key with ID d3cc399 ():
- Repeat passphrase for new snapshot key with ID d3cc399 ():
- Enter username: admin
- Enter password:
- ```
-
- As the help text in the command says, it's important to choose good
- passphrases and to save them in a secure location such as a password
- manager. The final username and password prompt are for the DTR login.
-
- Several important files are saved in the trust directory (the location you
- specified as the value of the `-d` flag. The following is an example listing
- of the trust directory:
-
- ```none
- ├── private
- │ ├── root_keys
- │ │ └── 92c11d487023de4447ef57747e84e7364cd7c62a4be28d8714ec05afe2f130f8.key
- │ └── tuf_keys
- │ └── dtr-example.com
- │ └── engineering
- │ └── testrepo
- │ ├── 87a129ea47a4112fec6b989bde35f6ddea8325638450d41b3f44fabaf49dbe3d.key
- │ └── aa4b236c610e3d951c930bf2a503861c41808ac28369bfbaf5c075b62cb3dd41.key
- └── tuf
- └── dtr-example.com
- └── engineering
- └── testrepo
- ├── changelist
- └── metadata
- ├── root.json
- ├── snapshot.json
- └── targets.json
- ```
-
- The `tuf` directory contains metadata needed by Notary. The `private`
- directory contains the root key, target key, and snapshots key. It is
- important to protect these keys, especially the root key. If you are using
- the Yubikey integration feature, the root key is already stored on your
- Yubikey. You should back up the entire `private` subdirectory to secure
- offline storage and remove the `root_keys` subdirectory from the trust
- directory. If you do not use a Yubikey, back up the entire trust
- directory to secure offline storage, and bring it online only when you need
- to perform Notary operations.
-
-3. The metadata has been created but only exists on your client. To publish
- it to DTR, use `notary publish`.
-
- ```bash
- $ notary publish
-
- Pushing changes to
- Enter username: admin
- Enter password:
- Enter passphrase for targets key with ID 63c2d66:
- Enter passphrase for snapshot key with ID 6ac388d:
- Successfully published changes for repository
- ```
-
- You will be prompted for the DTR login, the passphrase for the `targets` key,
- and the passphrase for the `snapshot` key.
-
-Typically, the administrator is not part of the group which is authorized to
-sign images. If you do attempt to sign images and you are not part of one of the
-correct groups, the image will not be available to UCP.
-
-Continue to [delegate image signing](#delegate-image-signing) to give the
-appropriate users the ability to sign images.
-
-You can also
-[learn more about the keys used by Notary](/engine/security/trust/trust_key_mng.md).
-
-
-## Delegate image signing
-
-The administrator who manages Docker Trusted Registry is often not part of the
-group which is allowed to sign images. This is where
-[Notary delegation roles](/notary/advanced_usage.md) come in. Delegation roles
-provide:
-
-- Simple collaboration workflows
-- Fine-grained permissions within a collection's contents across delegations
-- Ability to dynamically add or remove keys from delegation roles when
- collaborators join or leave trusted repositories
-
-When you [initialized the trusted repository](#nitialize-the-trusted-image-repository),
-three keys were created:
-
-- The `root` key signs the `targets` and `snapshot` keys.
-- The `targets` key is used by Notary for delegation roles, which act as signers.
-- Each change in the repository needs to be signed by the `snapshot` key.
-
-To avoid the need to distribute the `snapshot` key to each person who will sign
-images, you can configure the Notary server to manage it. In order to do this,
-you need to also rotate the `snapshots` key, so that private keys do not need
-to be transferred between the client and server.
-
-1. Rotate the key and configure the Notary server to manage it. This operation
- only needs to be done once for each trusted repository.
-
- ```bash
- $ notary key rotate snapshot --server-managed
- ```
-
- You are prompted for the DTR credentials followed by the passphrase for the
- `root` key.
-
-2. For each user who should be able to sign images, ask that user to create a
- client bundle. They should:
-
- 1. Go to the UCP web UI.
- 2. Click your username at the top right. Click **Profile**.
- 3. Click **Create a Client Bundle**. A file is downloaded called
- `ucp-bundle-.zip`.
- 4. Extract the zip file. The important file within the archive is the
- `cert.pem`, which is the user certificate.
- 5. Send you the `cert.pem` **through a secure, trusted channel**. If you
- plan to create more than one delegation, rename the `cert.pem` with the
- username or other identifying information.
-
-3. Run the following command to add the `targets/releases` delegation role for
- each user, using the `cert.pem` files. You can specify multiple `cert.pem`
- files at once.
-
- ```bash
- $ notary delegation add -p targets/releases --all-paths user1.pem user2.pem
- ```
-
- You will be prompted for your DTR credentials and the passphrase for the
- `targets` key.
-
- > **Note**: You can also add arbitrary delegations, but `targets/releases`
- > is a special delegation, and is treated as an actual release branch for
- > Docker Content Trust. If a Docker client has content trust enabled, and
- > the client runs `docker pull`, this delegation is what signals that the
- > content is trusted.
-
- Each user who can release images should be added to the `targets/releases`
- role.
-
-4. Create at least one more delegation and add users to it, or UCP will not
- honor the signed content. This delegation indicates the team that is signing
- the release.
-
- Docker recommends adding one delegation per team. For instance, if you have
- an `engineering` team and a `qa` team, add a delegation for each of these.
- If a user is a member of both teams, that user will be able to indicate
- which team they are signing on behalf of. Notary has no limit on how many
- delegation roles can exist.
-
- Valid delegation roles take the form of `targets/`. Do not include
- a trailing slash.
-
- The following command adds `user1` to the `targets/engineering` delegation:
-
- ```bash
- $ notary delegation add -p targets/engineering --all-paths user1.pem
- ```
-
- You will be prompted for your DTR credentials followed by the passphrase
- for the `targets` key.
-
-5. Securely remove the `.pem` files of the users you added delegations to. If
- these keys are compromised, they could be used to sign images which should
- not be trusted.
-
-
-## Next steps
-
-The Notary server is now configured to allow users to sign images. Next, each
-user needs to [configure their client](client_configuration.md)
-and [sign some images](client_configuration.md#sign-and-push-images).
-
-[Learn more about the targets/releases role](/engine/security/trust/trust_delegation.md).
diff --git a/datacenter/ucp/2.1/guides/admin/configure/content-trust/client_configuration.md b/datacenter/ucp/2.1/guides/admin/configure/content-trust/client_configuration.md
deleted file mode 100644
index ebb25e985b..0000000000
--- a/datacenter/ucp/2.1/guides/admin/configure/content-trust/client_configuration.md
+++ /dev/null
@@ -1,255 +0,0 @@
----
-title: Configure the Docker client to sign images
-description:
----
-
-After an administrator
-[configures the UCP and DTR servers for content trust](admin_tasks.md) and
-[delegates users to be able to sign images](admin_tasks.md#delegate-image-signing),
-each of those users needs to configure their system for image signing. This
-topic covers the required configuration steps, as well as how to sign and
-push images.
-
-Each user who will sign images needs to follow these steps.
-
-## Import the user's signing key
-
-Users who need to sign images should import the `key.pem` file from their UCP
-client bundle into Docker. The user probably downloaded the client bundle when
-they sent the administrator their `cert.pem` so the administrator could
-[delegate signing to them](#delegate-image-signing).
-
-Import the private key associated with the user certificate. You must specify
-the trust directory `~/.docker/private`. If the `~/.docker/private` directory
-does not yet exist, Notary will create it.
-
-- **Linux or macOS**:
-
- ```bash
- $ notary -d ~/.docker/trust key import /path/to/key.pem
- ```
-
-- **Windows**:
-
- ```powershell
- PS C:\> notary -d ~/.docker/trust key import /path/to/key.pem
- ```
-
-You are prompted for a passphrase. Save it in a secure location such as a
-password manager. You will need to provide the passphrase each time you sign an
-image.
-
-## Configure the Docker client
-
-These steps may need to be performed for each Docker user who will push images
-to the trusted repository, and also on each Docker client which should only be
-allowed to pull and use trusted images.
-
-### Linux or MacOS
-
-1. **Required**: Set the `DOCKER_CONTENT_TRUST` environment variable to `1`.
- You can do this temporarily or permanently.
-
- - To set the environment variable for the current command-line session, type
- the following into the terminal where you will be running `docker` commands:
-
- ```bash
- $ export DOCKER_CONTENT_TRUST=1
- ```
-
- This environment variable will be effective until you close the command
- prompt.
-
- - To set the environmment variable for just a single command, add it before
- the command:
-
- ```bash
- $ DOCKER_CONTENT_TRUST=1 docker pull...
- ```
-
- - To set the environment variable permanently, edit the `~/.profile` file
- and add the following line:
-
- ```bash
- export DOCKER_CONTENT_TRUST=1
- ```
-
-2. **If your DTR instance uses certificates not signed by a public certificate authority (CA)**:
- Configure the local Docker daemon and client to trust the DTR server's
- certificate. You need to do this step if you see an error like the following
- when you try to [sign and push an image](#sign-and-push-an-image).
-
- ```none
- x509: certificate signed by unknown authority
- ```
-
- This procedure is different if you are on a Linux or macOS client:
-
- - **Linux**:
-
- 1. Download the certificate add it to a subdirectory of the
- `/etc/docker/certs.d/` directory.
-
- ```bash
- $ sudo mkdir -p /etc/docker/certs.d/
-
- $ curl -k https:///ca -o .crt
-
- $ sudo mv .crt /etc/docker/certs.d//ca.crt
- ```
-
- 2. Configure the Docker client to use certificates available to the
- Docker daemon by creating a symbolic link from `/etc/docker/certs.d/`
- to `~/.docker/tls/`
-
- ```bash
- $ ln -s /etc/docker/certs.d ~/.docker/tls
- ```
-
- 3. Restart Docker using one of the following commands:
-
- - `sudo systemctl restart docker`
- - `sudo service docker restart`
-
- - **macOS**:
-
- 1. Download the certificate and name the output file
- `.crt`.
-
- ```bash
- $ curl -k https:///ca -o .crt
- ```
-
- 2. Import the certificate into the macOS keychain. This example uses the
- command line, but you can use the **Keychain Access** application
- instead.
-
- ```bash
- $ sudo security add-trusted-cert -d \
- -r trustRoot \
- -k /Library/Keychains/System.keychain \
- .crt
- ```
-
- 3. Restart Docker for Mac. Click the Docker icon in the toolbar and click
- **restart**.
-
-The Docker daemon and client now trust the DTR server. Continue to
-[Sign and push an image](#sign-and-push-an-image).
-
-### Windows
-
-1. Set the `DOCKER_CONTENT_TRUST` environment variable to `1`. You can do this
- temporarily or permanently.
-
- - To set the environment variable for the current PowerShell session, type the
- following into the PowerShell terminal where you will be running `docker` commands:
-
- ```powershell
- PS C:\> $env:DOCKER_CONTENT_TRUST = "1"
- ```
-
- This environment variable will be effective until you close the PowerShell
- session.
-
- - To set the environment variable permanently for the logged-in user, use the
- following command:
-
- ```powershell
- PS C:\> [Environment]::SetEnvironmentVariable("DOCKER_CONTENT_TRUST", "1", "User")
- ```
-
- The variable is set immediately.
-
- Whichever method you use, you can verify that the environment variable is set
- by typing `$Env:DOCKER_CONTENT_TRUST` at the command line.
-
-2. **If your DTR instance uses certificates not signed by a public certificate authority (CA)**:
- Configure the local Docker daemon and client to trust the DTR server's
- certificate. You need to do this step if you see an error like the following
- when you try to [sign and push an image](#sign-and-push-an-image).
-
- 1. Download the certificate by browsing to the URL
- `https:///ca`. The certificate is shown in the browser
- as a text file. Choose **File** / **Save As** and save the file as
- `.crt`.
-
- 2. Open Windows Explorer and go to the directory where you saved the file.
- Right-click `.crt` and choose **Install certificate**.
-
- - Select **Local machine** for the store location.
-
- - Select **Place all certificates in the following store**.
-
- - Click **Browse** and select **Trusted Root Certificate Authorities**.
-
- - Click **Finish**.
-
- 3. Restart Docker for Windows. Click the Docker icon in the Notifications
- area and click **Settings**. Click **Reset** and choose
- **Restart Docker**.
-
-The Docker daemon and client now trust the DTR server. Continue to
-[Sign and push an image](#sign-and-push-an-image).
-
-## Sign and push an image
-
-After [Configuring the signer's Notary and Docker clients](#onfigure-the-signers-otary-and-ocker-clients),
-the user can sign and push images to Docker Trusted Registry. These steps are
-the same on Linux, macOS, or Windows.
-
-1. Log into DTR.
-
- ```bash
- $ docker login
- ```
-
- You are prompted for your DTR credentials.
-
-2. Tag the image with a tag in the format `:imagename`. The following
- example tags the `ubuntu:16.04` image as `ubuntu` in your trusted
- repository. This will signal to the `docker push` command that the image tag
- contains a repository.
-
- ```bash
- $ docker tag ubuntu:16.04 dtr-example.com/engineering/testrepo:ubuntu
- ```
-
-3. Sign and push the tagged image, so that your deployments can use it. The
- following example signs and pushes the image created in the previous step.
- You are prompted for the delegation key passphrase.
-
- ```bash
- $ docker push dtr-example.com/engineering/testrepo:ubuntu
-
- The push refers to a repository [dtr-example.com/engineering/testrepo]
- 5eb5bd4c5014: Pushed
- d195a7a18c70: Pushed
- af605e724c5a: Pushed
- 59f161c3069d: Pushed
- 4f03495a4d7d: Pushed
- ubuntu: digest: sha256:4c0b138bdaaefa6a1c290ba8d8a97a568f43c0f8f25c733af54d3999da12dfd4 size: 1357
- Signing and pushing trust metadata
- Enter passphrase for delegation key with ID ff97e18:
- Successfully signed "dtr-example.com/engineering/testrepo":ubuntu
- ```
-
-4. To test pulling the image, remove it locally, then pull it.
-
- ```bash
- $ docker image remove dtr-example.com/engineering/testrepo:ubuntu
-
- $ docker pull dtr-example.com/engineering/testrepo:ubuntu
- ```
-
-5. You can verify that the image exists in the repository using the DTR web UI.
- Go to the DTR web UI and click **Repositories**. Choose the repository and
- go to **Images**.
-
- 
-
-The signed, trusted image is available in your trusted repository.
-
-## Where to go next
-
-* [Restrict services to worker nodes](restrict-services-to-worker-nodes.md)
diff --git a/datacenter/ucp/2.1/guides/admin/configure/content-trust/index.md b/datacenter/ucp/2.1/guides/admin/configure/content-trust/index.md
deleted file mode 100644
index 2af152e19e..0000000000
--- a/datacenter/ucp/2.1/guides/admin/configure/content-trust/index.md
+++ /dev/null
@@ -1,61 +0,0 @@
----
-description: Configure a Docker UCP cluster to only allow running applications that use images you trust.
-keywords: docker, ucp, backup, restore, recovery
-title: Run only the images you trust
-redirect_from:
- - /datacenter/ucp/2.1/guides/admin/configure/only-allow-running-signed-images/
----
-
-## About trusted images
-
-When transferring data among networked systems, _trust_ is a central concern. In
-particular, when communicating over an untrusted medium such as the internet, it
-is critical to ensure the integrity and the publisher of all the data a system
-operates on. Docker allows you to push images to, and pull images from, public
-and private registries.
-
-Docker provides a mechanism called
-[content trust](/engine/security/trust/content_trust.md), which you can use to
-verify that the contents of the image have been approved by people you trust,
-and to prevent untrusted images from being used in your UCP instance.
-
-### Example workflow for using trusted images
-
-An example workflow that takes advantage of content trust might look like this:
-
-1. Developers push code into source control.
-2. A CI system performs automated tests. If the tests pass, the CI system
- builds and cryptographically signs an image containing the code.
-3. A quality engineering team pulls the image signed by the CI system and
- performs quality tests on it. When the image is approved for production,
- part of the approval process is to cryptographically sign the image again.
-4. If any image is not signed both by the CI group and the QA group, UCP
- refuses to deploy it.
-
-## Configuration overview
-
-First, an administrator performs the following configuration tasks, which are
-detailed in [Server-side tasks for content trust in UCP](admin_tasks.md).
-
-1. Configure UCP.
-
-2. Configure the Notary client on the administrator's system.
-
-3. Initialize the trusted repository in DTR.
-
-4. Delegate image signing to users in the correct groups.
-
-
-Afterward, members of approved teams perform the following tasks, which are
-detailed in [Configure the Docker client to sign images](client_configuration.md):
-
-1. Set up the Docker CLI to use the signing certificates from the UCP client
- bundle and to require images to be signed when pulling them from
- repositories.
-
-2. Sign and push an image to a repository.
-
-## Next steps
-
-- [Server-side tasks for content trust in UCP](admin_tasks.md)
-- [Configure the Docker client to sign images](client_configuration.md)
diff --git a/datacenter/ucp/2.1/guides/admin/configure/run-only-the-images-you-trust.md b/datacenter/ucp/2.1/guides/admin/configure/run-only-the-images-you-trust.md
new file mode 100644
index 0000000000..394dfa8dd0
--- /dev/null
+++ b/datacenter/ucp/2.1/guides/admin/configure/run-only-the-images-you-trust.md
@@ -0,0 +1,60 @@
+---
+title: Run only the images you trust
+description: Configure a Docker UCP cluster to only allow running applications that use images you trust.
+keywords: docker, ucp, security, trust
+redirect_from:
+ - /datacenter/ucp/2.1/guides/admin/configure/only-allow-running-signed-images/
+ - /datacenter/ucp/2.1/guides/admin/configure/use-trusted-images-for-ci/
+---
+
+With Docker Universal Control Plane you can enforce applications to only use
+Docker images signed by UCP users you trust. When a user tries to deploy an
+application to the cluster, UCP checks if the application uses a Docker image
+that is not trusted, and won’t continue with the deployment if that’s the case.
+
+
+
+By signing and verifying the Docker images, you ensure that the images being
+used in your cluster are the ones you trust and haven’t been altered either in
+the image registry or on their way from the image registry to your UCP cluster.
+
+## Example workflow
+
+Here's an example of a typical workflow:
+
+1. A developer makes changes to a service and pushes their changes to a version
+control system
+2. A CI system creates a build, runs tests, and pushes an image to DTR with the
+new changes
+3. The quality engineering team pulls the image and runs more tests. If
+everything looks good they sign and push the image
+4. The IT operations team deploys a service. If the image used for the service
+was signed by the QA team, UCP deploys it. Otherwise UCP refuses to deploy.
+
+## Configure UCP
+
+To configure UCP to only allow running services that use Docker images you
+trust, go to the **UCP web UI**, navigate to the **Settings** page, and click
+the **Content Trust** tab.
+
+Select the **Run only signed images** option to only allow deploying
+applications if they use images you trust.
+
+{: .with-border}
+
+With this setting, UCP allows deploying any image as long as the image has
+been signed. It doesn't matter who signed the image.
+
+To enforce that the image needs to be signed by specific teams, include those
+teams in the **Require signature from** field.
+
+{: .with-border}
+
+If you specify multiple teams, the image needs to be signed by a member of each
+team, or someone that is a member of all those teams.
+
+Click **Update** for UCP to start enforcing the policy.
+
+## Where to go next
+
+* [Sign and push images to DTR](/datacenter/dtr/2.2/guides/user/manage-images/sign-images/index.md)
diff --git a/datacenter/ucp/2.1/guides/admin/configure/store-logs-in-an-external-system.md b/datacenter/ucp/2.1/guides/admin/configure/store-logs-in-an-external-system.md
index 7fa9313915..3871e9f03c 100644
--- a/datacenter/ucp/2.1/guides/admin/configure/store-logs-in-an-external-system.md
+++ b/datacenter/ucp/2.1/guides/admin/configure/store-logs-in-an-external-system.md
@@ -55,4 +55,4 @@ options that can accomplish this (e.g. Shield plug-in for Kibana)
## Where to go next
-* [Require all images to be signed](content-trust.md)
+* [Require all images to be signed](restrict-services-to-worker-nodes.md)
diff --git a/datacenter/ucp/2.1/guides/images/run-only-the-images-you-trust-1.svg b/datacenter/ucp/2.1/guides/images/run-only-the-images-you-trust-1.svg
new file mode 100644
index 0000000000..e3bfc41d29
--- /dev/null
+++ b/datacenter/ucp/2.1/guides/images/run-only-the-images-you-trust-1.svg
@@ -0,0 +1,109 @@
+
+
\ No newline at end of file
diff --git a/datacenter/ucp/2.1/guides/images/run-only-the-images-you-trust-2.png b/datacenter/ucp/2.1/guides/images/run-only-the-images-you-trust-2.png
new file mode 100644
index 0000000000..c91cb64ca6
Binary files /dev/null and b/datacenter/ucp/2.1/guides/images/run-only-the-images-you-trust-2.png differ
diff --git a/datacenter/ucp/2.1/guides/images/run-only-the-images-you-trust-3.png b/datacenter/ucp/2.1/guides/images/run-only-the-images-you-trust-3.png
new file mode 100644
index 0000000000..f8c48746aa
Binary files /dev/null and b/datacenter/ucp/2.1/guides/images/run-only-the-images-you-trust-3.png differ