Teleport for Ansible with ARA

This post aims to highlight the power of Teleport applications and show how it can massively simplify life by providing access to centralized collaborative systems which are otherwise inaccessible.

If you're wondering what ARA is I recommend reading up on it. The TL;DR is ARA Records Ansible and presents the information in a very understandable way. You can explore logs, collaborate on issues, identify gaps in automation, and more.

So what do torture chambers and wicker baskets have in common? Uber nerds generally have both in their homes. This post will show how I leverage Teleport applications and ARA to centralize Ansible logging in a secure and efficient way.

• Teleport == the wicker basket
• Ansible Logging == the torture chamber

Overview

I have Teleport running on my servers and have been loving it. Recently I've ventured into running Teleport applications, which has also been wonderful. To get Teleport to provide application access for ARA, I run the following simple configuration in my teleport.yaml file on the ARA-Server.

If you need to brush up on running teleport applications, have a look at their docs.

app_service:
  enabled: true
  debug_app: false
  apps:
  - name: ara
    uri: http://127.0.0.1:8000
    insecure_skip_verify: true
    rewrite:
      redirect:
        - "127.0.0.1:8000"
        - "127.0.0.1"

The application config I am using will provide access to my ARA server via teleport on localhost using port 8000. If you've seen my ARA server setup post, you'll remember that I've bound the ARA API to only localhost, which is useful for security but not great for usability; however, Teleport is here to marry security and usability together in Blasphemous Matrimony.

Client Setup

My Ansible client is like most other Cro-Magnon operators; I have a laptop with Ansible installed via brew.

You can read up on installing Ansible if needed here.

You can read up on installing ARA in your client environment here.

Login to the Teleport ARA Application

With our application configuration deployed, we need to login to access it.

tsh apps login ara

Once logged in, Teleport will store a key and certificate file which we'll use in our ARA configuration for API access.

These are the environment variables I set for ARA.

export ARA_API_CERT=$(tsh apps config --format=cert ara)
export ARA_API_KEY=$(tsh apps config --format=key ara)
export ANSIBLE_CALLBACK_PLUGINS="$(python3 -m ara.setup.callback_plugins)"
export ARA_API_CLIENT="http"
export ARA_API_SERVER="$(tsh apps config --format=uri ara)"
export ANSIBLE_LOAD_CALLBACK_PLUGINS=True

Now that we're logged in and have our configuration all defined, we run our Ansible playbooks normally.

ansible-playbook -i inventory.yml ping-hosts.yml

Once the playbook completes, we can pursue our Ansible execution via ARA CLI.

ara playbook list

The output will look something like this.

+----+-----------+---------------------------+-----------+-----------------+----------------------------------------------+-------+---------+-------+-----------------------------+-----------------+
| id | status    | controller                | user      | ansible_version | path                                         | tasks | results | hosts | started                     | duration        |
+----+-----------+---------------------------+-----------+-----------------+----------------------------------------------+-------+---------+-------+-----------------------------+-----------------+
|  2 | completed | zombie-x1                 | cloudnull | 2.14.4          | ...Projects/ansible-playbooks/ping-hosts.yml |     1 |      11 |    11 | 2023-04-06T01:29:39.886339Z | 00:00:10.206873 |
+----+-----------+---------------------------+-----------+-----------------+----------------------------------------------+-------+---------+-------+-----------------------------+-----------------+

And we can also use ARA Web UI.

Interaction Diagram

For those interested, here's an interaction diagram.

From the diagram, we can see the operator workflow really hasn't changed. Operators can go about their business without worrying about where and how their Ansible logs are being stored.

Fin

So the setup is simple, we created a tiny Teleport application for ARA and defined some config on our client machine. While this workflow does require I login to the ARA application before running operations, everything else is unchanged from the status quo; Teleport allows me to securely centralize my Ansible logging without impacting my day-to-day. I can run ad-hoc tasks, playbooks, and more from the comfort of my laptop, and I can review operations later using the ARA CLI or Web UI.

This type of setup would be hugely beneficial in an Initech environment where humans come together to collectively share their daily grind, especially if you use teleport as a dynamic inventory source. Teams can run Ansible operations and securely review logs collaboratively, which is huge when it comes to after-action reports, bug hunts, post-mortems, eliminating variance, improving idempotency, etc. So, in short, Teleport + Ansible + ARA is a powerful combination and will help your teams easily achieve more without actually having to do more.