Docker Security Cheat Sheet


Alternative Text by

The accompanying blog, that forms the notes for this cheat sheet, can be read here.

Adrian Mouat gives an excellent talk called ‘Using Docker Safely’. He will do it this Friday at GOTO; Amsterdam. If you get a chance to see it, you should.

As part of security week, we have summarised Adrian’s guidelines onto a cheat sheet, which you can download in high resolution by clicking on the image below. You can also visit us our booth at GOTO; this week and grab a hard copy.


  1. You suggest running Vault or Keywhiz for secrets; presumably inside the container. But any secrets API requires a client authentication, which must be passed into the Docker container. So, that’s still a secret that needs to be propagated into the container; and presumably, an API key to Vault or Keywhiz is actually more powerful than the secrets themselves.

    I don’t see how using volumes to pass secrets is any more secure than using the environment, since the volume on the host is going to be accessible to the root user just like the process environments. In fact, I have always felt that it’s less secure to use volumes, because when you place a secret onto a disk, there’s always the possibility that the permissions may be wrong, or the secret might be stolen by cloning the volume.

    • Hi Kevin,

      I address these points towards the end of this talk (around 29 mins), which also includes some input from Diogo Monica from Docker (previously Square) on the keywhiz solution

      You are of course completely right that a key-value store will require authentication. One way way to handle this is to use a secret that can only be used once. That way it doesn’t matter as much if you use an environment variable or file to pass in the secret; once it’s been used it doesn’t matter if other people can read it. Because solutions such as vault and keywhiz allow a greater level of control of secrets (think leases, “break glass” procedures, auditing, only providing access to certain secrets to containers with certain labels or IPs), I would argue that access to key-value store is not necessarily more powerful than the secrets themselves.

      The biggest issue with putting secrets in files is that they can get checked into source-code control by accident, so I’m not really a big fan. But IMO it’s better than environment variables in docker, which are visible to docker inspect and are given to any linked container.

  2. “The biggest issue with putting secrets in files is that they can get checked into source-code control by accident”

    Guess where the environment variables end up being stored… Most of the time they end up being stored in files too, so you have the exact same problem 🙂 If you are lucky the files with the env vars will be checked into a different repository (a devops repo instead of the app repo).

Leave a Reply

Your email address will not be published. Required fields are marked *