Security risk using /run/secrets/ (in 2020)?

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:

environment:
MYSQL_ROOT_PASSWORD_FILE: /run/secrets/db_root_password
MYSQL_DATABASE: wordpress
MYSQL_USER: wordpress
MYSQL_PASSWORD_FILE: /run/secrets/db_password

So how to use it secure?

For me it’s interesting in all three ways (dockerfile, docker compose and docker swarm).

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 :slight_smile:

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! :wink:

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.

I am sure that there is a solution for this. Just because you don’t know it doesn’t mean there isn’t! :wink:

I only say secret files and folders. :zipper_mouth_face:
But i want to hear it from users that are familiar with docker security.

I am curious to see how this one plays out :slight_smile: Good luck!

You can read it from someone who understand how to test it :wink:

Here is how custom targets work with docker service on the cli

echo "mysecret" | docker secret create mysecret -
docker service create -t --name secret_test  --secret source=mysecret,target=/test/mysecret ubuntu

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)

cat <<EOF | docker stack deploy -c - secret
version: '3.4'
services:
  test:
    image: ubuntu
    deploy:
      replicas: 1
    tty: true
    secrets:
      - source: mysecret
        target: /test/mysecret
        mode: 0444

secrets:
  mysecret:
    external: true
EOF

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.

Thanks, but this only compose mode!
You also assume that the container runs as root!
You completely ignore that I asked how to make it safe!

Thanks but no Thanks!

Ignorance is a blessing, isn’t it :slight_smile:

Good luck!