Sensitive Information Disclosure in Docker
Secrets
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.
Build Secrets
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.