This article had some good things in it, though I disagree with some points -- including the part where it suggests only using scalar variables.
What this really shows isn't specific to vault -- it's just that you can use variables in other variables. On Fri, Mar 21, 2014 at 7:54 AM, <[email protected]> wrote: > Hi all. > > (reposting because of a silly copy/paste error - sorry about that.) > > Vault was a great addition to Ansible. > Some complained about the lack of leaf encryption. > > I just published a blog post about a few of our practices involving > Ansible, > and here is an excerpt about how we easily work around this limitation. > Hope it helps some of you. > (Blog post is here: > http://reinteractive.net/posts/167-ansible-real-life-good-practices) > > Excerpt: > > *Vault Pseudo leaf encryption* > > Very recently, with version 1.5, Ansible introduced Ansible Vault, a way > to encrypt data in the playbook, and decrypt it at run time. This feature > was highly requested, and gives Ansible its true place among platform > management tools. > > The thing is: what we like about Ansible is the readability, and > encryption has a way of making things, well, less readable... > ansible-vault command will encrypt or decrypt the whole var file, you can > not encrypt just the value of a variable. The solution is simple enough: > create a second var file, just for the sensitive data. But this raises > another issue: your variables are now spread over multiple files, and some > of them encrypted. This can get messy. For instance, if you define a > dictionary of variables and only one of them is sensitive, you have to > encrypt the whole dictionary. > > Leaf encryption was (is) a feature request, but in the meantime, there is > an elegant way of keeping it both readable and secure: nested variables. > > For every sensitive variable, you create a prefixed double that goes in an > encrypted file. > > # var_filedb_password: {{ vaulted_db_passord }}# and for a dctionnaryaws: > - "access_key_id='abcdefgh'" > - "secret_access_key='{{ vaulted_aws_secret_access_key }}'" > > > # vault_filevaulted_db_passord: a_super_secretvaulted_aws_secret_access_key: > the_aws_secret > > That way, you can manipulate all your vars like before, knowing the > vaulted version stays encrypted. You can even solve the problem of having > someone responsible for the encrypted file and the rest of the team never > seeing its content but still being able to manage var files as they need. > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/2a8a43b6-b358-46a4-9d38-7874efc2fa8c%40googlegroups.com<https://groups.google.com/d/msgid/ansible-project/2a8a43b6-b358-46a4-9d38-7874efc2fa8c%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAEVJ8QMN7vstSiSxAgdhC2-Sx5hrYEc3fhT1_%2Bf_rsC-5CprYA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
