Why are Docker Secrets considered safe?
Asked Answered
H

2

21

I read about docker swarm secrets and did also some testing. As far as I understood the secrets can replace sensitive environment variables provided in a docker-compose.yml file (e.g. database passwords). As a result when I inspect the docker-compose file or the running container I will not see the password. That's fine - but what does it really help?

If an attacker is on my docker host, he can easily take a look into the /run/secrets

docker exec -it df2345a57cea ls -la /run/secrets/

and can also look at the data inside:

docker exec -it df27res57cea cat /run/secrets/MY_PASSWORD

The same attacker can mostly open a bash on the running container and look how its working....

Also if an attacker is on the container itself he can look around.

So I did not understand why docker secrets are more secure as if I write them directly into the docker-compose.yml file?

Honewort answered 7/1, 2018 at 20:27 Comment(1)
"You can use secrets to manage any sensitive data which a container needs at runtime but you don’t want to store in the image or in source control"Ernaline
M
28

A secret stored in the docker-compose.yml is visible inside that file, which should also be checked into version control where others can see the values in that file, and it will be visible in commands like a docker inspect on your containers. From there, it's also visible inside your container.

A docker secret conversely will encrypt the secret on disk on the managers, only store it in memory on the workers that need the secret (the file visible in the containers is a tmpfs that is stored in ram), and is not visible in the docker inspect output.

The key part here is that you are keeping your secret outside of your version control system. With tools like Docker EE's RBAC, you are also keeping secrets out of view from anyone that doesn't need access by removing their ability to docker exec into a production container or using a docker secret for a production environment. That can be done while still giving developers the ability to view logs and inspect containers which may be necessary for production support.

Also note that you can configure a secret inside the docker container to only be readable by a specific user, e.g. root. And you can then drop permissions to run the application as an unprivileged user (tools like gosu are useful for this). Therefore, it's feasible to prevent the secret from being read by an attacker that breaches an application inside a container, which would be less trivial with an environment variable.

Minna answered 7/1, 2018 at 21:21 Comment(5)
Thanks for that detailed answer. Ok - it makes sense if I avoid docker-exec. But I have written a docker backup service. This container need to know the DB password and also it must provide a way to run scripts from outside the container (usually 'docker exec')Honewort
If someone can exec into the container, then they will have access to your secrets. That's the same no matter how you store them.Minna
IMHO its not very secure. As mentioned a user with exec can access them - which is pretty bad security. Basically they assume the container cannot be accessed and no process can be exploited inside that container. I would propose an extra layer of security by encrypting the passwords/secrets with public key that the app process builds at startup. I haven't seen this in the wild - if someone knows of solution that does that please let me know :-)Falsetto
@Falsetto if you're customizing the application for access to secrets, you may as well use Vault. But you still need a way to authenticate to Vault.Minna
@Minna My idea also works with vaults. The idea is that only in the process memory of the app is the key to decrypt the properties. When the process dies and starts again new public/private key identity is created for the next retrieval. This just helps not to leak unencrypted (or weakly encrypted) data into the ENV or ps.Falsetto
J
2

Docker Secrets are for Swarm not for one node with some containers or a Docker-Compose for one machine (while it can be used, it is not mainly for this purpose). If you have more than one node then Docker Secrets is more secure than deploying your secrets on more than one worker machine, only to the machines that need the secret based on which container will be running there.

See this blog: Introducing Docker Secrets Management

Jaquelin answered 7/7, 2021 at 3:17 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.