This article looks at how Okta Privileged Access (OPA) can leverage DevOps tooling for automation in large infrastructure environments.
Introduction
Okta Privileged Access (OPA) provides privileged access management (PAM) for multiple use cases, such as securing access to privileged credentials (secrets) and privileged access to servers. Where there is a large environment needing PAM, customers often look to devops tooling to install and maintain components.
The following figure shows the architecture of OPA.
It comprises a number of cloud services (OPA, Okta WIC and Okta Access Requests) plus infrastructure components that are deployed to customer machines. These include the OPA Client deployed to user workstations, the OPA (Server) Agent deployed to servers and optionally a Gateway. More details on the components and interactions can be found in https://iamse.blog/2023/10/17/a-technical-introduction-to-okta-privileged-access/.
From an automation perspective it is common to look at the deployment and management of clients, and the deployment and automation of agents and gateways (highlighted in red). You may also find some automation of polices, resources and roles (highlighted in green).
The infrastructure components (Client, Agent and Gateway) are the same as for OPA’s predecessor, Okta Advanced Server Access (ASA), so the mechanisms available for automation are largely the same.
Client Deployment and Management
OPA Clients are software components installed onto user’s workstations. The client is supported on macOS, Windows and multiple flavours of Linux (see the list of supported operating systems).
Whilst the client can be installed manually, many organisations deploy and manage the MSI/package via their normal software deployment tool.
Once the client software component is installed, the user must enroll the client, and in the process authenticate against Okta/OPA. In some instances you can also silently install the OPA client (which includes auto enrollment).
Agent and Gateway Deployment and Management
There are different approaches to automation of the deployment and management of Agents and Gateways, including:
- Baking the components and enrollment tokens into a “gold” image
- Including deployment into run scripts provided by the cloud platform
- Include in devops scripts to create/start a server instance in a cloud platform
- Leveraging a devops tool like Terraform, Chef, Puppet, or Ansible
We will explore some of these.
Baked into the Image
If you leverage “gold” images or use something like Docker to deploy new instances of a server, you could bake in the relevant OPA agent (or gateway) and enrollment key into that image. When you run up an instance of that image, the new server will connect to OPA and be put into the Resource Group / Project associated with that enrollment token.
This may be appropriate if there are standard images for server types (e.g. web servers, DB servers) and you want them to be managed in the same way with OPA. You would need to ensure that any Policies you have would automatically adapt to new instances of the image starting up (e.g. using labels tied to the image, either system generated or custom, rather than tying policy to hostnames or IPs).
This approach will not provide for any sort of management of the Agent (or Gateway). It will remain at the version that was baked into the image unless some other form of systems management is applied. The image should be regularly updated with the latest Agent (or Gateway).
Included in IaaS Run Scripts
Cloud platforms, such as AWS, have mechanisms to run scripts on instance startup. For example you can use the user data field on an AWS instance to run a script (see https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html).
The code to install the Agent (or Gateway) and enroll could be added to the run scripts.
Note that the following is an old example and should not be used verbatim. Check with the deploy and manage servers section of the product documentation.
Depending on the platform you may be able to parameterise the script and also to get the latest version. But this is for server startup and not for ongoing maintenance.
Included in Build Scripts for DevOps Tools
If you use a DevOps tool, like Terraform, you can also pass commands into the startup process. The following is an example of a Terraform script (main,tf in his case) to build a new server in AWS and has code passed to the AWS user_data field to run the install and enrollment of the Agent.
This can be parameterised (e.g. using a variables.tf file or similar) to pass in arguments to run. Again this is a start state and this mechanism will not perform any management of the Agent once installed.
Many of the DevOps tools, like Terraform, Chef, Puppet and Ansible, can be used with OPA, but none of them have out-of-the-box capabilities for managing the infrastructure components. For example Terraform has an Okta Provider and an Okta Advanced Server Access Provider that can build objects in Okta or ASA (like groups) but neither will manage the Client, Agent or Gateway software packages. You need to add the native script commands into the tool, such as the example above.
Note that the Okta ASA Provider for Terraform will not work with OPA given the significant change to the data model. an Okta OPA Provider is not yet available.
Examples and Samples
This section looks at some large-scale examples and provides links to some sample code. the two examples are based on Okta Advanced Server Access (ASA) but as the Agents are the same for both ASA and OPA, the mechanisms could be applied to OPA (except for highlighted exceptions).
Terraform Example
The following diagram shows how a customer with large and dynamic server environment was able to leverage Terraform to automate deployment of the ASA agent and some ASA configuration into the process of running up a new server instance.
When a new customer signs up for their service, a set of Terraform scripts are run to create a new tenant for that customer. There are two parallel streams:
- The top stream in the diagram is using the (ASA) Terraform provider to create a new Project in ASA, assign Groups to that project and generate an Enrollment token for the Project.
- The bottom stream is creating the objects in AWS, a VPC and EC2 server instances. This includes installing the ASA agent onto the servers and using the Enrollment token from the other stream to enroll the server instances into the Project
This means that as a new tenant is spun up for a customer, the Agent is installed and assigned to the Project which grants admins access to connect to the server instances.
Note that this is for ASA and leverages the ASA Terraform provider for the ASA objects (project, group assignment and enrollment token). The Terraform provider has not yet been updated to cover the new OPA data model. To implement this mechanism with OPA would involve using the OPA API instead of the Terraform provider.
More details on this can be found at https://developer.okta.com/blog/2020/04/24/okta-terraform-automate-identity-and-infrastructure and https://www.okta.com/blog/2020/04/adapting-to-the-cloud-operating-model-using-okta-hashicorp.
Ansible Example
Terraform is great when you can describe your environment programmatically and you manage everything by creating/destroying instances. But for systems outside of this, you need a solution that can be used like a systems management tool to manage the installations.
Most systems management tools will support this. They need to be able to know about the servers and be able to run scripts on the servers. For ASA or OPA you could build scripts to install/enroll the agent, check if the agent is running and restart it if it’s not and even check for outdated and update it.
There are many large scale ASA customers who have done this with Ansible.
Some Sample Code
Some colleagues were developing a set of OPA utilities that are available at https://github.com/Okta-PAM-Resource-Kit. These are not provided by, nor supported by, Okta and are provided as examples to help with OPA deployments.
Under the scripts/installation folder are scripts for both Linux and Windows agent installation.
The Linux script will:
- Add the OPA/ASA repos to the local package manager when possible, allowing easy updates using standard tools
- Test for the presence of TLS inspection (MITM) which would interfere with outbound calls to Okta
- Extract a useful server name from the “Name” tag in AWS. (Allow tags in instance metadata must be enabled.)
- Create default configuration files for ASA Server Tools and ASA Gateway
- Create enrollment token file for ASA Server Tools
- Create setup token file for ASA Gateway
- And finally, install OPA/ASA Server Tools, OPA/ASA Gateway (and Transcoder on RDP capable OSes), OPA/ASA Client Tools, or any combination of the three.
The Windows script comes in both a CMD and PowerShell form, and is similar to the Linux script.
These scripts could be used as examples for implementing automation in Terraform, Ansible or other DevOps tools.
Conclusion
This article has looked at how automation can be applied to an Okta Privileged Access deployment, particularly the infrastructure components such as the Client and Agent. It has looked at how automation could be applied to both the initial install of the components and also the ongoing management of them, with some examples and links to sample code.
