The Easiest Way

Dealing with Passwords

Sooner or later, any administrator has to deal with passwords as part of their daily work. Although they should not slow down automation, storing them in plaintext in an Ansible playbook is not an option. This is even more true if, as suggested, the Ansible playbooks reside in a central Git directory to which many people have access. In many companies, the compliance policy rules out such a situation anyway: In many places, teams are not allowed to access any data other than that they absolutely need for their own work in the scope of segregation of duties. However, if a team posts passwords from its own infrastructure to the Git directory, which is then accessed by the entire company, there is no longer any protection.

The Ansible developers are aware of the problem and are addressing it with Ansible Vault. The name is somewhat unfortunate in that it clashes with HashiCorp Vault. Although an Ansible community module ties Ansible directly to HashiCorp Vault, it has nothing to do with Ansible Vault. The small Ansible Vault tool encrypts a text file created by the admin (Figure 3) so that Ansible can read it like any other variable file.

Figure 3: Ansible Vault lets you store encrypted passwords so they can be managed in Git.

Once the admin has installed Ansible, ansible-vault is also available as a command in the shell. You can use

ansible-vault create passwords.yml

to create a vault for passwords. In it, you then define your passwords as variables (e.g., ldap_admin_password: verysecret). In your roles and playbooks, you can then access the variable as you would any other. However, when Ansible is invoked, it adds a --vault-id to the command to reference the password file.

Also for Certificates

The Vault mechanism is suitable not only for passwords, but also for other confidential content, such as the SSL keys that belong to certificates. If a web server with SSL enabled needs to be rolled out without automatic Let's Encrypt, it usually needs the key matching the certificate without a set password, which you can do quite easily with the Vault command that encrypts the key for the certificate:

ansible-vault encrypt key.pem

The encoded file is stored in the files/ subfolder of the role that rolls out the certificate. You can then access the encrypted file with a content directive in the playbook. If you pass ansible-playbook the vault with --vault-id, Ansible automatically decrypts the vault when the playbook is called and uses the contents of the file.

Ansible Tower

It was to be feared that Ansible would not remain the small, no-frills automation tool of the first hour forever. However, Red Hat, as the new owner of the solution, is doing its best to implement changes carefully and, moreover, to design them such that administrators do not necessarily have to use them. In parallel, the vendor is trying to build a portfolio around Ansible that provides additional functionality for its own clientele. Ansible Tower, which is based on the open source Ansible AWX software, is a good example of this effort.

At its core, Tower is on one hand a REST API and on the other a graphical user interface (Figure 4), including its own user and rights management with which Ansible can be conveniently controlled on a variety of target systems. Additionally, Tower can also be linked to existing user directories such as LDAP, which forms a kind of front end for quick access to an organization's entire Ansible setup. In Tower, you can add new playbooks and roles to the setup, run them on hosts, and integrate them into continuous integration/continuous deployment (CI/CD) toolchains. Additionally, recurring tasks can be defined in Tower that Tower then automatically executes at the defined intervals.

Figure 4: Ansible Tower works as a REST API and a GUI for Ansible, making large Ansible setups more manageable. © Red Hat

One special feature of newer Tower versions is its seamless integration with various public cloud providers. Ansible itself comes with modules for quite a few clouds, including Amazon EC2 and Microsoft Azure. The cloud workloads rolled out from Tower can then be visualized by the tool itself and monitored within the scope of its capabilities (Figure 5).

Figure 5: In addition to the ability to launch Ansible workloads, Tower has an autorun mode and records actions in a compliance-compliant manner. © Red Hat

However, only death is free of charge, and that costs you a life. Tower can be seen as Red Hat's predominant attempt to generate additional revenue from the Ansible acquisition for the first time. As for other management tools, you need a separate subscription for Tower. According to various sources on the web, the premium version costs around $14,000 per year. Companies would do well to evaluate Ansible Tower extensively before making a purchase.