docker
/
docs
mirror of https://github.com/docker/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Fixed formatting, added another row for testing before completing table.

This commit is contained in:
Anne Henmi 2018-10-17 09:00:03 -06:00
parent c9296ab1c9
commit 1ba6e4f414
1 changed files with 23 additions and 34 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

57
engine/security/trust/content_trust.md
View File

@ -19,41 +19,11 @@ ability to use digital signatures for data sent to and received from remote
Docker registries. These signatures allow client-side verification of the
integrity and publisher of specific image tags.
Currently, content trust is disabled by default. To enable it, set
the `DOCKER_CONTENT_TRUST` environment variable to `1`. Refer to the
[environment variables](../../reference/commandline/cli.md#environment-variables)
and [Notary](../../reference/commandline/cli.md#notary) configuration
for the docker client for more options.
Once content trust is enabled, image publishers can sign their images. Image consumers can ensure that the images they use are signed. Publishers and consumers can be individuals alone or in organizations. Docker's content trust supports users and automated processes such as builds.
When you enable content trust, signing occurs on the client after push and
verification happens on the client after pull if you use Docker CE. If you use
Docker EE with UCP, and you have configured UCP to require images to be signed
before deploying, signing is verified by UCP.
To enforce Docker to run only signed images, configure the `daemon.json` file:
```
{
...
“content-trust”: {
“trust-pinning”: {
“root-keys”: {
“myregistry.com/myorg/*”: [“keyID1”, “keyID2”],
“myregistry.com/otherorg/repo”: [“keyID3”]
},
“official-images”: true,
},
“skip-check-on-run”: true,
“allow-expired-trust-cache”: true,
}
}
```
xxx - add configuration table here or xref- xxx
### Image tags and content trust
An individual image record has the following identifier:
@ -160,7 +130,20 @@ these various trusted operations:
### Enabling Content Trust in Docker Engine Configuration
The signature verification feature is configured in the Docker daemon configuration file `daemon.json`.
Currently, content trust is disabled by default. To enable it, set
the `DOCKER_CONTENT_TRUST` environment variable to `1`. Refer to the
[environment variables](../../reference/commandline/cli.md#environment-variables)
and [Notary](../../reference/commandline/cli.md#notary) configuration
for the docker client for more options.
Once content trust is enabled, image publishers can sign their images. Image consumers
can ensure that the images they use are signed. Publishers and consumers can be individuals
alone or in organizations. Docker's content trust supports users and automated processes
such as builds.
The signature verification feature is configured in the Docker daemon configuration file
`daemon.json`.
```
{
@ -179,16 +162,22 @@ The signature verification feature is configured in the Docker daemon configurat
}
```
| Stanza | Description |
| ***Stanza*** | ***Description*** |
| ----------------------- |---------------|
| trust-pinning:root-keys |A mapping of image globs to root key IDs which should have signed the root metadata of the image trust data. These key IDs are canonical IDs; root keys in DCT are certificates tying the name of the image to the repo metadata, so each one’s ID is different per repo. The ID of the private key (the canonical key ID) corresponding to the certificate though is the same no matter what the name of the mage.
| `trust-pinning:root-keys` |A mapping of image globs to root key IDs which should have signed the root metadata of the image trust data. These key IDs are canonical IDs; root keys in DCT are certificates tying the name of the image to the repo metadata, so each one’s ID is different per repo. The ID of the private key (the canonical key ID) corresponding to the certificate though is the same no matter what the name of the mage.
If this setting is provided, any image not matching one of these globs will not be trusted at all (with the optional exception of official images - see below)
If an image’s name matches more than one glob, then the most specific (longest) one is chosen.
***Note:*** the Docker Trust CLI or some other tool needs to be able to provide these canonical key IDs,
as opposed to just the regular key IDs |
|`trust-pinning:library-images` |
Docker EE will have the docker official images root key ID hard-coded. If this option is turned on, users will not have to look up the key ID of the Docker official library images (excluding DTR/UCP) and include it in their `trust-pinning:root-keys` setting - this will pin the official libraries (`docker.io/library/*`) to that hard-coded root key, and the official images will be trusted by default in addition to whatever images are specified by `trust-pinning:root-keys`.
Certified images from Docker Store and DTR/UCP would be considered for a future feature.
If `trustpinning:root-keys` specifies a key mapping for `docker.io/library/*`, those keys will be preferred for trust pinning. Otherwise, if a more general `docker.io/*` or `*` are specified, the official images key will be preferred.|
### Enable and disable content trust per-shell or per-invocation