What is the most secure way to provide SSL certificates (for HTTPS) to a Docker application?

The approaches I've considered:

  1. The environment

    It's common (but obviously not required) to use the 12factor approach with Docker apps, which would suggest environment variables, which are considered safe, but certificate chains can be a bit long and unwieldy for environment variables (not that this is a complete deal breaker).

  2. Private image

    I can also create a custom, private Docker image, but if I'm not using a private Docker repo (and I'm not--I'm using Docker Hub at present), that means trusting at least one other party with my secret. If I use automated builds, that means trusting yet another party (i.e. GitHub), too.

  3. A mounted volume

    This seems less kludgy than passing long environment variables that have to be processed. But up to this point, I've had no need at all for a local volume, and it seems a bit unfortunate if this is the one thing that requires me to use one. But maybe that's the price to pay for security?

From a security standpoint, what is the best option? Or are there pros and cons of these approaches I have not considered?

For reference, my current Docker image is hosted on Docker Hub, created with an automated build from GitHub, and the containers are running on Tutum. My Docker Hub and GitHub repos are private at present, but I hope to make them public later, when the project is a bit more mature. Although I'd hope for an answer that's general enough to apply more widely than in this specific setup.


3 Answers 3


One challenge with the environment variable approach is that they are shared with any linked containers (more info here), which may restrict the use of that approach in some setups.

Private images as you say are a problem as you're sharing the key to a number of parties and this could also affect your ability to use other related services which would need access to the github or docker repos (e.g. Jenkins)

This leaves the mounted volume solution, which seems like the best approach from a security standpoint. It restricts the necessary distribution to the docker host, which in most cases is less of an exposure than placing it with 3rd parties or potentially exposing it to other linked containers.


If anyone comes across this topic, note that a more recent solution might be to use Docker secrets: https://docs.docker.com/engine/swarm/secrets/

It enables Docker Swarm services to safely transmit information such as passwords, SSL certificates, etc., into containers.


2023 for Docker Compose users (yes, not entirely related to the op): https://docs.docker.com/compose/use-secrets/

Based on the docs you can add a secrets section as a sibling to your services like so:

    file: ./my_secret.txt

Then allow access only to the services required simply by adding it as in the example:

    image: myapp:latest
      - mine

Note this quote from the official guide:

The deployment of each container means Docker creates a temporary filesystem mount under /run/secrets/<secret_name> with their specific values.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .