mirror of https://github.com/docker/docs.git
trust: use "content_trust" as trust home page
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This commit is contained in:
parent
dc81cb8bb5
commit
d105bd05ca
|
@ -153,7 +153,7 @@ guides:
|
|||
title: Using certificates for repository client verification
|
||||
- sectiontitle: Use trusted images
|
||||
section:
|
||||
- path: /engine/security/trust/content_trust/
|
||||
- path: /engine/security/trust/
|
||||
title: Content trust in Docker
|
||||
- path: /engine/security/trust/trust_automation/
|
||||
title: Automation with content trust
|
||||
|
|
|
@ -44,7 +44,7 @@ image certification and publishing process as outlined below:
|
|||
DOCKER_CONTENT_TRUST=1 docker push <image>
|
||||
```
|
||||
|
||||
2. Docker verifies the signatures to guarantee authenticity, integrity, and freshness of the image. All of the individual layers of your image, and the combination thereof, are encompassed as part of this verification check. [Read more detail about Content Trust in Docker's documentation](/engine/security/trust/content_trust/#understand-trust-in-docker).
|
||||
2. Docker verifies the signatures to guarantee authenticity, integrity, and freshness of the image. All of the individual layers of your image, and the combination thereof, are encompassed as part of this verification check. [Read more detail about Content Trust in Docker's documentation](../../engine/security/trust/index.md).
|
||||
|
||||
3. Upon a successful signature verification, Docker pulls the original image to a private, internal staging area only accessible to the Docker Hub certification team.
|
||||
|
||||
|
|
|
@ -91,5 +91,5 @@ If the Docker registry is accessed without a port number, do not add the port to
|
|||
|
||||
## Related information
|
||||
|
||||
* [Use trusted images](index.md)
|
||||
* [Use trusted images](trust/index.md)
|
||||
* [Protect the Docker daemon socket](https.md)
|
||||
|
|
|
@ -222,7 +222,7 @@ This feature provides more insight to administrators than previously available w
|
|||
the CLI for enforcing and performing image signature verification.
|
||||
|
||||
For more information on configuring Docker Content Trust Signature Verificiation, go to
|
||||
[Content trust in Docker](trust/content_trust.md).
|
||||
[Content trust in Docker](trust/index.md).
|
||||
|
||||
## Other kernel security features
|
||||
|
||||
|
|
|
@ -2,6 +2,8 @@
|
|||
description: Enabling content trust in Docker
|
||||
keywords: content, trust, security, docker, documentation
|
||||
title: Content trust in Docker
|
||||
redirect_from:
|
||||
- /engine/security/trust/content_trust/
|
||||
---
|
||||
|
||||
When transferring data among networked systems, *trust* is a central concern. In
|
|
@ -9,7 +9,7 @@ systems. To allow tools to wrap Docker and push trusted content, there are
|
|||
environment variables that can be passed through to the client.
|
||||
|
||||
This guide follows the steps as described
|
||||
[here](content_trust.md#signing-images-with-docker-content-trust) so please read
|
||||
[here](index.md#signing-images-with-docker-content-trust) so please read
|
||||
that and understand its prerequisites.
|
||||
|
||||
When working directly with the Notary client, it uses its [own set of environment variables](../../../notary/reference/client-config.md#environment-variables-optional).
|
||||
|
@ -104,6 +104,6 @@ unable to process Dockerfile: No trust data for notrust
|
|||
## Related information
|
||||
|
||||
* [Delegations for content trust](trust_delegation.md)
|
||||
* [Content trust in Docker](content_trust.md)
|
||||
* [Content trust in Docker](index.md)
|
||||
* [Manage keys for content trust](trust_key_mng.md)
|
||||
* [Play in a content trust sandbox](trust_sandbox.md)
|
||||
|
|
|
@ -482,7 +482,7 @@ No signatures or cannot access registry.example.com/admin/demo
|
|||
|
||||
## Related information
|
||||
|
||||
* [Content trust in Docker](content_trust.md)
|
||||
* [Content trust in Docker](index.md)
|
||||
* [Manage keys for content trust](trust_key_mng.md)
|
||||
* [Automation with content trust](trust_automation.md)
|
||||
* [Play in a content trust sandbox](trust_sandbox.md)
|
||||
|
|
|
@ -89,7 +89,7 @@ the new key.
|
|||
|
||||
## Related information
|
||||
|
||||
* [Content trust in Docker](content_trust.md)
|
||||
* [Content trust in Docker](index.md)
|
||||
* [Automation with content trust](trust_automation.md)
|
||||
* [Delegations for content trust](trust_delegation.md)
|
||||
* [Play in a content trust sandbox](trust_sandbox.md)
|
||||
|
|
|
@ -11,7 +11,7 @@ The sandbox allows you to configure and try trust operations locally without
|
|||
impacting your production images.
|
||||
|
||||
Before working through this sandbox, you should have read through the
|
||||
[trust overview](content_trust.md).
|
||||
[trust overview](index.md).
|
||||
|
||||
### Prerequisites
|
||||
|
||||
|
|
|
@ -296,7 +296,7 @@ updated. This feature is particularly important if you do use often-changing tag
|
|||
such as `latest`, because it ensures that all service tasks use the same version
|
||||
of the image.
|
||||
|
||||
> **Note**: If [content trust](../security/trust/content_trust.md) is
|
||||
> **Note**: If [content trust](../security/trust/index.md) is
|
||||
> enabled, the client actually resolves the image's tag to a digest before
|
||||
> contacting the swarm manager, to verify that the image is signed.
|
||||
> Thus, if you use content trust, the swarm manager receives the request
|
||||
|
|
Loading…
Reference in New Issue