I think with this release things have come full circle for me. I was part of the team that 5 years ago built Keywhiz at Square, starting the whole "secrets should be files exposed as an in-memory filesystem" thing.<p>Building it a second time was interesting. One of the biggest reasons why Keywhiz didn't go anywhere was the fact that it is incredibly hard to setup, and requires you to bring your own PKI. This time we didn't make that mistake and integrated directly into Swarm, which is the right place for it to live, and turns setting up your own PKI into a one-liner.<p>Anyway, AMA.<p>Disclosure: I work on the Docker Security team
This looks amazing. Solving secret distribution across containers will be very useful. Being able to see via `docker secret` exactly which services are using which secrets is an unexpected treat.<p>I'm a little worried about two aspects of what has been shown. From the article it shows:<p><pre><code> $ docker exec $(docker ps --filter name=redis -q) ls -l /run/secrets
total 4
-r--r--r-- 1 root root 17 Dec 13 22:48 my_secret_data
</code></pre>
From this we can tell exactly how long the secret is. If the secret service didn't do it for us, I'd like for the secrets to be null-padded to a uniform 2-4K of bytes.<p>I'm also a bit worried that the default protection on the file has it set to world-readable. Since it appears that secret distribution is independent of the container setup itself, there doesn't appear to be any way of setting ownership and permissions on this file. That is, if one were able to chmod/chown the file in the Dockerfile, running a `docker service update --secret-rm` and `docker service update --secret-add` would reset such 'fixes'.<p>A great start, and I can't wait to start using it.
This is interesting, but in my opinion, it's not quite as universally useful as some of the secret management in other security tools because you have to explicitly manage the secret within your application by reading that in-memory filesystem.<p>I'd much prefer passing a secret as an environment variable if that can be done securely. It's possible with some tools, but not out of the box with Docker itself.<p>eg, with one tool, you can do:<p># docker run --rm -e PASSWORD={supersecret_password} someimage:latest program<p>Then '{supersecret_password}' gets replaced in the container at runtime with the value stored in the tool or from an integration with a separate dedicated secret management tool like HashiCorp Vault, and value gets masked external to the container such as when running 'docker inspect' command.<p>The benefit is that you don't need to modify or maintain a lot of pre-packaged applications that read environment variables instead of looking to the contents of a file on the disk, so it just works out the box.<p>However, under ordinary circumstances, you may not want to pass secrets as environment variables in docker (or at least be careful about it). A 'docker inspect' command can show any docker user the environment variable and its value, if you don't have a tool to encrypt the contents.
Comparing this to Vault (with which I have been very satisfied):<p>The article mentions a single master key for cluster encryption. Are there any plans to split this as in Shamir's Secret Sharing?<p>How do secrets and secret authorizations renew and expire?<p>Any plans for limited-use tokens/secrets?
Comparison of this with other secretes management frameworks here <a href="https://medium.com/on-docker/secrets-and-lie-abilities-the-state-of-modern-secret-management-2017-c82ec9136a3d#.ur0pnuirw" rel="nofollow">https://medium.com/on-docker/secrets-and-lie-abilities-the-s...</a>
It would be neat if you could inject secrets as environment variables. Something like:<p><pre><code> --secret="my_secret:MY_SECRET"
</code></pre>
Obviously you could have a script that does<p><pre><code> MY_SECRET=$(cat /run/secrets/my_secret) ./whatever
</code></pre>
but a lot of existing containers can be configured via environment variables.