Secrets Management

This feature is part of the Enterprise plan. If it is not enabled for your organization, please contact StrongDM at the StrongDM Help Center.

Overview

You can manage secrets through StrongDM using secret engines. A secret engine has a backing secret store, and is used to manage secrets within that store, and in the case of most types of secret engines, simultaneously manage the credentials within the resource that the secret engine interacts with. For example, the Active Directory secret engine can be configured to interact with AD credentials and also to store those credentials in your selected secret store for StrongDM nodes to retrieve and use as they authenticate user traffic with resources.

When a secret engine is created in StrongDM, the ID of the secret store to be used and the secret store root path where the secret engine's configuration is stored are specified.

Managed secrets are kept in your supported secret store of choice, but they are considered "managed secrets" because you are using a StrongDM secret engine to manage add, view, and delete them. You can also facilitate the rotation of eligible secrets in secret engines (for secret engines types that are not the basic Key Value type), and set password complexity rules for secrets that are rotated. All managed secrets paths that are managed by the secret engine begin with the configured secret store root path.

Secrets Management Use Cases

The most common use cases for managing secrets through StrongDM are:

1. Automated Rotation for Secrets Used by StrongDM: StrongDM resource configurations can reference credentials stored in a StrongDM Vault or third-party secret store, and rotate those credentials at the source and in the secret store. This enables secretless access for end users while ensuring that backend credentials (e.g., AD, Postgres, MySQL, MSSQL) are automatically rotated on a schedule. This improves security without adding operational overhead.

2. Controlled Checkout of AD Credentials for Admin Workflows: Admins may need temporary access to privileged AD accounts for specific operational workflows. StrongDM’s AD Secrets Engine supports credential checkout with automatic rotation. Rotation can occur either on a schedule or immediately after the credential is returned, ensuring safe, auditable, and time-bound use.

3. Breakglass Credentials for Emergency or Maintenance Access: Highly privileged AD or database superadmin accounts that are required for break-glass or critical maintenance workflows can be stored in a secret store and checked out under audit. After use, StrongDM automatically rotates these credentials to restore a secure baseline.

4. Shared API Keys Without Rotation Requirements: Teams sometimes need to share API keys, local administrator passwords, or credentials for resources that StrongDM is not used to access. You can store, manage, and retrieve those using the Key Value Engine backed by a secret store. These secrets are not rotated, but StrongDM provides centralized access controls and audit logging for visibility and governance (and storage, if StrongDM Vault is used)."

Set Up a Secret Store

Secret stores function and support

A secret store is a vault or other external secret management service in which you can store and centrally manage credentials. StrongDM is secret store agnostic. You can store your secrets with any supported secret management service, and integrate it with StrongDM. Once this integration is set up, the node that reaches out to StrongDM for credentials is instead directed to authenticate itself to the secret store through the integration. Then it is able to fetch and use the credentials stored there for this resource.

StrongDM supports the following secret store types when managing secrets through StrongDM with secret engines:

• AWS Secrets Manager

• Azure Key Vault

• GCP Secret Manager

• HashiCorp Vault

• StrongDM Vault

Set up a secret store

If you haven't already done so, you should configure a secret store integration with StrongDM. This ensures that a secret store is already set up to contain secrets that can be managed. You may skip this step if you already have a secret store configured.

To add a secret store in the Admin UI, follow these steps.

1. Log in to the Admin UI and go to Settings > Secrets Management. The settings that display are organized into four tabs for setting up secret stores, secret engines, secrets, and certificate authorities.

2. Select the Secret Stores tab and click the add secret store button.

3. On the form that displays, set the properties for the specific secret store you wish to add. Your nodes will also need to be configured to access the secret store provider, unless that provider is StrongDM Vault. Please see the secret store documentation for requirements, properties, and configuration details for your specific secret store type.

The Secret Stores tab now displays the secret store that you just added.

Secret Engine types

StrongDM offers the following types of secret engines for secrets management:

• Active Directory (AD): Manages and can automatically rotate passwords for AD accounts within AD and the supported secret store of your choice

• Microsoft SQL (MSSQL): Manages and can automatically rotate passwords for user accounts within MSSQL and the supported secret store of your choice

• MySQL: Manages and can automatically rotate passwords for user accounts within MySQL and the supported secret store of your choice

