Ansible has been around the block since 2012. It’s an open-source software provisioning tool that lets you configure and manage application deployments in an automated manner. It is agentless, meaning that it doesn’t need a specific tool or target host in order to automate.
In the past, I’ve used Ansible to boot up backup instances and orchestrate infrastructure recoveries via AWS. However, Ansible isn’t just limited to Amazon Web Services. It is also supported by major cloud providers such as Digital Ocean, Google Cloud, Oracle Cloud, and Microsoft Azure. It can also be integrated into your Docker instances, Rackspace and OpenStack. In short, if the cloud platform supports Python and PowerShell, it will also most likely support Ansible.
It’s easy to create an Ansible orchestration — but this isn’t the main focus for this article. When something is easy to boot up, it is also usually prone to security risks. This is because default settings are usually used, or bad practices implemented because the developer hasn’t considered the security repercussions.
Here are some best practices when it comes to Ansible and how to implement them.
Avoid single target login names
It’s common for Ansible to be set up with a single root target login credentials. Why? Because most things have some sort of super admin account.
However, Ansible doesn’t require a single target login name. This means that admins can have their own personal account on each target server, with the ability to sudo with passwords for super admin access. This is important because it allows you to see who did what in the logs, rather than have a single anonymous super user.
Another good security practice for Ansible when it comes to admin accounts is to avoid generic names like admin and ansible. If the username is easy to guess, an attacker is already halfway there with accessing your automated orchestration tool. Select identifiers that can be tracked and traced back to a person. The owner of this username is then responsible for its safekeeping. This will increase your audit logs and make it easier to track and trace down issues to the source if they ever arise.
Use Ansible Secret Management
Ansible Vault is an encryption tool that lets you create and view encrypted variables, files, encrypt existing files, edit, re-key, and decrypt files using standard symmetric encryption (AES-256). This is done before it gets committed to the source code repository, meaning that your passwords, service accounts, key files, and other sensitive information is secure before it gets committed.
However, you still need to manually put these files into the vault for encryption before committing it to your git branch. This means files that have not been added to the vault become vulnerable to exposure through your Git repository.
To fix this, it is good practice to employ git hooks to ignore certain types of files unless it has been prefixed by VAULT_. This prefix is automatically added to files that have been encrypted and anything that gets committed remains secured from unwanted access.
But how do you use Ansible Vault?
- To create encrypted files
- For storing and accessing vault passwords
- For storing and accessing vault passwords
- To encrypt content with Ansible Vault
Run the following command on your data file:
- To encrypt existing files
You can use the ansible-vault encrypt command to achieve this effect:
To encrypt files with password prompts:
To view your encrypted files:
To edit encrypted files:
To edit an encrypted file under a specific vault ID and password source:
How does Ansible know if you have permission to decrypt the data? It does this through the vault ID. The vault ID acts as an identifier for one or more vault secrets. You can have multiple vaults with different passwords attached to a particular encrypted file.
Here is the command to set the vault ID before you start encrypting your sensitive data.
The label is your vault ID and the source is where it obtains its password. This might come in the form of a file path to a secret key, or a prompt for the user to type in the password.
When you run ansible-vault on any file, it automatically applies the current vault ID, unless otherwise explicitly supplied in the command line.
You can also use multiple passwords on a single vault ID. For example, your secret key encryptions inside the vault can have the same vault ID but different passwords for each instance. This adds another layer of security on your sensitive data. However, it also increases the maintenance of passwords and management of these passwords over time.
Depending on how sensitive your data is and how secure you need it to be, classes of files can be segregated into different password categories with the same vault ID.
It is also good to note that the vault ID merely serves as a password hint, rather than a hard-line enforcer that needs to be matched. This means that if you have an encryption for a dev and prod instance, and the password for one of these is correct — it will still work.
It doesn’t matter if the vault ID is dev, if the password matches prod, Ansible will still decrypt it against the prod encryption. To force Ansible to decrypt only if both the vault ID and password pairing match, you need to set the config option to DEFAULT_VAULT_ID_MATCH.
To rekey your encrypted files:
When you run this command, it will ask you for the original password and the new password. Ansible doesn’t let you revoke access. This means that keys cannot be revoked — only changed. This means that every time you want to change the accessibility of an encrypted file, the new password keys will need to be redistributed to developers who have permission to access it.
While it all sounds very manual, the level of human communication and interaction required ensures that everyone who has the new keys is physically aware of the changes.
Here’s how to set the new password on the targeted files:
A different ID can be set with the rekeyed files through –new-vault-id.
Conclusion
Ansible is mostly executable bits of code that are pushed to your target machines. It is free, open-source, and sits on the configuration management and orchestration tool side of DevOps. This means that it is often used from provisioning resources, configuration management, app deployments, continuous delivery, along with implementing security and compliance policies on servers. If you’re a system administrator, acts of automation through Ansible can cut down on repetitive tasks and help automate the patching process. The in-built vault system adds another layer of security on top of all the other security measures you already have.
By using Ansible Vault and diversifying your accessibility through targeted and traceable usernames, you can easily increase the security of your Ansible automation easily. While Ansible does use SSH, once you have automation running, it is mostly hands-off. This means that if your sensitive data is not secured at the source, malicious hijacking can occur without you noticing.
