Cyberark Central Credential provider has some killer features with one of particular interest(for this article that is) which is the ability to have a different password per host. It seems pretty bonkers to think you can maintain separate passwords for 100 different devices, but CA does it, and not only that, it has facilities that can change the password each time it’s used *galaxy brain*.

This post demonstrates how to do a per-host lookup inside the Tower/Control environment.

Demo Video

Cyberark Setup

In my CA environment I have a safe named “test” that I’m using.
In the root folder of test I’ve created three password objects, each for the switches I plan to connect to. Each object is named the same as the inventory hostname from ansible: sw1, sw2, sw3.

All of the connection info along with the walkthrough is in my CA AIM blog post.

Playbook

I’m first going to say that given my drothers I would have used the Cyberark lookup plugin, but you have to have the Central Credential software installed on your server, and I’ve yet to get a copy of it. The playbook to make that work is here:

I instead used the cyberark collection that contains the cyberark_credential module.

Looking at the playbook above I have a variable that I’ve setup(and I’m replacing at runtime from my tower environment) named ca_base_url.
The other cyberark info is just presented plain text, but notice that I had to supply my cert and key. This is why I wanted to use the lookup plugin, so I wouldn’t have to put a link to the cert/key anytime I wanted to use it…but I digress.

The real magic happens in the query section of the first task:

1

query: "Safe=test;Object={{ inventory_hostname }}"

I’m connecting to the safe named “test” and for each host in the current run I’m pulling the password object that is named the same as their “inventory_name”. Having these two match is how I key the two items together(the host to their respective password).

I next set the ansible_password variable for each host based on the password I just looked up. Now, when ansible subsequently attempts to connect to any inventory host it will do so via the password that was just pulled.

Make note that any task that either did the lookup or set the variables also had the no_log option set to true so that the passwords are never exposed in the logging.

Conclusion

The Cyberark per-host lookup process isn’t too difficult, it’s just a slight mind-shift from what we are used to. If you have any questions or comments, please let me know. Thanks and happy automating!

Collections are the new hotness for ansible, so you should start adjusting to it now…that means I’ll have to start converting my playbooks little by little now. That’s because ansible 2.9 allows for both standard modules and collections to work in tandem. So do the thing if you haven’t already.

You have multiple options when trying to install collections into your tower environment, and I’m going to cover a couple here.

Manual collection install

If you are going to manually install these files from the CLI, keep in mind that Tower runs as the AWX user, so you will need to su awx before doing most of these installs.
First you can pull collections straight from Ansible galaxy.

1

ansible-galaxy collection install my_namespace.my_collection

You can also download the archive file and do an offline install:

1

ansible-galaxy collection install my_namespace-my_collection-1.0.0.tar.gz -p ./collections

You can download certified collections via the automation hub(it allows you to grab them as archives right off the cloud.redhat.com site). After that the install process is just the same.

Automatic collection install

The best way to automatically pull collections is via a requirements file.

First, in your git repository(or other SCM system) create a folder called “collections” and add a file inside named “requirements.yml”
So I wanted to dynamically pull the Arista EOS collection so I did it as follows(/collections/requirements.yml):

1
2
3
4

---
collections:
# Install the Arista EOS collection
- arista.eos

Now when I run the playbook it will reach out to the repository in question and pull the content.
Keep in mind that it doesn’t fully install the collection. I can’t create a new repo with playbooks and start using that collection without either a manual install or a requirements file. It’s for this reason that in my lab environment I simply do a manual install so I can use it in all of my playbooks without keeping track.

If you are using certified content and you want to pull directly from the Automation hub, look at this documentation; it walks through the settings required.
In newer versions of Tower/control the “Primary Galaxy Server” options are no longer present and that portion will be completed via custom credentials as shown in this video.
Here’s the screen shots from my machine:
First I created two credentials:

The first connects to the automation hub:

Galaxy Server URL:

1

https://cloud.redhat.com/api/automation-hub/

Auth Server URL:

1

https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token

I then create a credential to connect to the standard public galaxy servers:

I now set the Tower/control server to use these creds:


The order in which you select them is the order in which the server will check for download. In my case I want to ensure that my automation hub link is set first, so it will check there, then fall back to checking galaxy. That means I’ll unselect them both, then add them back in the correct order:

Good luck and happy automating!