How to Manage Ansible Secrets With Akeyless Vault

Ansible is an open-source automation tool that is used for configuration management; in addition to the open-source version, Red Hat also offers the enterprise version, Ansible Tower. 

There are lots of ways where Ansible requires secrets (credentials, passwords, ssh-keys). in order to operate. One example would be the way Ansible uses SSH keys in order to connect to different nodes, that are called within your playbooks, or API keys, to access resources that you need to configure.

To avoid plain text secrets within Ansible playbooks, Ansible offers an internal vault for secrets management called ‘Ansible Vault’. Even with this functionality, it is preferable to use a centralized solution for managing your passwords, keys, and tokens vs. a single-platform vaulting solution - and here’s why:

Benefits of Using a Centralized Secrets Management Solution

• Makes secrets management operationally easier
• Enables simple compliance
• Achieves great functionality in terms of security 

Instead of talking in generalities, let’s see how it works with Akeyless Vault, a unified secrets management platform that works across all DevOps tools.

Operation-wise — you probably work with more tools besides Ansible, such as Jenkins, Kubernetes, and Chef to name a few, and each of these tools has its own secret manager/vault. This forces you to manage multiple ‘islands of secrets’, which is both cumbersome and risky. It should be your choice to avoid this scenario. A centralized secrets management platform allows for clearer visibility and easier management as all your secrets are created and accessed via a single source.

Functionality-wise — most of DevOps tools’ internal secrets management solutions such as Ansible Vault, lack the creation of Just-in-Time Secrets, which enables temporary credentials. The idea behind JIT is that any playbook has on-demand access to a certain resource that ‘dies’ after the playbook completed its run. This is also a crucial functionality for achieving zero-trust implementation.

Security-wise — maintain the least privileges approach by leveraging the ability to completely eliminate the use of SSH keys and employing instead short-lived SSH certificates. This allows for enhanced security since certificates use date ranges to automatically expire. In case of mistakes, misuse, or theft, SSH certificates automatically expire.

Audit-wise — simply put, the centralized solution enables consolidated audit. Instead of finding/collecting audit trails about secret usage from multiple systems, you can get it from a single source. It saves you precious time and relieves much of the compliance hassle.

How to Fetch a Secret With Akeyless Vault in Ansible

So with all of the above in mind, the ease of operation and enhanced security allowed by using the Akeyless Vault centralized secrets management platform, let’s see in actuality how simple it is to fetch a secret in Ansible.

1. Place the Akeyless Plugin within your lookup_plugins directory pip install HVAC

2. Create an account with Akeyless (it’s free) https://console.akeyless.io/register

3. Create your first secret in Akeyless

4. Run export VAULT_ADDR=https://hvp.akeyless.io

5. Store your Akeyless token in ~/.vault-token in the following format

<access-id>..<access-key> example

6. Create a new playbook file named secret_fetch.yml, within your playbook, call the secrets within the Akeyless Vault

xxxxxxxxxx

# This playbook fetches a secret from Akeyless vault

- name: example

hosts: all

tasks:

- name: Fetching a secret named test from Akeyless Vault

debug:

msg: "{{ lookup('hashi_vault', 'secret=secret/data/Ansible/My_first_Ansible_Secret:data') }}"

*Akeyless supports full interop with the Community Vault plugins

7. Run the playbook 

xxxxxxxxxx

ansible-playbook -i <hostname>, -u ubuntu secret_fetch.yml 

Configuring the Akeyless Ansible Plugin solves many challenges surrounding managing security and operational burden within a typical Ansible playbook.

To Sum Up

When you work with Akeyless Vault for secrets management, you are able to generate any secret or credential on-demand within your playbooks. 

Secrets are easily and automatically fetched when you need to use them for configuration management. Automation allows for action to be performed during a specific period, for a specific user.

You eliminate the risk of standing or expired secrets to a critical application being exploited. Even though these secrets are temporary, you view a complete audit trail of which users fetched the secret and mediate the risk of it being misplaced or misused, because it's no longer valid.