• PostgreSQL: Manages and can automatically rotate passwords for user accounts within Postgres and the supported secret store of your choice

• Key Value: Stores secrets within the supported secret store of your choice without automatic rotation directly on a resource

Note that all secret engine types require a backing secret store to contain the secrets they are managing.

Manage Secret Engines with the StrongDM Admin UI

This section provides instructions on how to set up Secrets Management in the StrongDM Admin UI. The process generally involves configuring secret store integration, creating a secret engine to facilitate the management of the managed secrets in the secret store, adding managed secrets, and optionally entitling users to the managed secrets via policy. When setup is complete, eligible users can view managed secrets in the Admin UI or from the CLI.

If you wish to use the CLI instead of the Admin UI, please see the Secrets Management in the CLI section of this guide.

If you wish to manage the secrets for a particular resource type that has a bespoke secret engine, choose that one to configure below. Otherwise, you can use a key-value engine.

Choose the tab for the type of secret engine you are setting up and follow the configuration instructions.

Active Directory

Prerequisites for use of the Active Directory secret engine

The AD connection is set up within either the StrongDM Admin UI or the StrongDM CLI, and the process generally involves providing AD configuration information to connect to the on-premises AD and enabling secrets updates within AD. Connection to AD is orchestrated through StrongDM nodes. Once the connection is established, the secrets are rotated on AD.

For StrongDM, the following requirements must be met:

• You must be a StrongDM account administrator.

• At least one StrongDM gateway must have authorization for the necessary operations to succeed in both API operations and network traffic to the secret engine and/or vault.

For AD, the following requirements must be met:

• The user must have the privilege to change passwords for users in scope detailed in the Set up AD account privileges section.

• Authorization details must be provided during configuration.

• Open port 636 for TLS encrypted connections.

• Open port 389 for unencrypted connections.

Set up AD account privileges

StrongDM will authenticate using a user account in Active Directory that must be an granted adequate permissions to reset passwords for other accounts. In order to do that:

1. Go to Active Directory Users and Computers, right click on the organizational unit that contains the accounts (generally "Users"), and select Delegate Control.

2. Click Next, and when prompted for a User or Group, select the account that StrongDM will be using to rotate passwords.

3. In the next page of the wizard, choose Create a Custom Task to Delegate.

4. Select Only the following objects in the folder, then select User objects from the list.

5. Click on General > Property-Specific > Creation/Deletion of specific child objects and pick the following from the Permissions list:

   • Change Password

   • Reset Password

   • Read lockoutTime

   • Write lockoutTime

   • Read pwdLastSet

   • Write pwdLastSet

   • Read userAcccountControl

   • Write userAccountControl

6. Click Next, then Finish.

For HashiCorp Vault, the nodes (gateways or relays) that are going to access the secret store for storing managed secrets must have permissions to read/write/create/delete secrets with a path starting with the secret store root path.

Create a secret engine

To add a new secret engine in the Admin UI, follow these steps.

1. In the Admin UI and go to Settings > Secrets Management.

2. Select the Secret Engines tab and click Add secret engine.

3. On the dialog that displays, select Active Directory and then set the following properties, then click save.

Secret engine properties

These properties are required, other than Tags.

Property	Requirement	Description
Name	Required	Descriptive name that clearly indicates what the engine is for
Secret Store	Required	The secret store where the secrets you wish to manage are located
Secret Store Root Path	Required	The path to the secret store where the secrets are located, for example, /secret/data/ad
Select node(s)	Required	The node(s) (gateways, relays, proxy clusters) to be used to contact your secret store; does not have to be filled out to create the engine, but is required to function
Select or add tags	Optional	Tags for organizing and interacting with secret engines

Active Directory properties

The URL and Bind DN are required, with the rest being optional. Note that if the Bind password is provided, the existing password for this user will be updated to match the provided value. If a password is not provided, the secret store's password value will not be in sync with Active Directory until after the first rotation.

Property	Requirement	Description
URL	Required	Active Directory URL
Bind DN	Required	Bind Distinguished Name, or direct path to or reference to the user account used to access AD
Bind password	Optional	Password for the Bind DN
Credential rotation interval	Optional	Interval for automatic secret rotation, in days, hours, and minutes
Timeout after credential read	Optional	Timeout after credential read in days, hours, and minutes

Password generation properties

These properties are optional criteria and constraints on password generation for the rotation of passwords.

Property	Requirement	Description
Length	Optional	Length of passwords that are generated; defaults to 32
Number of Digits	Optional	Number of digits contained in passwords that are generated; defaults to 6
Number of symbols	Optional	Number of symbols contained in passwords that are generated; defaults to 0
Excluded characters	Optional	Characters that are excluded from passwords that are generated; defaults to \
Exclude uppercase	Optional	Exclude uppercase letters from passwords that are generated
Allow repeated passwords	Optional	Allow repeated passwords when generating new passwords

Advanced settings

These properties are advanced settings regarding the encryption of the connection to AD and other advanced details.

Property	Requirement
CA certificate	Optional
Start TLS	Optional
Insecure TLS	Optional
Disable timestamp validation	Optional
Request timeout	Optional
Connection timeout	Optional
Maximum backoff duration	Optional
Base DN	Optional
User Principal Domain	Optional

The Secret Engines tab now displays the secret engine that you just added.

CLI example for AD

The following example provides a general idea of how to use some of the sdm admin secretengines and sdm admin managedsecrets CLI commands to set up an AD secret engine to store secrets, entitle them to a user, have the user retrieve the secrets, and rotate the secrets in AD.

1. Create the secret engine:

   sdm admin secretengines create active_directory
   --binddn "cn=admin,dc=example,dc=com"
   --bindpass="Example"
   --secret-store-id se-1234a12345bcd123
   --name AD
   --secret-store-root-path="/secret/data/ad"

2. Configure the node (gateway or relay) to be used to contact Active Directory. Run the sdm admin nodes update command to update the relevant node with a tag in the form of eng__<SECRET_ENGINE_NAME>=true:

   sdm admin nodes update n-1b23000c4567a890 --tags eng__AD=true

3. Define a managed secret that will manage the passwords for the user. After running the following command, information about the new secret is returned.

   $ sdm admin managedsecrets create AD Bob user_dn='cn=Bob Belcher,ou=example,dc=example,dc=com'
   ID                   ms-1a234b5c67de8912
   Secret Engine ID     eng-12a3456b78cd9e1f
   Name                 Bob
   Last Rotated At      NEVER
   Next Rotation At     NEVER
   Policy               password.excludeuppercase=false,password.length=0,password.numsymbols=0,password.numdigits=0.password.allowrepeat=false
   Tags

4. Retrieve the password for the created user, which is shown in the Secret Value that is returned. To retrieve, rotate, or validate secrets, use the sdm managedsecrets command. The show subcommand shows the secret without sensitive values; the retrieve subcommand shows the sensitive data.

   sdm managedsecrets retrieve AD Bob

5. Now that you've created secrets and verified that they can be retrieved, you have the option to rotate the user's password:

    sdm managedsecrets rotate AD Bob

6. Optionally log in to the Admin UI and go to Access > Secrets to view, rotate, and/or validate the managed secret.

See the sdm admin managedsecrets and sdm managedsecrets command reference pages for details on these commands.

How to Schedule Automatic Password Rotation

For AD managed secrets, you may schedule automatic password rotation by setting a time-to-live (TTL) value for either the secret engine or the managed secret. The TTL is an amount of time in seconds, minutes, or hours (for example, 12h, 30m, 5s, or 6h30m) that determines the lifetime of the password.

A password is valid for the given amount of time set in the TTL, after which it is automatically rotated. If the TTL value is not set, the secret engine's TTL value is used for rotation. If neither are set or they are set to 0s (zero seconds), then there is no automatic password rotation, and rotation will need to be done manually using sdm managedsecrets rotate or on the Admin UI's Access > Secrets page.

In the following example, an AD secret engine is created with the TTL set to 12 hours:

sdm admin secretengines create active_directory
--binddn "cn=admin,dc=example,dc=com"
--bindpass="Example"
--secret-store-id se-1234a12345bcd123
--name exampleAD
--secret-store-root-path="/secret/data/ad"
--ttl="12h"

In the following example, an AD managed secret is created and the TTL is set to 12 hours:

sdm admin managedsecrets create exampleAD Bob
--user_dn="cn=Bob Belcher,ou=people,dc=example,dc=com"
--ttl="12h"

Maximum Backoff Duration

To ensure successful automatic secret rotations for AD managed secrets, you can set a specific maximum backoff duration value for automatic rotations. Maximum backoff duration is the maximum amount of time that the system will wait before attempting rotation before stopping. The default value is 24 hours.

If an automatic rotation attempt fails, the system will retry in increasing intervals until the maximum backoff duration is reached. After it is reached, the system will retry every maximum backoff duration. For example, if the maximum backoff duration is set to 12 hours and automatic rotation fails, the system might retry 1 minute later, retry 1 hour later after that, and then retry 12 hours later, which is the maximum backoff duration value. Every subsequent attempt will be made every 12 hours after the previous attempt until the rotation is successful.

Once a rotation succeeds, whether manual or automatic, the schedule resets, and the next rotation will follow the standard secret expiration timing.

You can adjust the maximum backoff duration by using the --max-backoff-duration option when creating or updating an AD secret engine.

In the following example, an AD secret engine is created with rotation set to occur every 12 hours (see the --ttl value) and the maximum backoff duration set to 10 minutes. If the scheduled rotation fails, the system will try again in increasing intervals until 10 minutes has been reached. After that, the system will attempt to rotate it every 10 minutes until it is successful.

sdm admin secretengines create active_directory
--binddn "cn=admin,dc=example,dc=com"
--bindpass="Example"
--secret-store-id se-1234a12345bcd123
--name exampleAD
--secret-store-root-path="/secret/data/ad" 
--ttl="12h"
--max-backoff-duration="10m"

Microsoft SQL

MySQL

PostgreSQL

Key Value

Managed Secrets

To add managed secrets in the Admin UI, follow these steps.

1. In the Admin UI and go to Settings > Secrets Management.

2. Select the Secrets tab and click Add Secrets.

3. On the dialog that displays, set the following properties:

   • Name: Enter a unique name for this secret. This name will display throughout StrongDM and help you to identify the managed secret.

   • Description: Optionally enter a description of the secret to help you to remember what it is for.

   • Select Secret Engine: Use the dropdown menu to select the secret engine to use to manage how and when users access secrets and facilitate the rotation of secrets.

   • Select or add tags: Optionally assign tags to the managed secret.

4. Click Save.

The Secrets tab now displays the secret that you just added, along with any other managed secrets that have been added via the Admin UI and CLI. You may now edit the secret's settings in order to schedule rotation and set a password complexity rules, view entitlements for the secret, and see any activities related to the secret.

Secrets settings

After you have created a managed secret, you can set password complexity requirements, such as the number of symbols required, for passwords that are generated, rotated, or updated, to suit the needs of your organization.

For AD managed secrets only (not Key Value), you may schedule automatic password rotation by setting the credential rotation interval. A secret is valid for the given amount of time set, after which it is automatically rotated. If no interval is set or it is set to the default zero seconds, then there is no automatic password rotation, and rotation will need to be done manually for the secret on the Secrets tab.

The Settings tab is where you can update the secret's properties, set your password policy, and schedule automatic rotation. To get to the settings in the Admin UI, go back to Settings > Secrets Management Secrets. Click on the name of a managed secret and then click on the Settings tab to view or edit the secret's details. Alternatively, you can click Actions > View.

The following properties are shown on the Settings tab.

Property	Requirement	Description	Example
Name	Read Only	Name of the managed secret	AD-dev-secret
Description	Optional	Description of the managed secret to help you to remember what it is for	AD dev environment
Select secret engine	Required	Name of the secret engine configured for this managed secret	Example Name
Select or add tags	Required	Tags consisting of key-value pairs <KEY>=<VALUE>	env=dev
User DN	Required	For AD managed secrets, the user DN	cn=Bob Belcher,ou=people,dc=example,dc=com
Password	Optional	Password of the managed secret	1234567890
Credential rotation interval	Required	Amount of time in days, hours, and minutes that the secret is valid before it is rotated	0 days, 12 hours, 0 minutes
Timeout after credential read	Required	Amount of time in days, hours, and minutes for the secret to be viewed before it expires	1 days, 0 hours, 0 minutes
Length	Optional	Password length; if not set, defaults to zero (0)	24
Number of Digits	Optional	Number of digits to use when generating the password; if not set, defaults to zero (0)	24
Number of Symbols	Optional	Number of symbols to use when generating the password; if not set, defaults to zero (0)	2
Exclude Characters	Optional	Enter any characters to exclude when generating the password	@
Exclude Uppercase	Optional	Select the checkbox to exclude uppercase letters when generating the password
Allow Repeat	Optional	Select the checkbox to allow consecutive characters to repeat

