This article is to help to rotate static credentials managed by the Okta Privileged Access vault by sending a reminder to the security team if the secret is vaulted and has not been rotated for more than 30 days (configurable). The Security team can take action and rotate the secrets. This solution is provided as a guide and it can be further enhanced or extended.
The given example is built using Okta Workflows and an event captured in the Okta system log.
Use Case Overview
Generic/shared secrets are stored in the Okta Privileged Access vault which will be encrypted and restricted for access/reveal. Those credentials are static in nature – there is no automated rotation/provisioning mechanism built in for generic secrets. They cannot be revealed/updated/deleted until policy authorizes end users to perform those respective operations. Each action against these credentials generates an event in the Okta system log.
For example, Secret creation/ modification/ deletion generates events as “pam.secret.create” or “pam.secret.update” or “pam.secret.delete” in the Okta system log respectively.
This solution will help with rotation of the static secrets stored in a vault by prompting an administrator to manually refresh the credentials and update the secret on certain intervals to reduce the risk.
We will leverage Okta Workflows for the solution that will have 2 workflows.
- First workflow is designed to periodically check for all matching System Log events since the last check and process them together and store the metadata of the secrets and the duration since last update/create in a workflow table. This is more efficient than triggering a flow for each event for a newly discovered event.
- Second workflow is designed to periodically check the workflow table identifying secrets due for rotation and sending reminders.
Example Workflows
Workflows Prerequisites (Tables)
Prerequisite:
Create 2 tables, one to capture the last execution timestamp and one to store the secret metadata.
- This table will always have a single row with the last execution timestamp (column called LastExecutionTimestamp).
Table Name: LastExecutionDetails
| Column Name | Field Type |
| LastExecutionTimestamp | Date |
- This table will store the secret metadata with some additional data to send reminders
Table Name: SecretMetadata
| Column Name | Field Type |
| Created By | Text |
| Date Created | Date |
| Last modified by | Text |
| Last modified | Date |
| Notification Status | Text |
| SecretName | Text |
| ProjectId | Text |
| ResourceGroupId | Text |
| SecretId | Text |
| ProjectName | Text |
| ResourceGroupName | Text |
| Event Type | Text |
| Secret Path | Text |
One Table split in multi parts for better visibility, the three screenshots represent different columns for the same row.:
Part – A
Part – B
Part – C
Workflows Part 1 – Capture Secret Details in a Table
I used a standard pattern for the flows:
PART 1: Capture Secret details in a table
We created a scheduler workflow to keep checking for either of these 3 event types from Okta syslog. “pam.secret.create” or “pam.secret.update” or “pam.secret.delete”.
Steps involved with the flow:
- Read the last execution timestamps from the table. If there is no entry in the table or flow never executed, it will create a row in the table, else it will update the table with the current execution timestamp as the last execution timestamp.
- To make it zone neutral, convert the all timestamp to ISO format.
- Search the syslog for “pam.secret.create”, “pam.secret.update” and “pam.secret.delete” events between the current timestamp and last execution timestamp.
- Capture the details of the secret, including the metadata
- Calculate the life of the secret since last rotation
- Depending on whether it was a create, update or delete event: insert a new row for the new secret in the SecretMetadata table; update the existing secret row with last modified timestamp; or delete the entry from the table.
Part 1 – Main Flow
This flow is scheduled to execute at a certain interval and scan the Okta syslog to monitor and capture the details if these 3 event types occur.
- pam.secret.create
- pam.secret.update
- pam.secret.delete
Workflow chart of the main flow:
Part A1:(row does not exist): If scheduler runs for the first time then it creates an entry into the LastExecutionDetails table with first execution timestamp.
PART A2: (row already exists option): For any subsequent runs of the scheduler entry into the LastExecutionDetails table get updated with last scheduler execution timestamp.
Part B: This part of the flow searches for the recent “pam.secret.create”, “pam.secret.update” and “pam.secret.delete” events in okta syslog.
Helper Flow 1.1 to Get System Log Events
We created a few helper flows to get all secrets created/updated from syslog and store into a table or delete the entry from the workflow table if a delete event was found. This flow is called by the For Each cards in the Part B flow shown above, and will run for each create/update/delete event found in the system log.
Workflow Cards (Helper Flow – 1): This flow is to call other flows based on the event type.
Workflow Chart of helper flow – 1
Part A: This part of the helper flow to make a call to other helper flow based on the event type captured from Okta syslog.
Part B: This part is to display If and Else If conditions from previous screenshot
PART C1 (inside If condition): This part of the flow executed when the “pam.secret.create” event was captured and called another helper flow to create an entry into the SecretMetadata table.
PART C2 (inside Else If condition): This part of the flow executed when the “pam.secret.update” event was captured and called another helper flow to update the existing entry into the SecretMetadata table.
PART C3 (inside Else If condition): This part of the flow executed when the “pam.secret.delete” event was captured and called another helper flow to delete the existing entry from the SecretMetadata table. This will help from sending a false notification for an already deleted secret from Okta Privileged Access Vault.
Helper Flow 1.2 to Create SecretMetadata Entry
This helper flow is to help create an entry into SecretMetadata table for each entry found for event “pam.secret.create” and send a message to the team with details of the event.
Workflow Chart of helper flow – 2
Workflow Cards (Helper Flow -2):
Helper Flow 1.3 to Update SecretMetadata Entry
This helper flow is to help update an existing entry into the SecretMetadata table for each entry found for the “pam.secret.update” event and send a message to the team with details of the event.
Workflow Chart of helper flow – 3
Workflow Cards (Helper Flow -3):
Helper Flow 1.4 to Delete SecretMetadata Entry
This helper flow is to help delete an entry from the SecretMetadata table for each entry found for “pam.secret.delete” event when the actual entry has been deleted from the vault.
Workflow Chart of helper flow – 4
Workflow Cards (Helper Flow – 4)
Helper Flow 1.5 to Send an Email
We created a helper flow to send a notification. This flow loops for each secrets created/updated
Workflow chart of helper flow to send notifications.
Workflow Cards (Helper Flow -5)
Sample Email Notifications
New Secret Creation Activity:
Existing Secret Update Activity:
Secret Deletion Activity:
Workflows Part 2 – Send Reminders to Rotate Secrets
We created a scheduler workflow to keep scanning workflow table for secrets due for rotation.
Steps involved with the flow:
- Search table to find out the secret which last modified timestamp is more than or equal to 30 days (you can change this by editing the Where Expression shown in the following screenshot). These are the secrets due for rotation.
- For each secret due for rotation send a reminder
Part 2 – Main Flow
Workflow Chart of Main Flow:
Workflow Cards (Main Flow) : This flow scans the table and executes for each secret found 30 days older or more.
We created a helper flow to compose message with details to send reminder
Helper Flow 2.1 to Compose Email Message
Workflow Chart of helper Flow:
Workflow Cards (Helper Flow – 1):
We created a helper flow to send a notification. This flow loops for each secrets created/updated.
Helper Flow 2.2 to Send an Email
Workflow chart of helper flow to send notifications.
Workflow Cards (Helper Flow -2): Sends email
Sample Email Notifications
Sample email notification:
