Ping Identity Configuration Made Easy with Terraform

TLDR – Ping Access Configuration Management – With Terraform – The Devops Way – Expensive bespoke tooling not required.


At Raidiam we are all about enabling businesses to deliver delightful secure digital experiences rapidly, safely and most importantly with control. Unfortunately, in our experience, many organisations embracing “the API” as a primary business channel focus on Design and Build before attempting to “wire-in” services into API Gateways and API Managers.  Run considerations, in particular, change processes more often than not, fail to be factored into the costs of implementation. In addition, API gateways are quite often deployed as shared services. When change is executed poorly it can be quite costly and impact more applications and services than the one that was intended to be altered.

We have found this to be equally true for all Identity and Access Management products where declarative configuration options are not available including deployments of, Ping Identity’s, projects; in this article we will demonstrate the free, open-source terraform provider that can be used to manage multiple Ping Access  environments, control their configuration state, promote changes to different environments, detect manually applied configuration changes and if required revert deployment changes to previously known good configurations.

We believe that Security Concerns and DevOps are not separate disciplines or responsibilities but a mind-set and that ownership for the final quality and security of the delivery should be held by all members of a technology team.

By ensuring that industry standard DevOps tooling and DevOps practices can be utilised through to production without requiring significant specialist skill sets and change teams, not only will organisations reap the benefits of increased change velocity, they will do so with increased confidence that their most valuable asset, customer trust is being well managed.


Terraform to the rescue


Those IT Professionals that have been involved in Tier 1 mission critical systems change know that modifying a single service in production can involve extensive change control documents that painstaking detail how to apply even the most simplest of change. They often include, significant pre-change checks, Painstaking Post Change Checks and then updates to configuration databases to reflect the “current state” which, at this point usually only reflects that current desired state.

By leveraging Terraform organisations can use Infrastructure as Code practices to provision and manage any cloud, infrastructure or service. Teams can  define infrastructure target state and using tooling to manage the full lifecycle — create new resources, manage existing ones, and destroy those no longer needed.

For those that aren’t familiar with HashiCorp Terraform, in their own words:

Terraform is a tool for building, changing, and versioning infrastructure safely and efficiently. Terraform can manage existing and popular service providers as well as custom in-house solutions.

Configuration files describe to Terraform the components needed to run a single application or your entire datacenter. Terraform generates an execution plan describing what it will do to reach the desired state, and then executes it to build the described infrastructure. As the configuration changes, Terraform is able to determine what changed and create incremental execution plans which can be applied

By declaratively defining the target state, technology operations teams can detect configuration drift such as manual changes (Security Issue!), by comparing the “deployed state” with the desired state.

This article doesn’t intend to go into all of the aspects of state management and the benefits the use of terraform can bring to the software and virtual infrastructure delivery life cycle. As an industry standard practice and toolset it should be familiar to most developers and operations teams. What might not be familiar is how you can use Terraform to manage Ping Identity products and automate the “last-mile” of service deployment and change.


Ping Access Terraform Provider

The Ping Access Terraform Provider is an Open Source project, formally listed as a Terraform community project by Hashicorp. It is well documented actively being maintained and supports the latest version of Ping Access 6.0.

For a demonstration of how it can be used, this article will leverage a local instance of Ping Access launched using the Ping Access DevOps Docker Image with an empty configuration and will demonstrate creating the following resources

  • A virtual host
  • A target site
  • A rule – CORS policy
  • An application linking the host, site and policy together


A simple beginning

Not much to show at this point, we have a vanilla Ping Access without any configuration applied.

Review, Plan, Apply

 In the following 30 second clip we are reviewing the terraform configuration, asking terraform to create a plan outlining the changes that it believes need to be made to bring our deployed environment to target state, before finally we apply the plan.

Reviewing our deployed environment we can now see all of our resources successfully deployed and the application has wired in a virtual host and the site successfully.


But what if someone makes a manual change? In this next example we’re making a manual change to CORS Rule, changing the protocol from http to https.

Undetected manual changes… a thing of the past!

Here we can see that terraform has interrogated the deployed state and compared it with the desired target state. In this case at the top of the screen you can see that it is planning on “removing” – https://localhost:8080 and “adding” + http://localhost:8080. Applying the plan

Resource Management 101

When you finished with resources, or in this case an entire deployment a simple Terraform destroy removes all of the resources.

Awesome –

But how do bring my existing estate under control?

Here, Raidiam has your back, we’ve developed processes and tooling to be able to convert existing deployments to native terraform configuration for the Open Source provider. If you need help with the provider or find it useful, please consider sponsoring the project.

Finally, what about Ping Federate? Watch this space – more news coming soon.