Hi all,
I’ve been using ansible 1.6.x and I love it – soo much easier than how I’ve had to do things in the past 
I’m running into an issue upgrading to 1.7.x. Suddenly all my playbooks refuse to run; ansible errors out saying it needs my vault credentials. The output looks like this:
xkillac4@MHK-01:~/project/ansible$ ansible-playbook unittest.yml
ERROR: A vault password must be specified to decrypt /home/xkillac4/project/ansible/group_vars/vagrant/vault.yml
xkillac4@MHK-01:~/project/ansible$
I feel like I may be missing something obvious, and would really appreciate it if someone took a look at my example below.
I boiled the issue down into a toy project, and put it into tarball here: https://www.dropbox.com/s/gu2t7mymyeio838/ansible-testcase.tar.gz?dl=0
(or for the cautious, in a gist here: https://gist.github.com/c-nichols/aca08301235ddd5b4014
Why does my example error out? Is it expected behavior, given that I don’t need anything from the vault and am not referencing any hosts from the group with the vault? Why does this example work with ansible prior to 1.7?
What do you guys think? Am I missing something obvious?
Thanks,
Colin
Ansible will try to load any group variables things referenced by inventory, because it doesn’t know what variables you may or may not use.
If it’s not a path brought in by inventory or vars_files, etc, it would not be loaded.
Hi Michael,
My coworker posted on reddit, his synopsis is a bit shorter and sweeter: http://www.reddit.com/r/ansible/comments/2kxg9s/ansiblevault_and_multiple_vault_passwords_in_17/
How would you suggest we lay out the project/playbooks to support multiple vault passwords (and on a related note, what do you think of vxd’s suggestion in the reddit thread)?
Also, this seems like a recent development (1.7), and based on the reddit thread it seems like I’m not the only one who’s run across this – do you know what the motivation for the change was?
Thanks,
Colin
“How would you suggest we lay out the project/playbooks to support multiple vault passwords (and on a related note, what do you think of vxd’s suggestion in the reddit thread)?”
Possibly could do something like the following on the ansible command line
ansible-playbook site.yml -e @production.yml
With different vault passwords for:
production.yml
stage.yml
But right now, different files in the same run must have the same vault password.
This may imply keeping those variables out of inventory, though I’m not sure it’s possible in your case.
Is this being done because some team members might leave the team later and no longer need access to something?
Another solution might be a credential in Ansible Tower - let Tower unlock your vault, and let it give this capability to everybody on the team, but maybe everybody can’t read the file.
Those who edit the vault – and can change Tower’s knowledge of the vault password - could maybe be kept limited.
Trying to understand the use case so that might not be appropriate.
This has been a paint point for our team as well, asking for a vault password when the playbook has nothing to do with vaulted items. Wish this weren’t the case.
It’s going to be the case because we don’t know if a template will reference a variable later.
Is this being done because some team members might leave the team later and no longer need access to something?
We have 3 vaults – one each for dev, staging, and production. They contain all the same variables, just with different values. We gave them all different passwords so that our dev/staging playbooks can be deployed by “untrusted” agents (untrusted relatively speaking – e.g., CI server, temporary contractors, etc.) without revealing production secrets.
You can see why it might be confusing to me, then, to hear that ansible must include all group_vars as a sort of insurance policy. I’m new to ansible, and I haven’t seen a project laid out any other way than what I’ve described thus far. In this pattern, when the user runs the staging.yml playbook, they do not need group_vars/production/. Indeed it would be potentially harmful if it were included, possibly resulting in broken configurations if values from group_vars/staging/ were overwritten.
It sounds like I’m not the only person using ansible in this way, and I find it to be extremely convenient. I think it’s a great solution for the problem of managing secrets for multiple environments; certainly seems like an issue that’s in ansible’s wheelhouse.
If there’s a more efficient way to deal with the problem of managing secrets for multiple environments, I’d be interested in learning. I guess for now I will convert to using var_files on all my plays. I view this as a subpar solution, though, because it is considerably less maintainable.
Is there a better way to solve my issue of secrets for multiple environments, and if not would you consider reopening this as an issue, so that the workflow I described can be used?
Thanks,
Colin
Do you use the same inventory for all of your playbooks? I'm not
familiar with the change that made this pattern not work, but does it
only pull in group_vars for groups in your inventory? If you used
separate inventories for each environment would this problem go away?
Keeping your inventory in different directories solves this for you.
-i inventory/production/inventory.ini, group_vars, host_vars
-i inventory/stage/inventory.ini, group_vars, host_vars
Basically it would only see the group_vars, host_vars in that particular directory.
Host_vars could even be shared with a symlink.