github.com/kobeld/docker@v1.12.0-rc1/docs/security/trust/trust_automation.md (about) 1 <!--[metadata]> 2 +++ 3 title = "Automation with content trust" 4 description = "Automating content push pulls with trust" 5 keywords = ["trust, security, docker, documentation, automation"] 6 [menu.main] 7 parent= "smn_content_trust" 8 +++ 9 <![end-metadata]--> 10 11 # Automation with content trust 12 13 Your automation systems that pull or build images can also work with trust. Any automation environment must set `DOCKER_TRUST_ENABLED` either manually or in a scripted fashion before processing images. 14 15 ## Bypass requests for passphrases 16 17 To allow tools to wrap docker and push trusted content, there are two 18 environment variables that allow you to provide the passphrases without an 19 expect script, or typing them in: 20 21 - `DOCKER_CONTENT_TRUST_ROOT_PASSPHRASE` 22 - `DOCKER_CONTENT_TRUST_REPOSITORY_PASSPHRASE` 23 24 Docker attempts to use the contents of these environment variables as passphrase 25 for the keys. For example, an image publisher can export the repository `target` 26 and `snapshot` passphrases: 27 28 ```bash 29 $ export DOCKER_CONTENT_TRUST_ROOT_PASSPHRASE="u7pEQcGoebUHm6LHe6" 30 $ export DOCKER_CONTENT_TRUST_REPOSITORY_PASSPHRASE="l7pEQcTKJjUHm6Lpe4" 31 ``` 32 33 Then, when pushing a new tag the Docker client does not request these values but signs automatically: 34 35 ```bash 36 $ docker push docker/trusttest:latest 37 The push refers to a repository [docker.io/docker/trusttest] (len: 1) 38 a9539b34a6ab: Image already exists 39 b3dbab3810fc: Image already exists 40 latest: digest: sha256:d149ab53f871 size: 3355 41 Signing and pushing trust metadata 42 ``` 43 44 When working directly with the Notary client, it will use its [own set of environment variables](/notary/reference/client-config.md#environment-variables-optional). 45 46 ## Building with content trust 47 48 You can also build with content trust. Before running the `docker build` command, you should set the environment variable `DOCKER_CONTENT_TRUST` either manually or in a scripted fashion. Consider the simple Dockerfile below. 49 50 ```Dockerfile 51 FROM docker/trusttest:latest 52 RUN echo 53 ``` 54 55 The `FROM` tag is pulling a signed image. You cannot build an image that has a 56 `FROM` that is not either present locally or signed. Given that content trust 57 data exists for the tag `latest`, the following build should succeed: 58 59 ```bash 60 $ docker build -t docker/trusttest:testing . 61 Using default tag: latest 62 latest: Pulling from docker/trusttest 63 64 b3dbab3810fc: Pull complete 65 a9539b34a6ab: Pull complete 66 Digest: sha256:d149ab53f871 67 ``` 68 69 If content trust is enabled, building from a Dockerfile that relies on tag without trust data, causes the build command to fail: 70 71 ```bash 72 $ docker build -t docker/trusttest:testing . 73 unable to process Dockerfile: No trust data for notrust 74 ``` 75 76 ## Related information 77 78 * [Content trust in Docker](content_trust.md) 79 * [Manage keys for content trust](trust_key_mng.md) 80 * [Delegations for content trust](trust_delegation.md) 81 * [Play in a content trust sandbox](trust_sandbox.md) 82