Introducing Secrets Management in Okta Privileged Access

This article explores the new secrets management capability within Okta Privileged Access.

Introduction to Secrets Management

A key feature of the new Okta Privileged Access product is the introduction of a vault to securely store credentials (or secrets). With the initial release of the product this unlocks two critical use cases:

• Generic Secrets Management – where the vault is a container for any secret with controls around who can access or manage secrets and how they can access them.
• Securing Privileged Accounts – where shared admin accounts (such as super admin, shared or service accounts) are discovered on servers (and other resource types in the future), managed in the vault and controls can be applied to who can use these credentials and how.

This article will explore the first use case.

For further information on Okta Privileged Access and the concepts in this article, see the Okta Privileged Access page on this site – https://iamse.blog/pam-incl-asa/oig-privileged-access/.

The Vault, Secrets and Folders

The vault is a separate component in Okta Privileged Access that is built to leverage Amazon Web Services Nitro Enclaves. To quote the AWS website “Enclaves offers an isolated, hardened, and highly constrained environment to host security-critical applications. Nitro Enclaves includes cryptographic attestation for your software, so that you can be sure that only authorized code is running, as well as integration with the AWS Key Management Service, so that only your enclaves can access sensitive material.”. This all resides within Okta’s cell-based architecture (more info in this pdf file).

To support a delegated management model a hierarchical folder structure is used to store secrets.

Secrets are name-value pairs, where the value is some encrypted text. It could be an account password, or an API key, or some other bit of text you want to securely manage.

Secrets reside in folders and security policy can be applied to folders or specific secrets. There are top-level folders and sub folders that can be used to build a folder hierarchy. If a policy is applied to a folder that has sub folders, the policy will apply to all the sub folders. Thus you can structure your folder hierarchy to suit who needs access to specific secrets and folders – perhaps you have a distributed business where there are different owners of sets of secrets.

Top-level folders are assigned to projects in resource groups. This is for assignment of resource administrators to manage (create, edit and delete) the top-level folders. However this does not apply to sub folders, which are managed based on policy applied.

Resource Administration and Security Policy

Okta Privileged Access has been built around a strict separation of administrative duties model. There are PAM Administrators who can assign others to different roles, Resource Administrators who manage the resources, and Security Administrators for managing the policy to determine who can access the resources and how.

With Generic Secrets, the resources are the secrets and the folders that store them, and the policies dictate what actions can be performed against the folders and secrets. The operations that can be performed are:

• List secrets or folders
• Create, Update and/or Delete folders
• Create, Update and/or Delete secrets, and
• Reveal secrets

This means that an administrative role for secrets could involve management of resources, so admins defined as principals in a policy may also need to be delegated administrators of some projects storing folders and secrets.

You can define security policies to allow users to manage both top-level folders and sub folders (as well as secrets). The exception to this is top-level folders can only be created by resource administrators (or delegated resource administrators). This is because you need to assign policy to a folder, so there must be a top-level folder there at some point. But once a top-level folder has been created you can have a policy to allow others to update or delete it. Note that you can assign admin groups as Delegated Administrators to the Resource Groups containing top-level folders to give the group users full control over the top-level folders.

The following figure shows some examples of how policy could be defined to manage folders and secrets.

The “Create top-level folders” box (solid line) represents the resource administrators associated with the resource group / project. 

The other three boxes show different policies that could be applied:

• You could have a “Reveal secrets” policy that only allows the policy principals (who the policy applies to) to reveal secrets and traverse the tree to get to them.
• You could have a “Manage all folders and secrets” policy that allows the principals to create, update and delete all secrets and folders from a top-level folder down.
• You could have a “Manage some folders and secrets” policy that allows the principals to create, update and delete secrets and folders at and below a specific sub folder.

These are just examples, and you can tailor your policy to suit your access and management needs.

An Example of Generic Secrets Management

Let’s walk through an example to show how the concepts above apply.

We have a fictional company where they need to manage secrets for some software on servers managed by system admins. They have a multi-department approach where there are admins in each department responsible for managing their own departments secrets, as well as a company-wide security admin team, and then users (like sysadmins) who need to access secrets for specific accounts.

If you have an environment available, you will get more benefit by following along.

The configuration in Okta and Okta Privileged Access

First, let’s look at the configuration in Okta and Okta Privileged Access to support this scenario.

Okta Users and Groups

In Okta, the are four Okta users:

• Sam SecretAdmin – her role is to manage the secret infrastructure across the entire organization
• Dave DeptAAdmin – his role is to manage the secret infrastructure for DeptA only
• Larry LinuxAdmin and Louise LinuxAdmin – they are Linux sysadmins who need to access some secrets in DeptA as part of their day-to-day role.

There are three Okta groups to correspond to these users as shown below.

