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
Wrong Podman Secret Creation Behavior #741
Comments
I'm not sure I understand what is the problem, the docs says:
It should be value, not the file path. If you want to use file path it will be a feature request, but currently everything works as designed and documented. |
@sshnaidm Yes, the documentation inside this repo does mention what you cited above, but I am referring to Podman's documentation of the secret subcommand and how it is intended to be used. As I understand it, Ansible modules are wrappers for the actual underlying program (in this case Podman with the secret subcommand) and are supposed to mimic the original functionality as closely as possible with some extra checks (exit status, etc.). But this module says that it uses the driver file by default (like Podman) which Podman originally refers to as an actual file containing the secret. This module, however, does not honor the option driver with the file value in the same sense as Podman originally. The documentation on both containers.github.io and docs.ansible.com mentions:
But using this option explicitly (driver: file) does still use a literal string provided in the actual Yaml/Playbook which partially defeats the Podman secret functionality which tries to separate sensitive data from configuration files (be it podman-compose files, Containerfiles, or Ansible Playbook's which easily can wind up committed into repos). In other words, the option driver with the value file should read from the passed file. Otherwise, I do not see any meaning in having the option if everything is going to be passed as stdin. I would even consider this somewhat of a security risk due to how one transitioning from writing I see two ways this could be tackled:
Alternative 1 does add an extra driver value (stdin) and encompasses breaking changes but makes it clear that either the file contents are being used as a secret or the literal string value in the data option. Alternative 2 adds an extra option for file content usage and warns users in the documentation of the deviation from the original subcommand. I would, even though it encompasses breaking changes, recommend the first alternative just because it makes this sensitive topic more "idiot-proof" from misconfigurations. |
I strongly object to the first option, it's totally clear parameter name |
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
The containers.podman.podman_secret module does not use the default driver file correctly. The passed data value is not being used as a path to the secret file, as expected, but as a literal string. This means that Podman registers the secret as "/path/to/secret" instead of "some-password" (contents of the file). According to the Podman documentation (https://docs.podman.io/en/latest/markdown/podman-secret-create.1.html) the behavior should be: "...Create accepts a path to a file, or -, which tells podman to read the secret from stdin...". It looks like the stdin '-' option is hardcoded in this module.
Steps to reproduce the issue:
The output from the above command will show
"SecretData": "/tmp/some_password.secret"
(but should instead show"SecretData": "super_secret_password"
).Execute the command natively with Podman Secret:
Version of the
containers.podman
collection:Either git commit if installed from git:
git show --summary
Or version from
ansible-galaxy
if installed from galaxy:ansible-galaxy collection list | grep containers.podman
Output of
ansible --version
:Output of
podman version
:The text was updated successfully, but these errors were encountered: