If you haven’t already, I recommend you spend a bit of time taking a look at https://www.osirium.com/automation That tells the story of why secure automation, built on the Osirium Privileged Process Automation (PPA) framework, is the IT Process Automation (ITPA) solution needed by service desks, IT operations teams, admins, DevOps and much more.
In this article, I’m going to focus on the concepts and technology behind PPA so you get a better idea of how it’s deployed, managed and integrates with your existing systems and processes. Along the way, we’ll see how to:
This video sums it all up:
To help us get started, here’s what we call the various elements of a privileged process:#
All these modes are closely linked. If you wish, a single process could be written to be invoked in all three different modes. Equally, any task could switch during execution. For example, an automated process may be invoked from ServiceNow but, if necessary, it can switch to requiring human interaction to confirm/approve a choice or review results. (You can see this in action here)
PPA tasks are hosted within Docker Containers which we’ll get into later. These tasks can be written in different languages, for example, Active Directory tasks might be written in PowerShell while network switch operations are written in Python. You choose what works best for you depending on the system and your available skills. Importantly, these tasks never contain admin credentials or keys with isolation via a vault proxy.
PPA abstracts access to credentials via a proxy. That means the code never needs to know what vault it’s using, and the developer of the process never has access.
Besides the protection immediately gained, the proxy goes further and ensures that code can move from dev to test to production easily and securely with no risk that test credentials get into production or vice versa. The proxy also removes the need to worry about different vault providers. You may have multiple vaults in your business such as Osirium PAM or HashiCorp Vault but no code changes are needed to move between the providers.
So what does this isolation, or proxy, look like?
Clearly, embedded credentials in source code is an accident waiting to happen.
As an example, traditionally a script might have:
The PPA version is slightly longer but adds a huge amount of protection:
Note that the code is not vault-specific, so during development, a vault with test credentials can be used but when the code makes it to the production environment, a completely different vault will be used.
Also, this code can only be compiled and run within the PPA appliance which is also protected from unauthorised access.
You can use any number of Docker base images, although we provide some neatly packaged pre-baked ones.
The base images will have the file systems, network, languages and library dependencies you need along with some PPA specifics:
There are some optional libraries that can be included to simplify the development effort, by default, that includes libraries for Active Directory, InfoBlox, Cisco, ServiceNow, Checkpoint and others.
This is an especially powerful capability of PPA. All input and output is handled via a web interface and provides a set of simple UI primitives that add very rich interaction options.
Take this example: In an existing script, you might have code such as this:
Which returns a very simple, but not very intuitive result to the console:
For a PPA version, this would be changed to:
The PPA version will give you a rich user experience.
You’ll even get rich functionality “for free” such as sorting results and even a CSV download option. It’s also ready for changes, as PPA adds more capability to the UI library, for example in the way the table is formatted, the process gets the benefit without any code changes.
What’s really cool here is that if the PPA team improve the way that they layout tables – then the process code does not change, a new version of the PPA appliance results in a new layout with no code changes.
If you’re interested, the UI documentation can be found here: PPA Documentation.
There are three main “roles” for human interactions with processes:
The Process Operator may also be an Approver for some processes. A simple example might be where ServiceNow has used business rules to initiate a PPA process. The Operator might be required to approve actions that the PPA Process will make, or perhaps to provide missing information so that a process can complete.
As we’ve seen the process has been isolated from the admin credentials via the proxy vault and the UI is abstracted from the code. That prevents any accidental exposure of dev or test credentials to production systems or production credentials revealed to developers. Because PPA Processes are well contained and carry all their dependencies with them – they can move from UAT to Production without developer intervention. Now, this has to be a good thing!
Your existing DevOps pipeline can be used to deploy the PPA containers – and PPA can even help with that as you can see in this example using Ansible.