ansible inline vault

[h0nIg]

Sometimes you want to define a complex variable dictionary and do not want to create a separate vault file for passwords. It would be cool for history purpose to use a plain yml file for variable definition and inline vault variable content like the following. This feature is described by @jpmens on http://jpmens.net/2014/02/22/my-thoughts-on-ansible-s-vault/

nameserver: 10.0.0.1
admin: Jane Jolie
dbpassword: @vault@"AHchx0a+G8mejs84tGxCNKxMFP7tM7Y7kl"
webservertype: nginx

[h0nIg]

this is not a duplicate, since the other guy wants to get this implemented by filters and my intention is that this is handled by the ansible yaml parser itself, please reopen!

[bcoca]

i doubt that will happen as the performance penalty of examining every possible value for vault content will slow down Ansible considerably.

[h0nIg]

therefore the initial idea was to scan only the first letters and check for a special content like @vault@

[bcoca]

yes, that is what will be prohibitive for most users, only those with tiny inventories and few variables would not notice a huge delay.

We have been doing a lot of performance optimization prior to the 2.0 release, most speedups came from avoiding copying and examining the variables as much as we did.

[h0nIg]

hmm ok.

but to check this statement: do you really think another loop on VariableManager.get_vars for replacing variable content is expensive too? (in comparision to copying on combine_vars). just scrolled the source code and it seems that it would work

[bcoca]

try it out, but look at the commit history and you'll see we removed lots of code that scanned and/or copied the variables. What you see now should be the minimal needed for ansible's functionality and it is still slower than what we would want when large inventories are invovled

[bcoca]

@h0nIg i do think your idea makes for a better user interface, though no need to add @vault@ as vault already puts in a specific recognizable header.

If you can implement w/o it impacting performance too much, go ahead, i suspect it will be hard to do but will be very happy if you prove me wrong.

[bcoca]

i've been thinking about this more, a much more efficient way to do this would be to use a YAML type handler instead of parsing the values.

key: !vault vaultedvalue

would just require that we create a function that handles vaulted strings and register it with the module parser as the one to handle the !vault type.

[h0nIg]

this seems to be pretty easy, wrote example implementation (not tested):

h0nIg@e680f50

[marcinhlybin]

I wrote ansible filter that does exactly what you want:
https://github.com/ahes/ansible-filter-plugins/blob/master/vault.py

Have fun :)

[h0nIg]

@ahes i do not want to include a separate encryption library, i want to use it with ansible capabilities

[alikins]

http://jpmens.net/2014/02/22/my-thoughts-on-ansible-s-vault/ describes something that decrypts to a string.

Would an inline vault need to support decrypting to a more complex object (map, list, etc)?

If a inline vault needed additional info (like an identifier for which key to use), would it be acceptable if that was in a wrapper mapping? Or 'args' to a !vault object?

[h0nIg]

@alikins

the first one is the intended one.

inline vault should not need to decrypt to a complex object, but it should support to decrypt to a yaml multiline string. the intention is to hide the parts that should be secure only

what do you mean by "wrapper mapping"? i do not have any preference at all

[alikins]

what do you mean by "wrapper mapping"? i do not have any preference at all

Not a particular thing, just a vague idea that the key id may need to be defined outside of the vault blob. One thought was something like a map with the (map) keys being 'key_id' and 'vault_blob', but I didn't really think that through ;->

Current version of my branch should be fine with multiline strings.

[alikins]

One advantage of keeping the decrypted value simple and deserializing to something string like is it makes it easier to wait until the last possible moment to decrypt (as opposed to attempting to decrypt while parsing). That could potentially be as late as remote node module execution[1]...

[1] assuming shared secrets or some pki support in ansible-vault...

[alikins]

@h0nIg
Take a look at #16274

That is an implementation of vault encrypted yaml variables (originally based on your sample implementation)

[gebi]

Just as a note becaue i stumbled over this PR.
Speed would not be a problem if the wrong usage of PBKDF2 would be fixed in ansible vault (#20933).
The reason being, PBKDF2 should only be done ONCE per ansible startup to derive the possible low entropy user password into acceptable key material and not once per encrypted content.
The key derivation function done per content could be MUCH faster (eg. some simple HMAC with matching output length or PBKDF2 with only a single round instead of 10000).

the linked bug report is really about having a method to disable PBKDF2 with 10000 rounds for key material with already known high entropy and is no exact match to this discussion, but also discusses the principle problem in ansible vault.

[bcoca]

closing as implemented in #16274, released in 2.3 usable as !vault example i have above