Chapter 3: Protecting Your Secrets with Ansible

Secrets are meant to stay secret. Whether they are login credentials to a cloud service or passwords to database resources, they are secret for a reason. Should they fall into the wrong hands, they can be used to discover trade secrets, customers' private data, create infrastructure for nefarious purposes, or worse. All of this could cost you and your organization a lot of time, money, and headaches! When the second edition of this book was published, it was only possible to encrypt your sensitive data in external vault files, and all data had to exist entirely in either an encrypted or unencrypted form. It was also only possible to use one single Vault password per playbook run, meaning it was not possible to segregate your secret data and use different passwords for items of different sensitivities. All that has now changed, with multiple Vault passwords permissible at playbook runtime, as well as the possibility of embedding encrypted...

Technical requirements

To follow the examples presented in this chapter, you will need a Linux machine running Ansible 4.3 or newer. Almost any flavor of Linux should do—for those interested in specifics, all the code presented in this chapter was tested on Ubuntu Server 20.04 Long Term Support (LTS), unless stated otherwise, and on Ansible 4.3. The example code that accompanies this chapter can be downloaded from GitHub at this Uniform Resource Locator (URL): https://github.com/PacktPublishing/Mastering-Ansible-Fourth-Edition/tree/main/Chapter03.

Check out the following video to see the Code in Action: https://bit.ly/2Z4xB42

Encrypting data at rest

As a configuration management system or an orchestration engine, Ansible has great power. To wield that power, it is necessary to entrust secret data to Ansible. An automation system that prompts the operator for passwords at each connection is not very efficient —indeed, it's hardly fully automated if you have to sit there and type in passwords over and over! To maximize the power of Ansible, secret data must be written to a file that Ansible can read and from which it can utilize the data.

This creates a risk, though! Your secrets are sitting there on your filesystem in plaintext. This is a physical as well as a digital risk. Physically, the computer could be taken from you and pored over for secret data. Digitally, any malicious software that can break the boundaries set upon it is capable of reading any data to which your user account has access. If you utilize a source control system, the infrastructure that houses the repository is just...

Creating and editing encrypted files

To create new files, Ansible provides a program called ansible-vault. This program is used to create and interact with Vault-encrypted files. The subcommand to create encrypted files is create, and you can see the options available under this subcommand by running the following command:

ansible-vault create --help

The output of this command is shown in the following screenshot:

Figure 3.1 – The options available when creating an Ansible Vault instance

To create a new file, you'll need to know two things ahead of time. The first is the password ansible-vault will be using to encrypt the file, and the second is the filename itself. Once provided with this information, ansible-vault will launch a text editor (as defined in the EDITOR environment variable—this defaults to vi or vim in many cases). Once you save the file and exit the editor, ansible-vault will use the supplied password as a key to encrypt...

Executing ansible-playbook with encrypted files

To make use of our encrypted content, we first need to be able to inform ansible-playbook of how to access any encrypted data it might encounter. Unlike ansible-vault, which exists solely to deal with file encryption or decryption, ansible-playbook is more general-purpose, and it will not assume it is dealing with encrypted data by default. Fortunately, all of our familiar --vault-id parameters from the previous examples work just the same in ansible-playbook as they do in ansible-vault. Ansible will hold the provided passwords and IDs in memory for the duration of the playbook execution.

Let's now create a simple playbook named show_me.yaml that will print out the value of the variable inside of a_vars_file.yaml, which we encrypted in a previous example, as follows:

--- 
- name: show me an encrypted var 
  hosts: localhost 
  gather_facts: false 
 
  vars_files: 
    - a_vars_file...

Mixing encrypted data with plain YAML

Before the release of Ansible 2.3, secure data had to be encrypted in a separate file. For the reasons we discussed earlier, it is desirable to encrypt as little data as possible. This is now possible (and also saves a need for too many individual files as part of a playbook) through the use of the encrypt_string subcommand of ansible-vault, which produces an encrypted string that can be placed into an Ansible YAML file. Let's start with the following basic playbook as an example:

---
- name: inline secret variable demonstration
  hosts: localhost
  gather_facts: false
  vars:
    my_secret: secure_password
  tasks:
    - name: print the secure variable
      ansible.builtin.debug:
        var: my_secret

We can run this code (insecure though it is!) with the following command:

ansible...

Protecting secrets while operating

In the previous section of this chapter, we covered how to protect your secrets at rest on the filesystem. However, that is not the only concern when operating Ansible with secrets. That secret data is going to be used in tasks as module arguments, loop inputs, or any number of other things. This may cause the data to be transmitted to remote hosts, logged to local or remote log files, or even displayed onscreen. This section of the chapter will discuss strategies for protecting your secrets during operation.

Secrets transmitted to remote hosts

As we learned in Chapter 1, The System Architecture and Design of Ansible, Ansible combines module code and arguments and writes this out to a temporary directory on the remote host. This means your secret data is transferred over the wire and written to the remote filesystem. Unless you are using a connection plugin other than Secure Shell (SSH) or Secure Sockets Layer (SSL)-encrypted Windows Remote...

Summary

In this chapter, we covered how Ansible can deal with sensitive data effectively and securely, harnessing the latest Ansible features, including securing differing data with different passwords and mixing encrypted data with plain YAML. We have also shown how this data is stored at rest and how this data is treated when utilized, and that with a little care and attention, Ansible can keep your secrets secret.

You learned how to use the ansible-vault tool to protect sensitive data by creating, editing, and modifying encrypted files, and the variety of methods available for providing the Vault password, including prompting the user, obtaining the password from a file, and running a script to retrieve it. You also learned how to mix encrypted strings with plain YAML files, and how this simplifies playbook layout. Finally, you learned the operational aspects of using Ansible Vault, thus preventing Ansible from leaking data to remote log files or onscreen displays.

In our...

Questions

1. Ansible Vault encrypts your data at rest using which encryption technology?

   a) Triple DES/3DES

   b) MD5

   c) AES

   d) Twofish

2. Ansible Vault instances must always exist as separate files to the playbook itself:

   a) True

   b) False

3. You can ingest data from more than one Ansible Vault instance when running a playbook:

   a) True

   b) False

4. When executing a playbook that makes use of Vault-encrypted data, you can provide the password:

   a) Interactively at playbook launch

   b) Using a plaintext file containing just the password

   c) Using a script to retrieve the password from another source

   d) All of the above

5. Ansible will never print vault data to the terminal during a playbook run:

   a) True

   b) False

6. You can prevent Ansible from inadvertently printing vault data to the terminal during a playbook run using the following task parameter:

   a) no_print

   b) no_vault

   c) no_log

7. An interrupted playbook run could leave sensitive unencrypted data on a remote host:

   a) True

   b) False

8. What is used...