The new Okta Privileged Access product was featured in the recent Oktane23 conference. The product is currently (Oct 23) in early access with General Availability expected in Dec 23.
This article is a brief technical overview of Okta Privileged Access (OPA) looking at the components and functions of the product. It is written to provide a backdrop for future material looking at the capabilities of the product and to help architects understand where the pieces fit in the Okta landscape.
Note that this article covers both features available with the early access product and what has been announced as targeted for GA. As always these features may change by GA.
Components of Okta Privileged Access
The following figure provides an overview of the OPA components.
The product comprises a set of (optional) infrastructure components and multiple cloud tenants. Let’s start at the bottom and work our way up the figure.
To support infrastructure privileged access (server and, soon, kubernetes clusters) there are some installable components that are used – a Client that resides on the users workstation, an Agent that resides on the servers, and optionally a Gateway for network proxying. If you are familiar with Okta Advanced Server Access, these components are the same (more details can be found here). Note that Bastions are no longer used.
The next layer in the figure is the Okta Privileged Access tenant, called a “Team”. This is the cloud service for managing privileged access. It has it’s own datastore and also a Vault for storing credentials.
The next layer in the figure is the Okta platform, the Okta Workforce Identity Cloud. The Okta Privileged Access app (team) is represented as an application in Okta like any other SaaS application – it has SSO & provisioning, assigned users, push groups, authentication policies, and is in the OIN catalog. OPA will also leverage Universal Directory indirectly – through users and groups associated with the application. It will also leverage the System Log (more on this in the next section).
Sitting above WIC in the diagram are two components – Okta Access Requests and Okta Workflows. Okta Access Request is included in the OPA product in a limited form for a specific use case (see below), and extends access requests to other platforms like Slack/Teams and email. Okta Workflows is not part of the OPA product but may be useful for bespoke automation tasks (expect to see examples in articles on this site going forward).
All of these cloud components are sitting behind the Okta Dashboard.
Now lets dive into the functions provided by these components.
Functions of Okta Privileged Access
The following figure provides an overview of the OPA components in the context of the components.
Again, let’s start at the bottom and work our way up the diagram looking at the functions (blue boxes).
At the infrastructure layer the Gateway, in addition to providing the network proxying capability, can perform Session Recording of the SSH/RDP sessions flowing through it.
The Okta Privileged Access Team implements the PAM administration. This includes managing PAM Policy & Resources. Resources are the things were are controlling access to, such as servers and credentials (or secrets). Policy is how we control who can access these resources and how we control that. To control this, OPA is an Administrative RBAC model where management of resources can be separated from management of policy, and these roles can be delegated. Finally, the Vault enables the storage and control of access to secrets – Managed Credentials.
The Okta WIC platform also provides functionality leveraged by OPA in addition to hosting the OPA application. OPA is writing Privileged Events into the System Log and can be subject to custom reporting. As OPA continues to develop it will leverage the Reporting component in WIC for PAM out-of-the-box reports.
One of the policy controls implemented in OPA is the ability to run an access request when trying to access a resource. OPA includes a limited version of the Okta Access Requests component to implement Privileged Access Requests. OPA will call into Access Requests to raise a request which would then be reviewed/approved (say by a manager or service owner) and returns the result for OPA to allow or deny access to the resource. Whilst not part of the OPA product, Okta Access Requests (with an Okta Identity Governance license) could also be used to manage the groups memberships driving PAM roles and PAM policy assignment in OPA.
Not shown in this diagram is the new Cloud Infrastructure Entitlement Management (CIEM) capability.
This is a brief high-level view. There will be additional functionality as the product passes through GA and into 2024 and beyond, but the core architecture should remain.
