In a recent engagement a customer raised issues around management of secrets and folder,s and associated policies and users in their Okta Privileged Access (OPA) deployment. In the spirit of the mantra of Mr Bigweld in Robots “see a need, fill a need“, I set about writing some utilities to help manage larger, more-complex Secrets deployments. This article summarises what I’ve built.
A link to the Workflows download can be found at the bottom of the article.
Background
Secrets is a resource type in Okta Privileged Access (OPA) which has been with the product since it became Generally Available. The Secrets capability involves folders that can be applied in a hierarchy with policies applied to different levels of the folder tree and leveraging inheritance. This makes it very flexible where different folders can be used and managed by different parts of a business.
But with flexibility comes potential complexity. Customers with large/deep folder structures face challenges in visualising the structure and where policies are applied. As an administrator there is currently no tool to visualise, nor is there a way to preview the access for a specific user or a resource (folder / secret). Whilst Okta is looking to address these as the product develops, I wrote a set of utilities based in Okta Workflows as a stopgap approach.
The Utilities (Reports)
This solution involves four utilities:
- A hierarchical (or tree) view of all folders and secrets, showing where policies and rules are attached.
- A user access view showing what folders and secrets a specific user can see.
- A secret search mechanism
- A resource access view showing who has access to a specific folder or secret
These are implemented as Delegated flows that appear in the Okta Admin Console.
They all produce reports via email.
Report 1 – Folder Hierarchy with Policy Rules
The first utility will produce a hierarchical (or tree) view of the folder/secret structure.
It also shows where policies/rules are specifically attached (secret policy rules are attached to folders and/or secrets).
Report 2 – Access for a User
The second utility takes a OPA user and performs a search across all folders and secrets to see where they have access, and what type of access.
It does allow for the policy inheritance model – where there is no policy rule specifically attached it will show inheritance from the next level up. It also shows the permissions from that rule and any conditions (MFA, Access Request).
This uses a temporary table in Workflows and this table is exported and sent in the email, so it can be reviewed in a spreadsheet tool like Excel.
Report 3 – Find a Secret
The third utility is a search utility. Given a string it will search through the secrets to find a match.
Note that this is somewhat redundant as Okta has released a secret search function that operates within the OPA UI and is much more usable.
Report 4 – Access to a Resource
The last utility will take a secret or folder name and produce a list of policy rules that apply, and thus the privileges, conditions and groups and users.
This makes it easy to see if the folder or secret has the access configuration you are expecting.
How It’s Built/Delivered
The solution is implemented in Okta Workflows, with tables used to build/store all the data needed for the reports, flows to load the tables and flows to leverage the data and produce reports.
Connectors
There are two connectors used: the Okta Privielged Access connector and a Google mail (GMail) connector.
Tables
The solution requires data pulled from OPA via multiple APIs and joined together. The tables are a poor mans implementation of a RDBMS with data tables and relationship tables. It stores users, groups, folders, secrets, policies and rules and some of the relations between them.
The most significant table (PolicyRulesAttach) shows the items (folders, secrets) with the policy rules attached and a breadcrumb showing the path to the item. Accessing the list sorting by breadcrumb is used to show the hierarchy.
There is also a temporary user access report table (tmp_UserAccessReport) used to show the folders and secrets a specific user can access.
LOAD*** Flows
There are a series of flows run to load the tables using APIs into OPA:
- LOAD1* – Get all secret folders and store in tables
- LOAD2* – Get all secrets and store in tables
- LOAD3* – Get all secret policies and store in tables
- LOAD4* – Build policy to folder mapping, including pulling the secrets and folders into the table shown above
- LOAD6* – Get all policy principals, i.e. the groups attached to policies and the users in those groups
These are run prior to running any reports (LOAD10, LOAD20, LOAD30, LOAD40, then LOAD60).
REPT*** Flows
The report flows generate the four different reports. They are run as Delegated Flows from the Okta Admin Console (and thus subject to the Okta Admin model).
- REPT1* – Produce a folder hierarchy with attached policies. This is passed the recipient email in the delegated flow, and then produces an email report with the hierarchy of folders and secrets (with indentation) and the policies attached.
- REPT2* – Produce a user access report. This is passed an OPA username (such as wendy.winadmin) and the report recipient. It will identify the users groups, the policies the groups are attached to, the rules in those policies and the resources (folders, secrets) those rules are attached to. The results are written to a table and that table sent via an email attachment.
- REPT3* – Product a report of secrets matching a string. This is passed a search string and a recipient email, and it searches through all secrets to find a match anywhere in the secret name. The results are emailed.
- REPT4* – Produce a resource access report. Given a resource (folder or secret) name, find all the policies and rules than apply, including the permissions, conditions and uses/groups for that policy rule. The results are emailed.
There is no dependency between these. Any of the reports can be run as needed (as long as the data has been loaded into the tables by the LOAD** flows).
UTIL*** Flows
Finally there are a set of utility flows used by multiple other flows to perform mundane functions like building the policy rule name string.
This concludes all of the components in the solution.
Conclusion
As use of Secrets within Okta Privileged Access becomes more widespread and the folder structures become bigger and more complex, additional capabilities are needed to view and manage the folders, secrets, policies and rules, and users. This article has presented a set of utilities implemented in Okta Workflows that can help manage complex Secrets deployments.
The Workflows package can be downloaded from below. To see more information on installation, click on the link then download.
