Skip to content
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

Can use Docker secrets without Docker Swarm #588

Open
chughts opened this issue Oct 31, 2024 · 5 comments
Open

Can use Docker secrets without Docker Swarm #588

chughts opened this issue Oct 31, 2024 · 5 comments
Assignees

Comments

@chughts
Copy link

chughts commented Oct 31, 2024

The statement

Docker secrets are only available via Docker Swarm services, hence to create a secret using docker, Docker Swarm must be used.

in docs/developer-config.md is not true.

It is also possible to use compose with both Docker and Podman the secrets end up in the same place /run/secrets. Though this does necessitate a docker-compose.yaml file.

@arthurbarr
Copy link
Member

Thanks @chughts. @RamSubbarao could you please update this doc? Relevant link confirming that Docker Compose can also be used: https://docs.docker.com/compose/how-tos/use-secrets/

@chughts
Copy link
Author

chughts commented Nov 7, 2024

Thanks @arthurbarr

Some additional notes: I think an improved example of creating a secret would be:

ADMIN_SECRET=passw0rd podman secret create --env=true mqAdminPassword ADMIN_SECRET

A Posix of 0777 is too permissive, and only read is needed, the default is 0444, which is better, so either use mode to be more restrictive, or use the default, and I don't think type=mount is needed. In which case the run command simplifies to:

podman run --secret mqAdminPassword --secret mqAppPassword --env LICENSE=accept --env MQ_QMGR_NAME=QM1 --publish 1414:1414 --publish 9443:9443 --detach --name QM1  icr.io/ibm-messaging/mq:latest

@arthurbarr
Copy link
Member

@chughts why do you suggest that creating the secret via an environment variable would be an improvement? The reason we're moving away from environment variables in the first place, is that they're considered insecure. I agree that the stdin method is also insecure, but the secure ways of doing it (e.g. via GPG) are more cumbersome.

@chughts
Copy link
Author

chughts commented Nov 14, 2024

By using (Linux & MacOS only) ```` ADMIN_SECRET=passw0rd podman secret create --env=true mqAdminPassword ADMIN_SECRET ````

on one line only, the password is in an environment variable only for the length of time it takes to construct the secret. Whereas piping it into a file, requires removal of the file.

scratch that, its the equivalent of

printf "passw0rd" | podman secret create mqAdminPassword -

but imho easier on the eye.

ADMIN_SECRET=passw0rd podman secret create --env=true mqAdminPassword ADMIN_SECRET

and is an environment variable only for the length of time it takes to construct the secret.

@arthurbarr
Copy link
Member

Yes, it's only for a short time, but then with the printf technique it's never in the environment (but would be in the ps output). So it's a case of choosing the lesser of two evils. I'm inclined to think that given we're consciously making this change specifically to avoid secrets in environment variables, that we'll stick with the printf technique for now, but say that it's just one technique. We will update the mount permissions though. FYI @RamSubbarao

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants