Key Value Secret Engine

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

StrongDM Vault has a secret engine that can be used for any type of secret or credential that does not already have a bespoke secret engine. This can include credentials you would like to use to access resources through StrongDM that don't have secret engines yet. It can also include secrets that you don't need to use for resource access, but instead wish to entitle to users for them to be able to manually retrieve the credential and do something with it, such as give themselves temporary Windows admin access.

This secret engine manages secrets within a secret store, but does no automatic rotation and no tandem updates with a target resource.

If you do not already have a secret store (StrongDM Vault or a supported cloud secret store provider) configured with StrongDM, configure one first by following one of the guides in the Secret Stores section.

Prerequisites

To set up the secret engine, the following general requirements must be met:

• Have the Admin permission level in StrongDM.

• Have at least one secret store (either StrongDM Vault or one of the supported cloud providers) configured and available to StrongDM.

Create a Secret Engine

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

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

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

3. On the dialog that displays, select Key-Value. Then set the following properties and click Save:

Secret Engine Properties

Property	Requirement	Description
Name	Required	Descriptive name that clearly indicates what the engine is for
Secret Store	Required	Secret store where the secrets you wish to manage are located
Secret Store Root Path	Required	Path to the secret store where the secrets are located (for example, /secret/data/ad)
Select node(s)	Required	Node(s) (gateways, relays, or 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

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

CLI Configuration of the Secret Engine

1. Get the ID of an available secret store to be used for storing secrets:

   $ sdm admin secretengines list-available-stores
   ID                      Name         Type           Tags
   se-0e599e2866db23fa     example 1    gcp            
   se-102c276965b83ad9     example 2    vaultToken     
   se-3ad72ac6620e8038     example 3    vaultToken

2. Create the secret engine:

   sdm admin secretengines create key_value
   --name keyvalue-example
   --secret-store-id se-1ab23ac6620e8038
   --secret-store-root-path="/secret/data/keyvalue"

3. Configure the node (gateway or relay) to be used to contact the secret store. 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__keyvalue-example=true

4. Define a managed secret that will manage the passwords for a user:

   $ sdm admin managedsecrets create key_value alice username=alice password=pass1
   ID                   ms-2de34ab567c8b910
   Secret Engine ID     eng-3b4b567891c23dd4
   Name                 alice
   Last Rotated At      <nil>
   Policy               password.allowrepeat=false,password.excludeuppercase=false,password.length=0,password.numsymbols=0,password.numdigits=0
   Tags                

5. Retrieve the password for the created user, which is shown in the Secret Value that is returned:

   $ sdm admin managedsecrets show key_value alice
   ID                    ms-2de34ab567c8b910
   Secret Engine ID      eng-3b4b567891c23dd4
   Name                  alice
   Last Rotated At       <nil>
   Policy                password.allowrepeat=false,password.excludeuppercase=false,password.length=0,password.numsymbols=0,password.numdigits=0
   Secret Store Path    
   Secret Value          password=pass1,username=alice
   Tags                  

6. Make changes to the managed secret:

   $ sdm admin managedsecrets update key_value alice [email protected]
   ID                   ms-2de34ab567c8b910
   Secret Engine ID     eng-3b4b567891c23dd4
   Name                 alice
   Last Rotated At      <nil>
   Policy               password.numsymbols=0,password.numdigits=0,password.allowrepeat=false,password.excludeuppercase=false,password.length=0
   Tags                

7. View details about the managed secret to confirm the changes were made:

   $ sdm admin managedsecrets show key_value alice                        
   ID                    ms-2de34ab567c8b910
   Secret Engine ID      eng-3b4b567891c23dd4
   Name                  alice
   Last Rotated At       <nil>
   Policy                password.length=0,password.numsymbols=0,password.numdigits=0,password.allowrepeat=false,password.excludeuppercase=false
   Secret Store Path    
   Secret Value          username=alice,[email protected],password=pass1
   Tags        

8. List all managed secrets for the secret engine:

   $ sdm admin managedsecrets list key_value                              
   ID                      Secret Engine ID         Name    Last Rotated At     Tags
   ms-01b0524966c590c6     eng-3b4b567891c23dd4     alice   <nil>              

9. Delete the managed secret:

   $ sdm admin managedsecrets delete key_value alice
   Deleted managed secret: ms-2de34ab567c8b910

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

Manage Secrets

Create a managed secret

Next, create a secret using the secret engine. This will allow the secret engine to begin rotating the password for the selected username and also begin storing it in your secret store, so that it can be used for proxying connections to the resource.

1. Go to the Admin UI under Settings > Secrets Management. Then select the Secrets tab, and select Add Secret.

2. Fill in a Name and Description for the secret.

It may be reasonable to correlate this name with the username or with the resource name that you intend to use this credential to access, if it is going to be used for leased credential access to the database. If it is being used for a specific identity using Identity Aliases, it could be named after the specific identity it is mapped to.

1. For Select secret engine, select the engine you just created.

2. Fill in the rest of the form, including resource specific fields and rotation or password complexity information for this secret if you desire it to be different than the defaults for this secret engine, and select Save.

Configure a resource to use this secret

Lastly, configure a resource to use this secret to authenticate to a resource.

Fill in the resource configuration as you normally would, but for Secret Store, select the secret store, and for the user credential fields, fill them in with /<SECRET_ENGINE_PATH>/SECRET_PATH?key=<SECRET_KEY>, filling in the values for <SECRET_ENGINE_PATH> from your secret engine configuration, <SECRET_PATH> from your managed secret configuration, and <SECRET_KEY> from the name of the revelant key within this managed secret.

Now you should be able to grant access to this resource to a user through a role, if you have not done so already, or through Just-in-Time access with workflows, and attempt accessing it.

Further Reading

• For more about managing secrets, see the main StrongDM Vault section.

• For instructions on entitling users to access particular secrets, see the Entitle Secrets via Policy section.

• For details on managing secret engines with the CLI, see Secrets Management via CLI.