ansible >=1.7 fails unnecessarily by trying to open irrelevant vaults?

[Colin Nichols]

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

[Michael DeHaan]

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.

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/dca55946-e774-4e4c-9bc8-a3fce732ef0e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Colin Nichols]

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

[Michael DeHaan]

"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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/957ad3da-09f3-474d-82d2-41bffd82fcd6%40googlegroups.com.

[Michael DeHaan]

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.

[Barry Morrison]

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. 

[Michael DeHaan]

It's going to be the case because we don't know if a template will reference a variable later.

--

You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/c7f80063-6e17-4499-80dd-bb248294f36e%40googlegroups.com.

[Colin Nichols]

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

[Michael Peters]

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?

> https://groups.google.com/d/msgid/ansible-project/046a6ad2-80a1-4d74-821b-9385698b6b21%40googlegroups.com.

[Michael DeHaan]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAJQqANcZQWLuYi%3DcTz-1B4r2V%3DO%2BhqFtsqisAoOLQ_58TJpOYA%40mail.gmail.com.