Link Search Menu Expand Document

Sensitive Information Disclosure in Docker

Play SecureFlag Play Docker Labs on this vulnerability with SecureFlag!

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.