Ansible Vault is now merged into devel (1.5)

We just merged a new feature called “Ansible Vault” to devel (1.5). Please read through Michael Dehaan’s blog post about the tools for basic usage:

http://blog.ansibleworks.com/2014/02/19/ansible-vault/

Follow the typical bug reporting process for any issues you may find.

Other notes:

  1. The default encryption cipher is AES, but the framework is “pluggable” to encourage community contribution for other cipher methods.

  2. All files used for a single playbook must be encrypted with the same password.

Please test away!

Will this work with lookup so if it generates a pass its stored in the vault automatically?

(I asked this in the official post but didn’t see my comment.)

There is no integration with lookup plugins at the moment. If you have a specific workflow or a example in mind, file a feature request on github and we can consider it for later releases.

Just a minor process note – It’s often troublesome to have a discussion about a feature on github because less people are there to read a ticket. I’d much prefer we discuss feature ideas here, for most major things, since that allows greater discussion, and search is also better.

That all being said, the basics here is that vault is designed to encrypt and decrypt YAML data files – of which since Ansible is data driven is mostly everything.

By contrast, the password lookup plugin is a clever tool, but it’s a hack and architecturally wrong for this solution, and it was not intended to keep files in version control.

The “random password per server” approach works on writing little stub files text here and there and I can see it being possible for, if --ask-vault-pass was set, and I can see this approach being fiddly. We’re unlikely to want to implement this though, because the random password generator bits are not designed to keep all the data in one file – it was an interesting plugin, but probably not implemented the way you want.

What you’d propose here I think is better served by keeping a file in a configurable location, like

{{ lookup(“password2”, “password.yml”, “mysql/” + inventory_hostname) }}

Which would store a key “mysql__{{inventory_hostname}}” in a YAML file.

Basically a rearchitected alternative to the password plugin.

where it would write a random password into password.yml under some_key and then encrypt and decrypt as needed using --ask-vault-pass.

This is going to be out of scope for 1.5, and we’re going to want to move on rather than build this for you, but if someone wants to implement this to the above suggested spec, I think it would be pretty interesting and useful.

In previous discussions in this list around the problem that
ansible-vault is trying to solve, I had demonstrated the need of an
interface that does encryption at a variable value level (like having a
leaf-node-only YAML encryptor/decryptor to use Michael's term) and other
members in the community, as well as Ansible's leader Michael DeHaan,
had agreed with that. The use case for such an interface is quite
standard: You want to commit your Ansible stuff to your revision control
system and keep your sensitive data secret *without* destroying the
readability of your data structure (Ansible is all about data) and
*without* loosing the ability to review and audit changes (a must in
many security-sensitive environments). Looking at how ansible-vault has
actually been implemented, it seems that the whole discussion around
that requirement was not considered at all, and, instead, files are
encrypted as a whole. What was the reason for that decision?

It is surely an important step forward to have an official approach to
encryption of Ansible's data, but it is IMHO disappointing the fact that
community feedback was not taken into account.

“and other
members in the community, as well as Ansible’s leader Michael DeHaan,
had agreed with that”

I am really not happy with the tone here.

ansible-vault was designed from the result of lots of threads about this, as well as making it as simple and usable at it could possibly be.

If it doesn’t fit your specific needs, that’s unfortunate, but I’m also exceptionally happy with the simplicity and interface of this design.

It certaintly wasn’t done to slight anyone, and I think everyone does need to understand how hard it is to balance the needs of a half million different Ansible users and make everyone 100% happy.

Vault is a great addition, and if this doesn’t work for someone, they can still write a lookup plugin to do something different. That’s a primary reason that ansible is pluggable.

Michael,

That’s pretty much exactly what I would want it to do. I currently do my own poor man’s vault by running a bash file which encrypts a folder where all the lookup passwords are generated to. The vault as is isn’t really useful for me since all my passwords are generated per server. Is this not a common thing? Would you have a different recommendation for how to manage passwords in general?

What you are proposing wouldn’t be the ansible-vault CLI, it would probably need to be a “password2” plugin, but the Vault code is totally usable by the plugin (utils/vault.py) as I’ve mentioned above.

What most people want is the ability to set secrets that are global across their infrastructure.

The password lookup plugin is great, but handling the password lookup plugin was not the main goal of implementing vault.

Totally open to seeing a password2 style addition that uses the vault code.

You can use an encfs-based role from here: https://github.com/ginas/encfs (drybjed.encfs on Galaxy) to open/close encrypted directory during Ansible run, and then use lookup(), copy, fetch as normal.

I really had no intention to have a specific tone that would make you unhappy. I just mentioned your name because you are Ansible’s leader, the one who makes final decisions, and nothing is wrong about that. What surprised me was that, while you were positive with what me and other people in the list were concluding about the requirement to have encryption at variable-level and not at file-level, it ended up that you choose not to make things that way. I am referring to a very specific and expressed by a few people requirement: Have variable-level encryption instead of file-level. Please take another look at this discussion: In case you don’t have time to pass through the whole discussion, I summarize the positions that were in favor of a design with variable-level encryption below: JP Mens: He was the one who started the discussion and must be the one that, at that time, spent the most time thinking and even actually implementing his proofs of concept Mavimo: He was the first to mention the tottaly crypted files at his “Cons” section of his git-crypt-based solution Dave Cottlehuber: Agreed with Mavimo Me: also expressing the reasons for a variable-level encryption approach (meaningful diffs for history, auditing, troubleshooting, etc.) Vincent Van der Kussen: Agreed with JP Mens’s summarization of design requirements Brian Coca: suggested his own version of a YAML interpreter hook for variable-level encryption Michael DeHaan: you were positive and suggested a YAML encryptor algorithm for encrypting “leaf” values of YAML data structures A lot of voices, some being heard by some great contributors I know of (JP Mens, Brian Coca). Also it seems that the implemented design for the actual encryption/decryption interface is not very different with the one you had suggested then: In fact, I think that you were the only one in that discussion who talked about a whole-file encryption interface. So, it’s questionable how much attention was given to the “variable-level vs file-level encryption” discussion. I guess that it is still possible to implement a ‘–leaf-only-encryption’ mode option for ansible-vault without loosing the current behavior. The question is whether you would accept such an addition in the core, or you have reasons not to. And sure, even if it does not evolve to meet an IMHO important requirement, people will still find the Vault feature useful. Above all, thank you for your work.