Why secrets and how they work

[zeronumbers]

1. Is podman secret solving same problem as docker secret? Are they compatible?
2. Can podman secret be used in compose? Any difference between compose providers?
3. When a secret is created from file, that file is copied? Changing original file would not change secret, original file could be deleted right?
4. Secrets basically allow you to store image in open registry where anyone can use it, even though said image requires information that should not be public?
5. If a secret information is required during build to generate files that would be in the image and would contain that secret information, then there is no point in using secret? And such image cannot be public?
6. If an image already cannot be public is there a point in using secrets for other stuff?
7. What access rights would secret file have at /run/secrets/...?
8. Secret options type can be mount or env, is env safe to use? In compose type env will be used?
9. Any examples with rootless podman compose using secrets?
10. How gpg secret should be used?

[rhatdan]

• Is podman secret solving same problem as docker secret? Are they compatible?

Yes they should be compatible.

• Can podman secret be used in compose? Any difference between compose providers?

I believe so.

• When a secret is created from file, that file is copied? Changing original file would not change secret, original file could be deleted right?

• Secrets basically allow you to store image in open registry where anyone can use it, even though said image requires information that should not be public?

Correct, or during build required a secret to access something.

• If a secret information is required during build to generate files that would be in the image and would contain that secret information, then there is no point in using secret? And such image cannot be public?

If the secret information is supposed to end up in the image, then there is no need to use a podman secret. Think of Podman Secrets as something that will not be stored in the final image.

• If an image already cannot be public is there a point in using secrets for other stuff?

That depends, you could have an image on a private registry inside your intranet, that still should not include the secret information. Also secret information might change over time, so embedding it in a container image might end up with a broken image.

• What access rights would secret file have at /run/secrets/...?

You should verify but they are world readable within the container, since a non root process might need access to the secret.
If processes other then init within the container should not have access to the secret then the init process should remove the secret or change it's permissions before it fork/execs other processes.

• Secret options type can be mount or env, is env safe to use? In compose type env will be used?

Not sure the definition of "safe" is, Both are available to the init process of the container, then that process has control over future processes inside of the container having access. The init process of the container can remove the file or environment variable if it does not want ancestor processes to have access.

• Any examples with rootless podman compose using secrets?

Ask in podman-compose repo.

• How gpg secret should be used?