moby: Incorrect mode for docker-compose secret file

Docker Compose doesn’t support real (swarmkit) secrets, and imitates them by bind-mounting the file directly into the container (which means that permissions on the host are the same as in the container).

You can change the ownership of the file on the host to match the uid/gid of the user in the container, but otherwise I don’t think there’s much that can be done unfortunately

I’ll close this issue because of the above, but feel free to continue the conversation

I think ideally the file would not be stored at all (as plain text), and used in a configuration management system or a password manager, then the secret created in advance.

Docker doesn’t need access to the file once it’s been stored as a secret (docker secret create)

If you do need the file locally, you can store it with 0400 permissions somewhere in your own home directory, so that only you (the person running docker stack deploy) has access to it.

@raratiru @niloct @JustinGuese @wbadart @MohammedNoureldin @Soberia @michitaro I see you upvoted this issue. If this is still important to you, please upvote this new feature request, and/or add your opinions there.

Docker Compose doesn’t support real (swarmkit) secrets, and imitates them by bind-mounting the file directly into the container (which means that permissions on the host are the same as in the container).

@thaJeztah, any chance for contribution in order to somehow fix this issue and make it also work in docker-compose?

However, I think this is the problem with original Elasticsearch docker image. They should add user elasticsearch to gid 0.

This ticket was about docker-compose, which does not use swarm services.

If you’re using swarm services, you can set the uid, gid and permissions when attaching a secret to service.

Looking at the elasticsearch Dockerfile (https://github.com/elastic/dockerfiles/blob/v7.10.1/elasticsearch/Dockerfile#L70-L73), the elasticsearch user has uid:gid 1000: 1000, so if you would mount the secret with uid=0 (root) and gid=1000 (elasticsearch group), then permissions 0440, it should have access.

Create a secret

echo "foobar" | docker secret create mysecret -

Create a service using the secret, that mounts it at /run/secrets/foo, with owner 0:1000, and 0440 permissions;

docker service create --name myservice \
    --secret source=mysecret,target=foo,uid=0,gid=1000,mode=0440 \
    nginx:alpine

exec into a container of the service as user 1000:1000, verify ownership/permissions are correct, and that user 1000 is able to read the secret;

docker exec -it --user 1000:1000 myservice.1.of0ct8765bouq1ystjd7ya0fi sh

$ ls -la /run/secrets/foo
-r--r-----    1 root     1000             7 Mar  4 12:10 /run/secrets/foo
$ cat /run/secrets/foo
foobar

Hi, thanks for replying 😃

Considering that in this scenario the container doesn’t run under root, and the user hasn’t sudo privileges, even if he compromises the container he wouldn’t be able to see the secret.

Right ?