If you rename an existing managed secret, and then later attempt to create a new secret that reuses the old name, this will create an error. If the original secret is removed rather than renamed, then that original name becomes available again.

Secrets entitlements

From the Secrets tab, click on the name of a managed secret and then click on the Entitlements tab to view all the entitlements for the selected secret. Alternatively, you can click Actions > View. For managed secrets, entitlements are the specific actions (for example, retrieve, rotate, or validate) that the user or service account is allowed to perform on the given secret, as permitted by policy.

The Entitlements tab displays the following fields.

Property	Description	Example
Name	Name of the user; this field may be blank for service accounts	Glick, Alice
Type	Type of account (user or service account)	User
Actions	Actions that the user is permitted to take on the secret (retrieve, rotate, or validate)	Retrieve, Rotate, Validate
Granted By	Name of policy	example policy
Last Accessed	Timestamp of when the secret was last accessed; this field is empty if the secret has never been accessed	Jul 10, 2025 1:45 PM

To learn more about entitling secrets to principals, read the Policy-Based Secrets Entitlement section.

Secrets activity

From the Secrets tab, click on the name of a managed secret and then click on the Activity tab to view all activities for the selected secret. Alternatively, you can click Actions > View.

For managed secrets, activities are the actions that a user has taken on the managed secret (for example, viewing, rotating, or validating). Note that activities are different than entitlements, as activities are what the user has actually done versus what the user is permitted to do.

The Activity tab displays the following fields.

Property	Description	Example
Date	Timestamp for the activity	Jul 10, 2025 1:00 PM
Operation	Operation(s) performed on the secret	TTL_ROTATE
User	Name of the user, or "System" if for an automatic rotation	System

Logs for Secrets

Logs for secrets are recorded in the following areas within StrongDM:

• Activity logs: Secret engine and managed secrets activities such as the creation, update, deletion, or rotation of secrets.

• Secrets logs: All user activity related to secrets, such as retrieval of secrets by authorized users.

• Policy logs: Any secrets activity that matches an evaluated policy is captured in the policy logs

Interaction With Managed Secrets

StrongDM admins may view managed secrets from the Admin UI in Settings > Secrets Management > Secrets tab. The Secrets tab displays the following details for each secret:

Property	Description	Example
Name	Name the secret was given to it when created	TestUserCredentials
Path	The path of the secret store the secret is kept in appended with the name of the secret	test_ad/subdir/TestUserCredentials
Type	Type of secret; corresponds to the type of the secret engine used to manage the secret	Active Directory
Secret Engine	Name of the secret engine that was given to it when created	TestActiveDirectoryEngine
Tags	Tags given the secret by administrators	exampletag
Actions	Actions available for you to perform on this secret; view or delete	n/a

Secrets can be entitled to particular end users through policies and action control as well as being visible to admins who can manage secrets. See the Policy-Based Secrets Entitlement section for more details on how to entitle secrets to users, or see the Retrieve Secrets section for details on how to retrieve and interact with secrets as a user.

Secrets Management in the CLI

This section provides Secrets Management configuration steps and usage information for the StrongDM CLI. Administrators can use the StrongDM CLI to add, update, read, delete, and otherwise manage secret engines and managed secrets.

If you wish to use the Admin UI instead of the CLI, please see the Admin UI section of this guide.

Secret engine CLI commands

Manage secret engines in the CLI with sdm admin secretengines and its subcommands:

• sdm admin secretengines create Creates a new secret engine

• sdm admin secretengines list: Lists all secret engines in your organization

• sdm admin secretengines show: Shows details about a secret engine

• sdm admin secretengines list-available-stores: Lists the secret stores that can be used with the secret engines in your organization

• sdm admin secretengines healthcheck: Checks the health of secret engines on all nodes

• sdm admin secretengines rotate: Rotates a secret engine's credentials

• sdm admin secretengines update: Updates the secret engine

• sdm admin secretengines delete: Deletes a secret engine

