I’m trying to figure out what the best way to provide a vault password for a CI process is. My organization uses Azure Devops, where it is standard to create a secret environment variable, and make that available to the agent which runs my Ansible playbooks. This is also common to other CI systems I have used such as Gitlab, Bamboo, Jenkins, and Github Actions.
I found this issue in which someone claimed that it was insecure to store secrets in environment variables and used that as justification for closing the ticket - however in the typical access pattern this makes my CI pipeline less secure, since I still provide the secret as an environment variable - but now Ansible also forces me to write the secret to disk, introducing another set of vulnerabilities to my application (especially since the agent may be running on shared hardware.)
Environment variables seem like the industry-standard mechanism in CI for sharing secrets with an agent process to run things like Ansible playbooks. It’s perplexing that Ansible has chosen not to support this. There is a workaround, but it’s very frustrating that the workaround actually decreases the security of the system relative to the straightforward solution of Ansible simply expecting a standard environment variable for the password. I’m rather perplexed and frustrated by the decision to close https://github.com/ansible/ansible/issues/45214
Wait, I think the advice in https://github.com/ansible/ansible/issues/45214#issuecomment-502300660 is flat-out wrong. Ansible doesn’t evaluate the bash, it just uses the script as the password. That is really dangerous to have that given out as “the way to do it.” People will think it’s right and end up basically using no password.
There is an obvious workaround that involves writing the password to a temp file, but again, this makes the entire system less secure.
This is a really bad interface that IMO shouldn’t even be there. It is incredibly easy to misuse and seems really complicated feature which seems to exist for the purpose of not adding a simple and easy-to-use feature.
At the least, the overloading of --vault-password-file seems wrong. There should be a separate option --vault-password-script. (Though again, this seems like a very complicated way to avoid adding a simpler feature that would be better and easier to use.)
At the least, the overloading of --vault-password-file seems wrong. There should be a separate option --vault-password-script. (Though again, this seems like a very complicated way to avoid adding a simpler feature that would be better and easier to use.)
Well, it is more or less consistent with the way --inventory works.
Inventory has a better failure mode though. If you forget to set the executable bit on your inventory plugin, your playbook is almost certain to fail. Even if it succeeds, you will probably notice nothing happened. If you forget to set the executable bit on a vault password plugin, the plugin source code will be used as the password and you will be none the wiser that your vault is basically obfuscated and not meaningfully encrypted at all.