8

Environment variables (set with -e) in Docker containers are available to every linked container.

Consider a typical use case, a database. The official MySQL image gives this example command:

docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql:tag

I have just put my password as plaintext inside an environment variable. To be sure, you need to docker inspect to see it, and if you can do that, that means you have root access to the host OS, which is game over anyhow... So let's move on.

Now I want to set up a wiki as well. Let's use this MediaWiki image. We also need to link the database:

docker run --name some-mediawiki --link some-mysql:mysql -d synctree/mediawiki

Oops! When I linked some-mysql, the environment variables propagated and now some-mediawiki can see MYSQL_ROOT_PASSWORD as well! This means that if someone were to compromise the wiki, they can potentially also find out the root password, and then get into the database with it through the link.

There has been some discussion by Docker devs about this, and the conclusion is that environment variables were never meant for sharing secrets securely anyway, and it is a mistake to use them in this way. Yet all the time I see images passing the password as an environment variable, even many official database images do this. Why?

2

A clear answer to your question can really only come from the maintainers of the individual images that are "mis"-using this feature, however some possible explanations are

  • They aren't aware of the risks. Docker is a relatively new technology to a lot of people and "best practice" isn't always clear for everyone, although the docker devs have made good efforts in this regard with things like the CIS guide
  • They're aware of the risks but have decided that it isn't a serious issue to their particular architecture. This may be the case, for example where other aspects of the system mean that the linked containers are required to trust each other, so compromise of one container leads easily to compromise of the other, regardless of environment variable sharing.
  • They're aware of the risks, but lack a better alternative. Ultimately service password management is a tricky problem to solve well and depending on the software in use on the containers, there may not be an option which the maintainers feel would work as well as using environment variables.
  • This answer works when the container is maintained by a third party, but doesn't explain the official containers. – Superbest Dec 11 '15 at 20:55
  • What specific images are you thinking about which are "official" but use a linked container setup with Environment variable passing? My expectation is that they'd fall under scenario 2 above "they're aware of the risks but don't think it's serious in their architecture" The nature of docker linked containers is that the database or back end server will likely be dedicated to the front-end app. As such all the data in the linked container is likely to already be accessible to the front end app, so access to the root password doesn't really provide a lot of additional access to an attacker. – Rоry McCune Dec 11 '15 at 22:04
0

If you are not on a multitenant machine, then this shouldn't be a problem. On the other hand compromise of one service means both get affected. This is the main reason for multi machine setups with either a separate vm or microservices someplace else.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.