sdm admin secretengines create

The sdm admin secretengines create command is used to add a new secret engine to your organization. You can create an AD (active_directory) secret engine or Key Value (key_value) secret engine.

To create an AD secret engine, run the sdm admin secretengines create active_directory command with all required options set, as in the following example.

sdm admin secretengines create active_directory
--binddn "cn=admin,dc=example,dc=com"
--bindpass="Example"
--secret-store-id se-1234a12345bcd123
--name exampleAD
--url ldaps://<HOSTNAME>:<PORT>
--secret-store-root-path="/secret/data/ad"

For the --secret-store-id option, the value should be the ID of an existing secret store. For --url, the URL should be in the format <HOSTNAME>:<PORT>, prepended by either ldap:// for an unencrypted connection or ldaps:// for a TLS encrypted connection.

To create a Key Value secret engine, run sdm admin secretengines create key_value with all required options set, as in the following example.

sdm admin secretengines create key_value
--secret-store-id se-1234a12345bcd125
--name exampleKeyValue
--secret-store-root-path="/secret/data/keyvalue"

After secret engine creation, configure the node (gateway or relay) to be used to contact the secret store or Active Directory. To do this, run the following command to update the relevant node and set a tag in the form of eng__<SECRET_ENGINE_NAME>=true:

sdm admin nodes update <NODE_ID> --tags eng__<SECRET_ENGINE_NAME>=true

Example:

sdm admin nodes update n-1b23000c4567a890 --tags eng__exampleKeyValue=true

This tag should be added to all nodes that have been configured to access both the secret store and the external secrets system.

See the CLI Reference for a copy of the help text available for sdm admin secretengines create.

sdm admin secretengines list

Use the following command to list all existing secret engines in your organization.

sdm admin secretengines list

If any secret engines are already created, the returned output looks similar to the following.

ID                      Name        Type                Tags    Secret Store            Secret Store Root Path
eng-12a3456b78cd9e1f    AD          active_directory            se-1234a12345bcd123     /secret/data/ad
eng-22a3456b78cd9e1h    Key Value   key_value                   se-1234a12345bcd125     /secret/data/keyvalue

See the CLI Reference for a copy of the help text available for sdm admin secretengines list.

sdm admin secretengines show

Use sdm admin secretengines show to show details about a specific secret engine. You must specify the secret engine ID, as in the following example.

sdm admin secretengines show eng-12a3456b78cd9e1f

See the CLI Reference for a copy of the help text available for sdm admin secretengines show.

sdm admin secretengines list-available-stores

Use sdm admin secretengines list-available-stores to list the secret stores that can be used with the secret engines in your organization.

Example:

$ sdm admin secretengines list-available-stores   
ID                      Name                  Type           Tags
se-0e111e2222db33fa     secretStore1        gcp            
se-111c222222b33ad4     vaultExample         vaultToken     
se-1ad22ac3333e4444     vaultExample2       vaultToken 

See the CLI Reference for a copy of the help text available for sdm admin secretengines list-available-stores.

sdm admin secretengines healthcheck

Use sdm admin secretengines healthcheck <SECRET_ENGINE_ID> to check the health of a secret engine on nodes.

Example:

$ sdm admin secretengines healthcheck eng-12abc45678d9f1g0
nodeID                 status
n-123123ab123123c1     OK

See the CLI Reference for a copy of the help text available for sdm admin secretengines healthcheck.

sdm admin secretengines rotate

Use sdm admin secretengines rotate <SECRET_ENGINE_ID> to rotate a secret engine's secrets.

Example:

sdm admin secretengines rotate eng-12abc45678d9f1g0

See the CLI Reference for a copy of the help text available for sdm admin secretengines rotate.

sdm admin secretengines update

Use sdm admin secretengines update to make changes to a specific secret engine. You must specify the secret engine type (active_directory or key_value), and set the options that you wish you change, as in the following example.

sdm admin secretengines update active_directory --name New AD Name

See the CLI Reference for a copy of the help text available for sdm admin secretengines update.

sdm admin secretengines delete

Use sdm admin secretengines delete to delete a secret engine. You must specify the secret engine ID, as in the following example.

sdm admin secretengines delete eng-12a3456b78cd9e1f

See the CLI Reference for a copy of the help text available for sdm admin secretengines delete.

