Why Use Ansible Vault?
Ansible vault is a very useful tool in the world of devops. It provides you an easy way to check your entire configuration into version control (like git) without actually revealing your passwords.
This means that when you apply config changes, it gets recorded and you can roll-back or upgrade just like you do with normal code. Nothing is lost, and nothing is insecure.
Encrypting a Single Property
Ansible can be used in countless ways; it is a very flexible tool. Take variables for example; you can put them in your inventory file, in separate variable files, at the top of your playbook, in the CLI command, and I’m guessing even more places.
In this case, lets say you have a nice existing variables file that just happens to not be encrypted. You don’t want to split up your file and you don’t want to encrypt the whole file either because then it is hard for others to review (e.g. why encrypt the DNS name for a service you’re hitting?).
Example vars-dev.yml:
mysql_password: password123
dns_name: some-service@company.com
So, let’s encrypt just the password in that file and leave everything else as plain text. We’ll use this command to encrypt the password (password123).
$> ansible-vault encrypt_string --vault-id vault_password 'password123' --name 'mysql_password'
mysql_password: !vault |
$ANSIBLE_VAULT;1.1;AES256
31336265626432653930373332313963666565336333303731653133613732616234383634613134
6463393739616232613837363065376336346265646432360a383464326231333035633762663738
65396562386166613537346165646539303334383039396235636331343830633761303239643434
6335343035646665640a666338346130636161663561376662666566316565646133653162663065
3534
Encryption successful
Note that “vault_password” in this line is actually a text file in the current directory that just has the password to my vault in it. Keeping your vault password in a file lets you use it in automation like Jenkins without it showing up in log entries/prompts.
$> cat vault_password
some_good_password
The entire part from ‘mysql_password’ onward in the command output (prior to Encryption Successful) is the line you should now use for the password in your variables file. So, the modified variables file looks like this:
Updated Example vars-dev.yml:
mysql_password: !vault |
$ANSIBLE_VAULT;1.1;AES256
31336265626432653930373332313963666565336333303731653133613732616234383634613134
6463393739616232613837363065376336346265646432360a383464326231333035633762663738
65396562386166613537346165646539303334383039396235636331343830633761303239643434
6335343035646665640a666338346130636161663561376662666566316565646133653162663065
3534
dns_name: some-service@company.com
Testing It Out
At this point, let’s test that we can use this partially encrypted variable file for something real.
Let’s start by creating some new files, all of which we’ll be lazy with and just keep in our current directory:
We’ll create a config.properties template file that uses our variables.
mysql.password={{mysql_password}}
dns.name={{dns_name}}
Well create a playbook.yml file that is our actual playbook to run:
---
- name: Ansible Vault Example
hosts: my_hosts
tasks:
- name: Copy config file to servers with decrypted password.
template: src="config.properties" dest="/tmp/config.properties"
And we’ll create inventory.yml to tell ourselves which hosts to target. We’ll just target localhost, but whatever. Make sure localhost can ssh to itself for this :).
[my_hosts]
localhost
Now we can run our test! Use this command to run our playbook with our inventory file and our variables file with our vault password. Based on the playbook, it should copy config.properties from our current directory to /tmp/config.properties with the variables replaced and decrypted where relevant.
ansible-playbook -i inventory.yml --vault-password-file vault_password --extra-vars @vars-dev.yml playbook.yml
Now we can cat /tmp/config.properties and see that it worked!
$> cat /tmp/config.properties
mysql.password=password123
dns.name=some-service@company.com
I hope this helps you in the future! I’ll be doing more blogs on Ansible, Vault, etc in the near future. So, come back for more!