Automating Ansible with Osirium PPA

Supercharging Ansible with Privileged Process Automation

Ansible has fast become the tool of choice for many IT operations, DevOps and NetOps teams. Its easy task and playbook creation, and cross-platform support make it an excellent solution for many IT Operations challenges.

However, although the playbooks are reasonably human-readable, they’re not really appropriate for non-technical users, especially outside the IT organisation.

Ansible Tower is an option to wrap Playbooks into a more user-friendly browser-based tool, but it’s still very technical. Tower has limited capability to interact with users (for example, all variables need to be provided via a Tower “survey”). Finally, Ansible can’t orchestrate operations outside the Ansible environment.

The good news is that Osirium’s Privileged Process Automation (PPA) tool formerly known as Opus is the perfect complement to Ansible to address those issues. Let’s take a look at how the integration works and the benefits Opus brings.

Start at the beginning – Ansible concepts

Playbook: At the heart of Ansible is the “Playbook.” It’s a YAML file that contains the tasks we want to execute on one or more servers to get them into the desired state. The playbook is descriptive. It defines a set order for tasks to be processed in a procedural and idempotent way (i.e. the operation can be repeated without changing the result).

Inventory: The inventory is a configuration file that defines the groups of hosts, and how to connect to them. Playbooks make references to this file, and, normally, playbooks only target a subset of the inventory. The inventory can be built from a variety of different sources.

Other configuration: Ansible has many ways of providing configuration. Configuration can be through the inventory, command-line arguments, environment variables, or in the playbooks themselves.

One thing that’s notably absent from Ansible is credential management. To execute many tasks, the playbook needs to run with elevated privileges, say to switch user context via “sudo” or even run a task module as “root”. For a good reason, Ansible recommends you don’t store those credentials (whether they’re passwords, certificates or other secrets) in the playbook. That’s not surprising! Ansible assumes they can be provided from a configuration file, via environment variables, or interactively when running the playbook. None of these options is desirable: they all leave credentials exposed and vulnerable. As we’ll see later, Opus solves these problems.

How does PPA integrate with Ansible?

The good news for the integration is that both Opus and Ansible are built using Python, making it easy for PPA to integrate via Ansible API. Opus can also use PowerShell, but that’s a topic for another article.

The API integration means PPA is not just a wrapper around Ansible command-line interface tools. PPA can hook directly into the “brain” of Ansible – its libraries – to do pretty much anything it wants.

In the video, you can see that the playbook progress is displayed with a native PPA progress bar, while the classic, more technical Ansible output is available in the logs. This gives the integration two levels of feedback, a human-friendly one, and the classic Ansible log for technical users.

Example use case: Developers

Also, in the video, you can see a developer use case in action. The user, a developer, provides the playbook file, the inventory file, and can load some extra secrets (sensitive data) from PPA vaults to finally execute the playbook. The strength of this approach is flexibility. You give your developers a ready-to-go Ansible environment to run their tasks without any kind of setup.

Example use case: Non-technical staff

As described earlier, Playbooks in YAML are intended to be “human-readable”, but they’re still pretty complex for non-technical staff who would never consider running any operations via a command-line interface.

With Opus, you can build a task that contains all the variable information built-in: playbook, inventory and secrets (provided from a secure privilege credential vault such as Osirium’s PxM or a password vault such as Hashicorp). Any user with zero Ansible knowledge can execute tasks that were originally written in Ansible. You can have one Opus task per playbook, or you can have “master” Opus tasks that let you choose one or more playbook from a list, depending on the use case.

The tasks available to the user are controlled by PPA depending on the user’s role in Active Directory or PxM. You can also enforce process rules such as requiring an approved ServiceNow ticket before starting the task, which can also ensure the ServiceNow ticket gets updated with the full audit trail once the playbook has completed.

Benefits of using Ansible with PPA

1. Security: As we’ve seen, secrets are stored in PPA vaults, so the users running the tasks never need to have access to them. In the second example use case, you can also hide playbook and inventory files, to reduce the information the user needs to run the task to the bare minimum.
2. Zero-knowledge: In the first example, there is no need to set up an Ansible environment. In the second case, you don’t even need to know what Ansible is or how it works. This makes Ansible useful for the whole company while it doesn’t enforce all users to learn Ansible.
3. Orchestration: Ansible is a great tool for putting hosts into a given state, but its nature is descriptive and purely procedural. You cannot do proper orchestration with it. By wrapping Ansible with an Opus task, you also provide a way of making the Ansible playbook be an orchestration block that composes a bigger, more complex task, an Opus task. You can orchestrate a number of steps that go beyond the Ansible environment, for example integration with a help desk system (for example, ServiceNow), changing settings within a tool (for example, updating Infoblox settings according to corporate policies), while using an Ansible script in the workflow to ensure the necessary services are installed, up-to-date and running.
4. Audit trail: Although Ansible has excellent logging, Opus provides a complete end-to-end audit trail of operations across multiple systems, including Ansible tasks. It can update help desk systems such as ServiceNow. PPA has a complete, end-to-end audit trail without the user or auditor having to find and scan multiple system logs.

Ansible + PPA = Dream DevOps environment

As we’ve seen, Ansible is a very powerful operations automation engine while Opus provides a rich, secure, easy to use automation environment that addresses broader automation needs. The combination is highly powerful and will drive major improvements in reducing complexity, risk and cost in DevOps teams.

If you’d like to see the demo live or have any questions, please get in touch.