Managed secrets CLI commands

You can work with managed secrets in the CLI with sdm admin managedsecrets and its subcommands:

• sdm admin managedsecrets create: creates a new managed secret.

• sdm admin managedsecrets list: lists all managed secrets in the secret engine.

• sdm admin managedsecrets show: shows details of managed secrets without sensitive data.

• sdm admin managedsecrets update: updates a managed secret.

• sdm admin managedsecrets delete: deletes a managed secret.

• sdm admin managedsecrets logs: displays logs for managed secrets.

As well as with the sdm managedsecrets commands:

• sdm managedsecrets list: list all managed secrets you have access to

• sdm managedsecrets show: shows details of a managed secret without sensitive data.

• sdm managedsecrets retrieve/read: shows details of a manage secrets with sensitive data.

• sdm managedsecrets rotate: rotates a managed secret.

• sdm managedsecrets validate: shows whether a managed secret is currently valid.

sdm admin managedsecrets create

Use sdm admin managedsecrets create to add secrets for a user for a specific secret engine. When running this command, you must, at minimum, specify the secret engine name and the desired name for the secrets you're adding.

For Key Value, run the following:

sdm admin managedsecrets create <SECRET_ENGINE_NAME> <MANAGED_SECRET_NAME>

Example:

sdm admin managedsecrets create key_value alice

For Active Directory, you also must set the user_dn, which is the distinguished name of the account that is managed.

In the following example, secrets are created for user Bob for an AD secret engine.

$ sdm admin managedsecrets create exampleAD Bob user_dn="cn=Bob Belcher,ou=people,dc=example,dc=com"
ID                   ms-1a234b5c67de8912
Secret Engine ID     eng-12a3456b78cd9e1f
Name                 Bob
Last Rotated At      NEVER
Next Rotation At     NEVER
Policy               password.excludeuppercase=false,password.length=0,password.numsymbols=0,password.numdigits=0.password.allowrepeat=false
Tags

See the CLI Reference for a copy of the help text available for sdm admin managedsecrets create.

sdm admin managedsecrets list

Use the following command to list all existing managed secrets in your organization. You must specify the name of the secret engine being used.

sdm admin managedsecrets list <SECRET_ENGINE_NAME>

If any managed secrets are already present, the returned output looks similar to the following.

ID                      Secret Engine ID         Name           Last Rotated At     Next Rotation At     Tags
ms-1111f22b33e4fb55     eng-1234aa5678e9faab     exampleAD     NEVER               NEVER                employeeNumber=12345

See the CLI Reference for a copy of the help text available for sdm admin managedsecrets list.

sdm admin managedsecrets show

Use this command to get information about a specific managed secret and the associated secret engine. The returned details include the secret engine ID, when the secrets were last rotated (if ever), when their next rotation is scheduled to occur (if at all), information about the password complexity policy, and any tags associated with the secrets. When running this command, you must specify the name of the secret engine and the name of the managed secret.

sdm admin managedsecrets show <SECRET_ENGINE_NAME> <MANAGED_SECRET_NAME>

Example:

$ sdm admin managedsecrets show exampleAD exampleManagedSecret
ID                   ms-1111f22b33e4fb55
Secret Engine ID     eng-1234aa5678e9faab
Name                 exampleManagedSecret
Last Rotated At      NEVER
Next Rotation At     NEVER
Policy               PasswordPolicy: Length: 0, Digits: 0, Symbols: 0, AllowRepeat: false, ExcludedCharacters: "", ExcludeUpperCase: false
Tags                 employeeNumber=12345

See the CLI Reference for a copy of the help text available for sdm admin managedsecrets show.

sdm admin managedsecrets update

Use sdm admin managedsecrets update to make changes to existing secrets for a specific secret engine. When running the command, specify the name of the secret engine, the name of the managed secret, and the new values of the options that you want to update.

sdm admin managedsecrets update <SECRET_ENGINE_NAME> <MANAGED_SECRET_NAME>
--name value
--password-length value
--password-num-digits value
--password-num-symbols value
--password-allow-repeat bool 
--password-exclude-characters value
--password-exclude-uppercase bool
--delete-password-policy bool
--password value
--user-dn value
--ttl value
--after-read-ttl value

Example:

