Simplifying secrets management with CyberArk and Red Hat Ansible Automation Platform

Access credentials and secrets are a crucial piece of today’s infrastructure management: if they get compromised, the environment itself is at risk. Thus some time ago, back at about version 3.5.1, the idea of a secrets management system was introduced into Ansible Tower, one of the components of our Red Hat Ansible Automation Platform. What this essentially means is that Ansible Tower has a credential store where it will encrypt at-rest secrets that you need in order to log in to a remote host, authenticate with a cloud endpoint or pull content from a version control system. 

We have always needed secrets in order to log in and then configure a remote resource. We do this every day with usernames and passwords. Ansible Tower has a very secure built-in mechanism for providing this capability, but some may see that as an additional security island or bespoke to the enterprise direction. In this blog post, I will highlight the Ansible way of solving the “security island” problem and propose a solution using Ansible credential plugins integration via CyberArk Conjur. Conjur is an API addressable vault where you store access and authorization information instead of having the secrets stored in Ansible Tower. An integration like this solves many enterprise privilege access problems, like least privileged access and password resets, as well as storing important auditing information centrally.

This blog post describes a step by step on how to deploy a container based CyberArk conjur application and integrate it with Ansible Tower.

Deploy a container host

To get started, launch yourself a new Linux instance. In our example we use a Red Hat Enterprise Linux 8. If you don’t have access to RHEL 8 yet, check out the RHEL 8 developer program. Otherwise, you may have issues using some of the commands or getting access to content within these instructions. Once your Linux instance is accessible, log into it and gain root privileges to run the following sequence of commands that will prepare the host with all the software dependencies.

Note: Install CyberArk Conjur and Ansible Tower onto a single host if you prefer an all in one solution. Please refer to the installation steps on docs.ansible.com if you don’t have an Ansible Tower system at your disposal. Id also recommend reading through this article for details around usage of podman

# dnf -y install python3 git podman
# curl -L "https://raw.githubusercontent.com/sheeshkebab/podman-compose-1/devel/podman_compose.py" -o /usr/local/bin/podman-compose
# chmod +x /usr/local/bin/podman-compose
# alternatives --install /usr/bin/podman-compose podman-compose /usr/local/bin/podman-compose 1
# cd /var/tmp

Set up Conjur

The setup of Conjur is rather simple, and others have already described it perfectly. Thus complete these steps right up to the sub heading where it says “Integrating Ansible”. If you follow the guide correctly, you will end up with a development version of Conjur running inside a container and a service account / password configured within.

I performed a few additional steps by setting up a load balancer instance that exposes my Conjur service to the outside world with a valid SSL certificate and DNS name.

Take it for a spin

Now you have a working containerised Conjur service, you are ready to integrate it into Ansible Tower. Let's start by defining a credential with Ansible Tower that allows us to authenticate against the Conjur service API.

To create a credential in Ansible Tower, click on “Credentials” in the left navigation bar and create a new one. Fill in the details as shown below and note the “Credential Type”.

• The Conjur URL needs to point to your Conjur installation. If you have installed all on one host, this is localhost. In my case it references my public load balancer. Conjur listens on port 8443.
• The API key can be found within the contents of your ansible.out file that was created during the installation.

Once your credential data has been entered, click the blue test button and populate the "SECRET IDENTIFIER" as per below screenshot. Note; the secret identifier matches what you set up earlier in your Conjur policy. Specifically, the location of the username “service01”. I've given my Conjur account a very simple annotation “Conjur-API-Account”, we will need this again soon.

If you get a green box that means you have things configured correctly. Adding it as per the screenshot should just work, but if you get a red box indicating failures, test that you have firewall rules and routing between your Conjur and Ansible Tower systems configured correctly and confirm that you are using the correct secrets identifier.

Add a new credential into Ansible Tower

Let’s use the freshly created Conjur credential, and Create a new credential of type “Machine” using Conjur. In the left navigation bar of Ansible Tower, click on “Credentials”, create a new one of type “Machine” and give it a name and organization. Machine credential types perform the authentication against automated endpoints. 

In our example the username will be "service01" because it matches the key stored at db/host1/user in Conjur. 

The password field will be auto-populated via an API call against your Conjur service. Select the "magnifying glass" within the password field of your new credential and locate your CyberArk credential that was created earlier.

Populate the metadata field with db/host1/pass so that the password returned from our API lookup against Conjur matches our "service01" account.

Finally, Click "ok" and then save your machine credential. You are done configuring the credential within Ansible Tower. 

To test out the entire integration and automated password lookup, build another Linux host and add the "service01" account as a user with the same password. This would obviously work equally well if your host was connected to a centralised LDAP directory.

#useradd -m service01
#passwd service01 < ‘contents from db/host1/pass’

Once that is done, add your test host to Ansible Tower’s inventory and run a ping module test.

A ping test is ideal because it will confirm that Ansible Tower was able to connect to your Linux host, authenticate and confirm that it is up. The ping test should output a result of type pong.

Cyberark’s security solutions provide a much greater capability than what is referenced in this blog. Feel free to explore further.

Takeaways and where to go next

Many organizations have enterprise vaults for storing passwords and credentials. Integrating with Ansible Tower means that you can avoid having another island for storing credentials. Plus, you will keep your security department happy by not introducing a new process into the authentication and access model.

If you want to learn more about CyberArk’s solution or the Red Hat Ansible Automation Platform, read one of the following articles:

• Introduction to CyberArk's Privileged Access Security solution 
• CyberArk Central Policy Manager Unix plugins
• Check out our Red Hat Ansible Automation Platform E-Books online.
• Sign up for updates to AnsibleFest 2020

Happy automating!