My Tomcat Container needs data that has to be well protected, i.e. passwords for database access and certificates and keys for Single Sign On to other systems.
I´ve seen some suggestions to use -e
or -env-file
to pass secret data to a container but this can be discovered with docker inspect (-env-file
also shows all the properties of the file in docker inspect).
Another approach is to link a data container with the secrets to the service container but I don´t like the concept of having this data container in my registry (accessible for a broader range of people). I know I can set up a private registry, but I would need different registries for test and production and still everyone with access to the production registry could access the secret data.
I´m thinking about setting up my servers with a directory that contains the secret data and to mount the secret data into my containers. This would work nicely with test- and production servers having different secrets. But it creates a dependency of the containers to my specific servers.
So my question is: How do you handle secret data, what´s the best solution to that problem?
If you want to pass secret information to your Docker build, make sure to give BuildKit and its secret mount type a look. You'll be able to access your secrets during specific RUN commands, and if your command doesn't put traces into the image layer, your secrets are safer than before.
Don't share secrets anywhere they aren't absolutely needed. Implement role-based access control (RBAC). Adhere to the principle of least privilege, where an application only has access to the secrets it needs — no more, no less. Limit secret access to the processes running inside a given container.
When you create a Secret with kubectl create -f secret. yaml , Kubernetes stores it in etcd. The Secrets are stored in clear in etcd unless you define an encryption provider. When you define the provider, before the Secret is stored in etcd and after the values are submitted to the API, the Secrets are encrypted.
Update January 2017
Docker 1.13 now has the command docker secret
with docker swarm.
See also "Why is ARG
in a DOCKERFILE
not recommended for passing secrets?".
Original answer (Sept 2015)
The notion of docker vault
, alluded to by Adrian Mouat in his previous answer, was actively discussed in issue 1030 (the discussion continues on issues 13490).
It was for now rejected as being out of scope for docker, but also included:
We've come up with a simple solution to this problem: A bash script that once executed through a single
RUN
command, downloads private keys from a local HTTP server, executes a given command and deletes the keys afterwards.Since we do all of this in a single
RUN
, nothing gets cached in the image. Here is how it looks in the Dockerfile:
RUN ONVAULT npm install --unsafe-perm
Our first implementation around this concept is available at
dockito/vault
.To develop images locally we use a custom development box that runs the Dockito Vault as a service.
The only drawback is requiring the HTTP server running, so no Docker hub builds.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With