sdm admin managedsecrets update exampleAD Bob
--name new-secrets-name
--password-length 50
--password-num-digits 50
--password-num-symbols 2

See the CLI Reference for a copy of the help text available for sdm admin managedsecrets update.

sdm admin managedsecrets delete

Use sdm admin managedsecrets delete to delete secrets. When running the command, specify the name of the secret engine and the name of the managed secret.

sdm admin managedsecrets delete <SECRET_ENGINE_NAME> <MANAGED_SECRET_NAME>

Example:

sdm admin managedsecrets delete exampleAD Bob

See the CLI Reference for a copy of the help text available for sdm admin managedsecrets delete.

sdm admin managedsecrets logs

Use sdm admin managedsecrets logs to get information about managed secrets, including the date and time when the secrets were created, the ID of the secret engine they were created for, the account ID of the user using them, and the last action taken.

Example:

$ sdm admin managedsecrets logs
ID                   Created At                               Managed Secret ID       Secret Engine ID         Account ID             Action       Debug
77ac90f066fa7d79     2024-09-30 10:29:13.485862 +0000 UTC     ms-1111f22b33e4fb55     eng-1234aa5678e9faab     a-123a4567890af1c2     validate 

See the CLI Reference for a copy of the help text available for sdm admin managedsecrets logs.

sdm managedsecrets list

Secrets available to the currently logged in principal are able to be listed with sdm managedsecrets list.

$ sdm managedsecrets list

See the CLI Reference for a copy of the help text available for sdm managedsecrets list

sdm managedsecrets show

Use sdm managedsecrets show to show details about a specific secret without showing the sensitive data associated with it, such as password values.

sdm managedsecrets show <SECRET_ENGINE_NAME> <MANAGED_SECRET_NAME>

See the CLI Reference for a copy of the help text available for sdm managedsecrets show.

sdm managedsecrets retrieve

Use sdm managedsecrets retrieve to show details about a specific secret that include the sensitive data associated with it, such as password values.

sdm managedsecrets retrieve <SECRET_ENGINE_NAME> <MANAGED_SECRET_NAME>

See the CLI Reference for a copy of the help text available for sdm managedsecrets retrieve.

Managed secrets also may be retrieved in the Admin UI's Access > Secrets page.

sdm managedsecrets rotate

Secrets created with a secret engine that allows rotation are able to be rotated with sdm managedsecrets rotate. For example, to rotate user Bob's password, run the following command with the name of the secret engine and the name of the managed secret:

$ sdm managedsecrets rotate exampleAD Bob
Rotated managed secret: ms-1a234b5c67de8912

See the CLI Reference for a copy of the help text available for sdm managedsecrets rotate

Managed secrets also may be rotated in the Admin UI's Access > Secrets page.

sdm managedsecrets validate

Use sdm managedsecrets validate to show whether a managed secret is currently valid. When running the command, specify the name of the secret engine and the name of the managed secret.

sdm managedsecrets validate <SECRET_ENGINE_NAME> <MANAGED_SECRET_NAME>

Example:

sdm managedsecrets validate exampleAD Bob

See the CLI Reference for a copy of the help text available for sdm managedsecrets validate.

Managed secrets also may be validated in the Admin UI's Access > Secrets page.

Configure password complexity requirements in the CLI

When a managed secret is created, you have the option to set password complexity requirements, such as the number of symbols required, for passwords that are generated, rotated, or updated, to suit the needs of your organization. The available options for passwords are:

• --password-length: Password length (default: 0)

• --password-num-digits: Number of digits to use when generating the password (default: 0)

• --password-num-symbols: Number of symbols to use when generating the password (default: 0)

• --password-allow-repeat: If set to true, allows for consecutive characters to repeat

• --password-exclude-characters: Set of characters to exclude when generating password

Password complexity requirements may be set as options with the following CLI commands:

• sdm admin managedsecrets create

• sdm admin managedsecrets update

In the following example, the AD managed secret is updated to require generated passwords to be 24 digits long, have 2 symbols, exclude # characters, and not repeat themselves or exclude uppercase letters.

sdm admin managedsecrets update exampleAD Bob
--password-length="24"
--password-num-digits="24"
--password-num-symbols="2"
--password-allow-repeat=false
--password-exclude-characters="#"
--password-exclude-uppercase=false