Automating CyberArk Administration Tasks

Michael Campbell, Senior Consultant, SecureITsource, Inc.

Automation is quickly taking over the network and infrastructure pieces of enterprise environments. Software is deployed at the click of a button and applications are communicating and working with other applications, not people. While we still need people to manage applications, we are not machines and we cannot work as quickly, efficiently or as powerfully as them. We still find ourselves working inside of these applications, making manual configuration changes and repeating ourselves over and over again. Thankfully there are ways we can utilize automation tools to do our jobs for us!

In this article I am going to be describing techniques for automating various parts of the administration of CyberArk, a software suite I use frequently and which requires the continuous onboarding of users, accounts, applications and configuration changes. Many of these techniques apply across the spectrum of applications but some are specific to CyberArk. The general message of this post is to work smarter, not harder. With a rudimentary knowledge of scripting, you can decrease the amount of time you spend on laborious manual work and increase the time you spend solving complex problems. If you are tasked with doing something more than once, script it!

PACLI

The CyberArk Vault Command Line Interface (PACLI) is the old-school interface for interacting with the CyberArk Vault. You can use it for user management, such as adding and deleting Vault users without logging into the otherwise cumbersome PrivateArk client. You can also manage safes, network areas, requests and more. PACLI is limited as far as what it can accomplish but I find it useful for performing quick Vault-level functions in a pinch as it is directly integrated with the Vault.

You can use the command line directly to harness PACLI or package a set of commands in a batch file. PACLI has its own syntax and while it works, I find iterating through lists of objects to act upon in batch files to be clunky. I have found PACLI to be most useful in cases where I can’t or don’t want to perform an action I should be able to in PrivateArk. For example, while setting up RADIUS authentication for a customer, we couldn’t switch a user’s authentication mechanism from LDAP for an unknown reason. It worked using PACLI. Now imagine having to do this for 100 user accounts. It’s a lot simpler to retrieve a list of all users and perform the same authentication change command across all their accounts using PACLI.

REST

Whereas I mentioned PACLI being old-school, REST is the new-school. Representational State Transfer, or REST, APIs are sets of rules that allow different services to interact. REST APIs are heavily used over the web and allow clients to perform actions on resources on a server. Most cloud services nowadays make a REST API available. REST calls are stateless and thus contain all information required to perform the action in the call. REST handles authentication, access tokens and create, read, update and delete (CRUD) commands through HTTP URIs. Most of the time, REST calls send and return a JSON response, which is easier to understand and parse than most other data structures, for example XML.

CyberArk makes their own REST API available and it is miles ahead of their PACLI program. It can do all the vault-level functions that PACLI can (plus more) as well as management for accounts, applications, platforms, and is a main component of CyberArk’s Central Credential Provider, which can retrieve application credentials at runtime in place of storing hardcoded credentials on a server. Most scripting and programming languages support REST making it the standard of choice for interacting with web services.

I’ve seen myself how small scripts can be inserted into the workflow of applications to interact with other applications to synchronize attributes across the two. For example, an infrastructure automation tool such as Ansible can make REST calls to CyberArk to onboard a newly created server’s privileged credentials to the Vault and create an application ID to prepare it for a Credential Provider installation. Ansible and CyberArk have a couple of official modules available on Ansible Galaxy that utilize the REST API to perform a myriad of neat functions including deploying an entire application credential provider environment.

As we can see, machines and software are using REST to get things done, why shouldn’t we? The level of automation you decide to use depends largely on what you’re working on, and it can be quite simple, but powerful, in many cases. For example, I have a script to create a safe and add a group of users with certain permissions. It can read in a list of safe names from the command line, a file, a previous REST call, or an array in the script itself. What used to take 10 minutes to an hour (depending on how many safes) now takes 30 seconds. I also use a script to create an application ID, set the authentication mechanisms, and add it to a safe. What used to take 5 minutes per application now takes 30 seconds. You can see how this can save a lot of time and clicking over time. I’ve also used scripts to migrate an entire environment including platforms, safes, applications, accounts and passwords.

My scripting language of choice is Powershell but the same can be accomplished with Python, Java, or any language really. I like Powershell because it has great community support. Instead of making web service calls directly, I prefer to use the psPAS module built by pspete. It turns every REST command into a function that can be called within Powershell. I find it to be easier to iterate over lists of resources I want to modify this way and it is simply a great library.

Below is an example of the script I mentioned above, which creates an application in the Vault with authentication methods and then adds it to a safe.

# Provide credentials

$Credentials = Get-Credential

# Create CyberArk Web Services Session

$token = New-PASSession -Credential $Credentials -BaseURI PVWAADDRESS -type RADIUS

# Import CSV of application and safe names and iterate over it

Import-Csv C:\cyberark\scripts\data\create_app_with_auth_in_safe.csv | Foreach-Object {

    # Create application

    $token | Add-PASApplication -AppID $_.Application -Location "\Applications"

    # Add application authentication methods

    $token | Add-PASApplicationAuthenticationMethod -AppID $_.Application `

        -AuthType certificateserialnumber -AuthValue CERTSERIALVALUE

    $token | Add-PASApplicationAuthenticationMethod -AppID $_.Application `

        -AuthType osUser -AuthValue DOMAIN\USER

    $token | Add-PASApplicationAuthenticationMethod -AppID $_.Application `

        -AuthType machineAddress -AuthValue ADDRESS

    # Add newly created application to safe

    $token | Add-PASSafeMember -SafeName $_.Safe -MemberName $_.Application `

        -SearchIn Vault `

        -ListAccounts $true `

        -RetrieveAccounts $true

}

# Close CyberArk Web Services Session
$token | Close-PASSession

The create_app_with_auth_in_safe.csv file is a simple comma separated list of applications and the safe they should be added to, like this:

Application,Safe

application1,safe1

application2,safe2

application3,safe3

In the above script, the $token variable is used to maintain the session across calls. After establishing the session, we import a list of applications and safes, and it iterates through each one, creating the application, adding the authentication methods, and then adding it to a safe. It could be modified easily to handle account onboarding. I’ll normally have a couple switches that are specified at run time to decide if it will perform certain actions, such as creating the safe if it doesn’t already exist. This could all be accomplished using Powershell Invoke-RestMethod cmdlets but pspete has spent so much time building out this toolset that it would be a waste of time (remember, we are trying to NOT waste time) not to use it.

SCIM

System for Cross-domain Identity Management, or SCIM, is a newer development built over REST, that was created specifically for automating the exchange of Identity information across systems. SCIM is very standardized and systems that support it can exchange information easily. It is used mostly by companies to provide user information to cloud-based applications. Since these applications are no longer in the same environment as a company’s applications, using internal tools like Active Directory and network shares no longer allow the exchange of identity information in a fast, secure and free of error manner.

CyberArk provides their own SCIM server which can be used to accept SCIM web service calls and uses PACLI and the Application Identity Manager to make the necessary changes in the Vault. This is a vital part of CyberArk’s PAM integration with Identity Provider tools such as SailPoint IdentityIQ. Since CyberArk supports SCIM (almost) out of the box, and the normal REST API handles everything I would want to accomplish, I haven’t needed to use SCIM for administration tasks, though I’m confident I could establish SCIM calls that list, add and remove users from CyberArk. What is more important however, is understanding how it works so that you can be prepared for integrating different identity systems, which you’ll now have time to do when you’re not bogged down manually administering privileged access!