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.
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.
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.
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.
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.
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.