What are best practices of structuring encrypting variables since Ansible 2.3.0?

Question

This document indicates that since Ansible 2.3 it should be possible to encrypt certain vars using a !vault | prefix instead of putting a variable and keys in a vault file and encrypt it completely.

notsecret: myvalue
mysecret: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          66386439653236336462626566653063336164663966303231363934653561363964363833313662
          6431626536303530376336343832656537303632313433360a626438346336353331386135323734
          62656361653630373231613662633962316233633936396165386439616533353965373339616234
          3430613539666330390a313736323265656432366236633330313963326365653937323833366536
          34623731376664623134383463316265643436343438623266623965636363326136
other_plain_text: othervalue

At the moment the structure is as follows:

ansible/group_vars/testing/vars
ansible/group_vars/testing/vault

When an encrypted variable is moved from the vault to the vars directory and ansible-vault decrypt ansible/group_vars/testing/vars is run it returns:

ERROR! input is not vault encrypted data for ansible/group_vars/testing/vars

This vaulted variable be decrypted with the supplied vault secret and used as a normal variable. The ansible-vault command line supports stdin and stdout for encrypting data on the fly, which can be used from your favorite editor to create these vaulted variables; you just have to be sure to add the !vault tag so both Ansible and YAML are aware of the need to decrypt. The | is also required, as vault encryption results in a multi-line string.

Questions

1. Should variables that need to be encrypted, be encrypted one by one using the command line?
2. What are best practices to restructure the old Ansible structure? E.g. remove the vault files and put all encrypted vars in the vars file?

Answer 1

Having been working with ansible vault quite a bit recently (specifically regarding what the encrypt and how to encrypt those things without making the code unreadable) I've found very little incentive to change my habits in 2.3.

If I'm going to have a series of encrypted variables, or files, keep them separate (I prefix them all with vault_) and just leave it at that.

A few times I have used the !vault feature but am left distinctly unamazed as it seems easier to just be very explicit about what is and is not coming from a secrets file. That way no one editing my plays makes assumptions about what is and isn't sensitive data.

Answer 2

I have decided to remove the ansible/group_vars/testing directory and replace it with a file, i.e. ansible/group_vars/testing that contains the encrypted vars:

mysecret: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          66386439653236336462626566653063336164663966303231363934653561363964363833313662
          6431626536303530376336343832656537303632313433360a626438346336353331386135323734
          62656361653630373231613662633962316233633936396165386439616533353965373339616234
          3430613539666330390a313736323265656432366236633330313963326365653937323833366536
          34623731376664623134383463316265643436343438623266623965636363326136

Instead of running ansible-vault edit ansible/group_vars/testing/vault one could pipe the values that need to be encrypted to ansible-vault, i.e. printf mysecret | ansible-vault encrypt. The latter will encrypt mysecret and the output could be added to the ansible/group_vars/testing file. When ansible-playbook will be run the encrypted variables will be decrypted if the ansible vault file is specified of course.

If the encrypted value needs to be debugged then the following code could be used:

- debug: msg="Decrypted value: {{ encrypted_var }}"