A secret is a sensitive piece of data, such as a password or a certificate, that should not be transmitted over a network or stored unencrypted. You can use Docker secrets to centrally manage this data and securely transmit it to only those containers that need access to it.
Secrets are encrypted during transit and at rest and are only accessible to the running services that have been granted explicit access. Secrets are available in Docker swarm and compose, where they can be implemented as follows:
version: "3.9" services: db: image: database secrets: - db_password secrets: db_password: file: db_password.txt
This example creates a container service using a secret in a compose file. When deploying, Docker creates the
db_password secret with the content from the
db_password.txt file and mounts it as a file under
/run/secrets/<secret_name> in the
db service that uses it. These files are never retained on disk but are managed in memory.
Until version 18.09, Docker didn’t provide an official way to secure the passage of sensitive information at build time.
Contrary to popular belief, it is unsafe to pass sensitive data as environment variables at build time using
--build-arg. The build-time environment variables were not designed to handle secrets, and sensitive material can easily be disclosed by running docker history against the image.
From Docker version 18.09 and API version 1.39 onwards, the Docker client provides the
--secret argument to the Docker build command to secure the passage of sensitive material at build time.