Can use Docker secrets without Docker Swarm

[chughts]

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]

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]

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]

@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]

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]

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

[rd-zahari-aleksiev]

By the way, why the DEVELOPER image doesn't just has default password "passw0rd" ? And only when you need to override it, to play around with secrets, docker-compose, swarm....?

[arthurbarr]

IBM no longer uses default credentials for security reasons. For example, it can be too easy to accidentally use a developer image in a production environment and compromise your system, or to be unaware of the default credential (there are many network endpoints which could have such credentials, even in MQ), and thus create a vulnerability.