Isn’t it a security risk to use /run/secrets/ ?
I think so!
But as example a database need it!
The location of the mount point within the container defaults to /run/secrets/<secret_name> in Linux containers, or C:\ProgramData\Docker\secrets in Windows containers. You can also specify a custom location.
How can i do this, specify a custom location?
And is it safe or can it be find out the location?
I think the location can be found because the secret can only be exists under the docker-path (where docker is running (docker root folder)).
There is a command (docker info) to find the docker root folder.
So it’s easy to find the secret path too.
Also i think it’s not secure to use it in compose like:
Secretes have been introduced with docker swarm and initaly only worked with them. Though, I remember that secrets work with docker-compose as well, even though the compose file refence says they don’t. It was either a docu-bug or a bug in docker-compose that they did
You can find what your are looking for here: Overview | Docker Docs. Though, from the example it does not get clear that “target” can be an absolute path.
Update: I could swear we used secrets to mount tls certificates to absolute paths. Though, I just checked the git repo: I was mistaken. Setting the target to absoulte paths does only work for “configs”
Update2: configs and secrets have two deviating behaviors: while secrets are distributed encrypted in the raft log amonst the swarm nodes, configs are distributed in clear text. While configs allow to be mounted at any path in the container, secrets are only allowed to be mounted in /run/secrets/. Inside a running container both are mounted in clear text. So secret only provides security “at rest” (in the raft log), when no container consuming it is running.
Secretes have been introduced with docker swarm and initaly only worked with them.
After looking for a solve… i found:
docker - Consume secret inside dockerfile - Stack Overflow
Secrets are available only after the build is completed. So the anwser is no, secrets can not be consume inside the dockerfile. You can consume them after the build is complete, for example in an entrypoint file that is executed when the image is run.
So it’s not possible in dockerfile but after building. Ok!
But this does not solve the problem or my question!
lets asume for a minute you would be able to mount the secret to any path: what advantage would it give you? Please think about if this advantage is more than just “security through obscurity”.
if someone gets into the the running container, the new mount location can be found with executing “mount” or taking a look at the configuration of the main application. Even if you remove everything that is able to print out the secrets content (like python, awk, sed, tr,…) , one could still use echo "$(</my/secret)"
The question is: are you trying to solve a problem with a solution that provides no advantage, thus making the problem a non problem?!
If you still feel this is a problem: kubernetes does what you are looking for.
Here is how custom targets work with stack deploy (for the sake of simplicity, the secret from the cli example is reused here and the compose.yml is embedded as here-doc string)
On both ways you can check the result by using this:
# connect to node via ssh
# or if you added the node as context:
# docker context use $(docker service ps secret_test --format '{{.Node}}')
docker exec $(docker ps -qa --filter name=secret_test) cat /test/mysecret
conclusion: the docker-compose reference 3 has a docu-bug.