-
Notifications
You must be signed in to change notification settings - Fork 5.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Secrets fail to set the uid
, gid
and mode
specified in docker-compose.yml
#9648
Comments
Same thing happens to me. I'm trying to use secrets to workaround having to set the permissions on the host file, by setting the mode in the secret, but it end up with the exact same permissions of the host. This issues comes up for me when using a keyfile for MongoDB replica authentication. The keyfile must not be world-readable, and in *nix this is easy to fix, in Windows (docker-desktop) it's not, so I was hoping that using secrets might fix the problem. It seems not |
As bind mounts do not support different permissions (uid, gid and mode), I suspect that in order to support this, the content of such secrets must be copied into the container (as in #9553), or, use POSIX ACLs (more complex). Am I right @ndeloof? |
well secrets and configs arent writeable (as per specification) so no reason why the implementation cant actually be a copy. |
I'm using a secret for a SSH Private Key that must have a 0400 mode. Setting the uid, gid and mode is a requirement.
|
Same issue applies both to Compose v1 and v2 A possible alternative I can imagine is to replace this approach with a |
In my own opinion, having to rebuild the image to change a secret isn't an option. Major issue? Not now because we haven't reach the production, we're still developing. But once in production, it will be a security concern. The access to the container repository isn't as secure as the access to the production host. Somebody pulling the image will have access to the private keys. Not a good thing at all ! There must be control over the uid, gid and mode for a secret file. |
This is not my proposal: compose would copy the secret into the container (not image) after creation, and before start. This is how secret based on environment is implemented already. |
Oh, my bad ! Sorry 'bout that ! |
So if a secret change, we need to restart the container. Am I right ? |
yes indeed |
Does it implies a redeploy of the container or just the starting phase will be enough ? It would be great if a refresh can be triggered manually (ex: docker compose refresh-secrets) to redo the copy in the container. Having a watchdog to do this automatically may consume resources unnecessary. Secrets don't change often but being able to update them without a restart can be a good solution. |
we could copy secret again at any time, or have a dedicated command for this purpose, but the more obvious one would be to trigger a container |
As long as the secret file can be updated on the fly and still have the good |
I agree with the suggestion on a copy implementation, my use case is local
development since I want to align local dev with a production swarm and a
quick restart on local is totally acceptable to me.
…On Thu, Dec 15, 2022, 16:14 Mario Gravel ***@***.***> wrote:
As long as the secret file can be updated on the fly and still have the
good uid, gid and mode, I'm good !
—
Reply to this email directly, view it on GitHub
<#9648 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABAXP2FJAB2TJB5D2UDM2BDWNMRVRANCNFSM53PZWJBQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
I was testing out the secrets functionality using docker compose version 2.14.1 today and was surprised to learn that they don't work the way the docs say they should.
This also seems to affect |
Marking this issue as "kind/enhancement" as secrets never have supported having uid/gid set by compose (v1 or v2), this feature was introduced and only supported by docker swarm |
Can confirm this failing behavior (setting mode, uid & gid) which is not working for me too.
I came across this when I wanted to mount a private ssh key to the checkmk/check-mk-raw container via docker compose secrets and specify uid, gid & mode for the key, when I got the same UNPOTECTED KEY warning when executing ssh manually. |
@peterge1998 the key thing about the docs is the explicit wording
a |
It would be nice if this was supported when using So if anyone gains access they can read the secrets in question without gaining root access. |
Indeed - you can copy, but then your project configuration can't be expressed purely from a declarative compose file, and needs to be "booted" from a shell script or equivalent. This makes it less easy to transfer it between environments. |
sure, I'm not suggesting here to write your own hack-ish script to use |
Exactly, my hope as well! |
unfortunately this approach is currently blocked by moby/moby#34142 |
I assume the |
@nicholastulach exact, build time secrets are implemented by buildkit |
That was totally unclear to me. Can we make more explicit which features are only supported with docker swarm? |
@noahehall The docs quoted is present in Services top-level element where clearly the word Therefore, I would argue that As @bodograumann says, if this is really a feature exclusive to docker swarm, it should be stated explicitly, or even removed from the document "Services top-level element" until it is actually something supported by |
@marcpa00 the compose specification is not intended to only cover docker compose features, that's fine some feature only apply to an alternative tool (whenever docker swarm doesn't use the compose specification) as long as docker compose warn users about unsupported features. Also, docker compose may be able to implement this feature once docker engine allows setting uid/gid on mounts, which has been discussed already. In the meantime, this is already available for environment-based secrets. |
@ndeloof Would it be possible to utilize a tmpfs mount, which allows some control of the mountpoint ownership (#3425 (comment)), in conjunction with the "volume with some initial content" idea that was mentioned for configs (#8707 (comment))? Somewhat of a naive question, as I'm not familiar with how Docker Compose is implemented at a systems level, or if a tmpfs would cause issues with scenarios like, e.g., host/container restarts. |
Any updates? I am running into this issue with Docker version 24.0.6, build ed223bc.
Executing commands within container
|
The permissions of the initial file are used in the container. The problem is when you need to mount the secret in two container which want non compatible permissions eg. 400 in one and 440 in the other. |
latest docker compose release warn you about this feature not being supported
the reason is that secrets are implemented as bind mounts, which comes with this limlitation. |
The documentation says mode, uid, and gid all work for compose services for both configs and secrets: Why is this issue being closed as "not planned". It is critical that files be loaded into the container with controlled / explicit permissions. Go try running filebeat with a custom filebeat.yml file loaded in without setting the permissions on the file correctly and see how far you get. What possible excuse can there be for this commitment to be backed out on? Loading files into the service without control of permissions is absurd. |
@quarky42 compose specification is a vendor-neutral definition of the compose file format, it doesn't define implementation details and limitation by Docker Compose. |
I feel like the confusion around this is warranted. The documentation that one would use for building a docker-compose.yaml doesn't indicate anywhere that there's a split in how secrets work when you use docker compose vs swarm. It's defined in the specification, and seemingly works partially in docker compose because of the aforementioned "bind mount hack"....though there's no indication via the documentation that any such hack is why it works in docker compose. |
That's indeed a major challenge we have to address regarding inclusion of the Compose Specification in Docker docs, as then we miss "implementation details" |
I'm found solution:
Dirty hack, but acceptable for me. |
Is there any roadmap for this feature (I needed this with configs, not secrets)? |
This error actually was more confusing than helpful to me, and is what led me to finding this discussion. It is seemingly counter to the Compose documentation, which makes it seem like they are supported. Only reading through this entire discucssion did I learn that the Docker team uses the term I'll add my $0.02 that this seems to be a severe limitation to Docker Compose Secrets and implementation should be reconsidered. This leaves the use of secrets at the whim of the image maintainer as to whether they build in a fashion that allows for access or not. For example, in the formal Postgres docker container, they run all entrypoints as a |
Description
Docker secrets specified using the long syntax for the
docker-compose.yml
file fail to set the specifieduid
,gid
andmode
.Also, from the docs, the default value of the
uid
andgid
fields should be the user that runs the container however the value remains whatever was set on the host machine.Steps to reproduce the issue:
Dockerfile
docker-compose.yml
somefile.txt
)docker compose run secrets-tester
Describe the results you received:
Received Output:
Describe the results you expected:
Expected Output:
Additional information you deem important (e.g. issue happens only occasionally):
Same behavior is observed in these cases:
tester
usersource
andtarget
names for the file indocker-compose.yml
uid
andgid
forroot
uid
andgid
mode
Output of
docker compose version
:Output of
docker info
:Additional environment details:
The text was updated successfully, but these errors were encountered: