Vault IDs in Red Hat Ansible and Red Hat Ansible Tower

This article demonstrates the use of multiple vault passwords through vault IDs. You will learn how to use vault IDs to encrypt a file and a string. Once they're encrypted, the vault ID can be referenced inside a playbook and used within Red Hat Ansible and Red Hat Ansible Tower.

Starting with Ansible 2.4 and above, vault IDs are supported

Vault IDs help you encrypt different files with different passwords to be referenced inside a playbook. Before Ansible 2.4, only one vault password could be used in each Ansible playbook. In effect, every file needed to be encrypted using the same vault password.

To begin with, vault IDs need to be pre-created and referenced inside your ansible.cfg file. The following excerpt is from ansible-config list for the configuration DEFAULT_VAULT_IDENTITY_LIST:

default: []
description: A list of vault-ids to use by default. Equivalent to multiple --vault-id
args. Vault-ids are tried in order.
env:
- {name: ANSIBLE_VAULT_IDENTITY_LIST}
ini:
- {key: vault_identity_list, section: defaults}
name: Default vault ids
type: list
yaml: {key: defaults.vault_identity_list}

You can reference multiple vault IDs and their corresponding vault files in ansible.cfg.  The vault_identity_list key under the default section is used to map the vault IDs to files.

The ansible.cfg has the following configuration:

[sanujan@fedora ansible]$ cat ansible.cfg
[defaults]
inventory = inventory
remote_user = root
vault_identity_list = inline@~/ansible/.inline_pass , files@~/ansible/.files_pass

For the purpose of this article, I've used the last line above to pre-create two vault password files in the $HOME/ansible directory with the appropriate permissions. That last line maps vault-id inline to /home/sanujan/ansible/.inline_pass and vault-id files to /home/sanujan/ansible/.files_pass.

The contents of those password files are shown below:

[sanujan@fedora ansible]$ cat ~/ansible/.files_pass
REDHAT
[sanujan@fedora ansible]$ cat ~/ansible/.inline_pass
redhat
[sanujan@fedora ansible]$ ls -l ~/ansible/.files_pass ~/ansible/.inline_pass
-r--------. 1 sanujan sanujan 7 Sep 23 06:25 /home/sanujan/ansible/.files_pass
-r--------. 1 sanujan sanujan 7 Sep 23 06:25 /home/sanujan/ansible/.inline_pass

This code creates a sample playbook containing encrypted text and a reference to an encrypted vars file, (vars/vars.yml), as shown in Figure 1.

How the string and vars file are encrypted is detailed in the next section.

Encrypting a file to be included/referenced inside the playbook

To create the encrypted section for a file, run:

[sanujan@fedora ansible]$ ansible-vault encrypt --encrypt-vault-id files vars/vars.yml

The --encrypt-vault-id files is how we reference the vault ID "files" to be used for encrypting the file vars/vars.yml in the playbook directory. This command doesn't prompt us for a password because it references the ID "files" from ansible.cfg.

The config file maps to ~/ansible/.files_pass, where the passphrase REDHAT is hard-coded. In the vars/vars.yml file, a variable is initialized with the key course and value DO457.

To view the encrypted file, you can use ansible-vault's view option. Here, the passphrase is automatically taken by Ansible, as it's referenced inside ansible.cfg:

[sanujan@fedora ansible]$ ansible-vault view vars/vars.yml 
course: DO457

Encrypting a string to be used inside a playbook

To encrypt a string intended for use inside an Ansible playbook, use a format similar to:

[sanujan@fedora ansible]$ ansible-vault encrypt_string --encrypt-vault-id inline -n testing this-is-the-secret

The --encrypt-vault-id inline portion is how we reference the vault ID inline to be used for encrypting the string this-is-the-secret. Next, we set the testing variable to the value of this-is-the-secretusing -n testing.

This command doesn't prompt us for a password. Instead, it references the ID inline from ansible.cfg, which maps to ~/ansible/.inline_pass with the passphrase redhat. The results for this command are shown in Figure 2.

The output breaks down as follows:

• The variable name testing, followed by !vault |, indicates that the vault is encrypted.
• The vault version that supports the vault ID is 1.2.
• The AES cipher in 256 bits is represented by AES256.
• The vault ID in use is inline.

Note: The vault ID is visible in the header.

Now, you can copy and paste the contents including the variable name (testing, in our case), all the way down to the line before Encryption Successful.

Executing the playbook

In order to execute this playbook, run:

[sanujan@fedora ansible]$ ansible-playbook vault_encryption.yml

The results are shown in Figure 3.

Prompting the vault password during playbook execution

If the vault_identity_list key is referenced in ansible.cfg, Ansible will always read those password files from left to right, checking for possible passphrase matches and disregarding the vault IDs before the tilde (~) character. If you prefer to have Ansible prompt you for the password to decrypt the vault string/file, you can comment out the vault_identity_list key in ansible.cfg.

To execute the playbook while requiring a prompt, use --vault-id id@prompt:

[sanujan@fedora ansible]$ ansible-playbook --vault-id inline@prompt --vault-id files@prompt vault_encryption.yml

An example is shown in Figure 4.

As you can see, this command prompts you twice: once for entering the passphrase for vault ID inline and the second for files.

Vault IDs in Ansible Tower

Ansible Tower also supports vault IDs, starting with Tower 3.3. You can reference these vault IDs while creating a credential of type Vault, as shown in Figure 5.

Summary

Vault IDs offer the flexibility to choose multiple passphrases for encrypting different files and strings.  Ansible Tower supports vault IDs also while creating the Vault credential.

Learn more

To learn more about vault IDs and how to use them in Red Hat Ansible and Red Hat Ansible Tower, see the following resources:

• Ansible Vault ID
• Ansible Documentation
• Ansible Tower Documentation