All these users are assigned to the Okta Privileged Access application in Okta via the three groups. You could have a single group for all Okta Privileged Access users assigned to the app.

The three groups are also assigned as Push Groups for the application.

This means they, and their user membership, are available to Okta Privileged Access to be mapped as administrator roles and/or assigned to policies as participants. The idea of having Okta groups managed in Okta and pushed to Okta Privileged Access is not unique to secrets management, but applies equally across the application.

Note that none of the groups are assigned to Okta Privileged Access roles. None of the users in these groups needs to be system-wide resource or policy administrators. We will assign the superadmin group as a Delegated Resource Admin in the Resource Group.

Resource Groups and Projects

We have created a single company-wide secrets resource group and assigned the superadmin group to it.

This means that the users in the OPA-Secrets-Superadmin group are resource admins in this resource group and could perform all admin functions on secrets, servers and any other (future) resources in the projects. You can’t scope these delegated admin roles down to specific resource types, so you should limit and manage who is assigned to these roles.

Note that the admin role assignment is at the resource group level, not the project level, so you may need to think about what the structure of the resource groups and projects needs to be for the admin roles in your implementation.

Now let’s switch over to Sam SecretAdmin and see what she can do to define some top-level folders.

Defining Top-Level Folders as the SecretAdmin

As Sam is in a group giving Resource Administration rights, she see’s Resource Administration in her Okta Privileged Access UI in addition to the user menu items.

Within Resource Management she only sees one resource group (this system has other resource groups for server use cases). She can edit the resource group and manage the projects within it.

She can create, update and delete top-level folders.

But there is no mechanism to create sub folders in these top-level folders. That is based on policy assigned to the folders. This is not something that Sam can do as she is not a security policy administrator (although she could be if needed).

We can see this by looking at the Secrets menu – there are none showing, even though three top-level secrets have been defined.

Let’s return to the user who has a system-wide security policy admin role and define the policies we need.

Define Secrets Policies

We will define some policies for management of folders and secrets. First we create a policy to grant the superadmin group access.

We create a policy rule for each of the top-level folders, granting full access.

Note that you can only have one top-level folder per rule and a policy can have thirty rules. These constraints may affect the design of your policies.

When published, the superadmin user (Sam SuperAdmin) should see all top-level folders in their Secrets view.

The policy is working as expected.

Next we need to create policies to allow both the DeptA admins and DeptA users to have access. As principals are at the policy level, we need two different policies for the two different user groups.

The DeptA admins policy is set to apply to the DeptA top-level folder and allows all operations on the folders and secrets (we have not included a screenshot). The DeptA users policy is set to apply to the DeptA top-level folder and allows only the list and reveal operations.

We now have three policies, one for each of the user groups and all published.

We should be able to manage folders and secrets as Dave the DepartmentA administrator.

Managing Folders and Secrets

As Dave (DeptAAdmin) we can see the secrets/folders and actions he can perform.

First, he can only see the DeptA-Secrets in the Secrets view, not the other two department top-level folders as Sam could. Also, note that the menu items are restricted – Dave is not a resource administrator or delegated resource administrator in Okta Privileged Access so he does not see the Resource Administrator menu items.

If Dave clicks into the DeptA-Secrets folder, he has administrator privileges in there. There are no secrets or folders yet, but he can create sub folders.

Once he has created sub-folders, he can then edit/delete them.

Within a folder he can create further sub folders or secrets. With secrets, he can add, modify and delete them.

So the Department A admins can administer the folders and secrets. What about the Linux sysadmins who only need to search through folders and reveal secrets?

User (Linux Sysadmin) View

If our Linux sysadmin, Larry, goes to Secrets in Okta Privileged Access, they see only the DeptA-Secrets folder.

They can go into the folder and whilst the create, update, delete functions are shown, they cannot perform those operations. But they can reveal the secrets.

This shows that the policies setup earlier are working as expected.

The same result applies if using the Okta Privileged Access client in the command line.

This can be useful for accessing secrets in scripts, but does require a client to be enrolled and authenticated.

This concludes the example.

Conclusion

Storing and managing access to secrets is a key new use case for the Okta Privileged Access vault, adding to the Securing Privileged Accounts use case for server access.

In this article we have introduced the secrets management concepts and how it fits into the Okta Privileged Access resources and policy framework. This framework provides for a lot of flexibility in delegated administration of secrets through folders and rights on those folders. Different teams of admins and users can be assigned to different sets of folders and secrets across a company, reducing the risk of exposing secrets to too many people. We have also explored an example of implementing secrets management with different roles of users to see how it’s done.

This is just the start with secrets management. We have not covered controls, such as Access Requests, around accessing secrets. As the product progresses we will see cloud platform and SaaS app-specific integrations for the vault.