Credential Management

Last modified on February 5, 2025

Overview

This guide provides a general overview of StrongDM’s credential management feature, which allows StrongDM administrators to manage access to secrets and facilitate the rotation of the managed secrets stored in the secret store of your organization’s choice.

This guide describes how to set up credential management using the StrongDM CLI, provides example setup steps for each supported secret engine, covers how to validate and/or rotate managed secrets in the StrongDM Admin UI, and provides policy examples on how to entitle credentials to users or groups of users and set up fine-grained action control for managed secrets.

Secret Engines and Managed Secrets

Secrets such as username/password credentials or other “secret” data are stored in your organization’s user-provided secret stores. The currently supported secret store types are AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, and HashiCorp Vault. Secret stores need to be configured to connect to StrongDM and enable StrongDM to manage user access and rotation of the stored secrets. Configuration involves creating a secret engine in StrongDM.

A secret engine is what connects StrongDM to the secret store. 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 will be stored are specified. For HashiCorp Vault, the secret store root path is a path inside a HashiCorp Vault KV engine.

Your secrets are still kept in the secret store, but they are “managed secrets” because you are using the StrongDM secret engine to manage how and when users access secrets, facilitate the rotation of eligible secrets, and set password complexity rules for secrets that are rotated and updated. All managed secrets paths that are managed by the secret engine begin with the configured secret store root path.

Supported Secret Engines

At this time, StrongDM supports the following types of secret engines for credential management: Active Directory (AD) and Key Value (KV).

The AD secret engine allows you to manage credentials and also rotate them in Active Directory. Use the AD secret engine if you want to manage passwords for accounts in Active Directory. This secret engine supports automatic password rotation.

The KV secret engine allows you to store and access (but not rotate) any secrets in the backing secret store. Use the KV secret engine if you want to store any other data to which you want to limit access.

Note that all secret engine types require a backing secret store.

CLI Command Information and Usage

Secret engines and managed secrets can be added, updated, read, deleted, and otherwise managed via the StrongDM CLI.

sdm admin secretengines

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

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 KV (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 example-ad
--secret-store-root-path="/secret/data/ad"

To create a KV 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 example-kv
--secret-store-root-path="/secret/data/kv"

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__example-kv=true

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    kv      key_value                   se-1234a12345bcd125     /secret/data/kv

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     secret-store-1        gcp            
se-111c222222b33ad4     vault-example         vaultToken     
se-1ad22ac3333e4444     vault-example-2       vaultToken

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

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.

sdm admin managedsecrets

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

sdm admin managedsecrets create

Use sdm admin managedsecrets create to add credentials 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 credentials you’re adding.

For KV, run the following:

sdm admin managedsecrets create <SECRET_ENGINE_NAME> <MANAGED_SECRET_NAME>

Example:

sdm admin managedsecrets create kv 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, credentials are created for user Bob for an AD secret engine.

$ sdm admin managedsecrets create example-ad 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     example-ad     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 credentials 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 credentials. 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 example-ad example-managed-secret
ID                   ms-1111f22b33e4fb55
Secret Engine ID     eng-1234aa5678e9faab
Name                 example-managed-secret
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 rotate

Credentials created for AD (active_directory) secret engines are able to be rotated with sdm admin 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 admin managedsecrets rotate example-ad Bob
Rotated managed secret: ms-1a234b5c67de8912

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

Managed secrets also may be validated in the Admin UI’s Credentials page.

sdm admin managedsecrets validate

Use sdm admin 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 admin managedsecrets validate <SECRET_ENGINE_NAME> <MANAGED_SECRET_NAME>

Example:

sdm admin managedsecrets validate example-ad Bob

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

Managed secrets also may be validated in the Admin UI’s Credentials page.

sdm admin managedsecrets update

Use sdm admin managedsecrets update to make changes to existing credentials 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 example-ad 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 credentials. 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 example-ad 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.

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 admin managedsecrets rotate or on the Admin UI’s Credentials 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 example-ad
--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 example-ad Bob
--user_dn="cn=Bob Belcher,ou=people,dc=example,dc=com"
--ttl="12h"

How to Set Password Complexity Requirements

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:

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 example-ad Bob
--password-length="24"
--password-num-digits="24"
--password-num-symbols="2"
--password-allow-repeat=false
--password-exclude-characters="#"
--password-exclude-uppercase=false

Credential Management in the Admin UI

After managed secrets are created in the CLI, they are shown in the Admin UI in Access > Credentials. On the Credentials page, you may view information for each managed secret, including the username, type (AD or KV), secret engine name, and tags. In addition, there is the option to rotate (if eligible), validate, and read (if eligible) each managed secret directly from that page of the Admin UI, instead of using the CLI.

If the managed secret is eligible for rotation, you may rotate it from the Admin UI by selecting the Rotate option within Actions. You may also validate a managed secret from the Admin UI by selecting the Validate option within Actions. You can read (that is, reveal) a stored secret if you are eligible to do so; if ineligible, there is no option to read it.

AD Credential Management Setup

Your organization can use StrongDM to facilitate the rotation of credentials for Active Directory (AD) accounts managed within StrongDM. The AD connection is set up within the StrongDM CLI, and the process generally involves providing AD configuration information to connect to the on-premises AD and enabling credential updates within AD. Connection to AD is orchestrated through StrongDM nodes. Once the connection is established, the credentials are rotated on AD. This section provides information about the requirements for AD credential management and provides an example of how to use the CLI commands to manage AD secret engines and managed secrets.

Prerequisites

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.
  • Authorization details must be provided during configuration.
  • Open port 636 for TLS encrypted connections.
  • Open port 389 for unencrypted connections.

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.

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 credentials, entitle them to a user, have the user retrieve the credentials, and rotate the credentials 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.
    $ sdm admin managedsecrets show AD Bob
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
Secret Store Path    /secret/data/ad/bob
Secret Value         map[expires_at:2024-08-28T15:00:00.12345Z last_rotated_at:2024-08-28T14:17.22.26234Z password:fdlsfjkdsjflksdjflskdjgdkl,user_dn:cn=Bob Belcher,ou=example,dc=example,dc=com]
Tags
  5. Now that you’ve created credentials and verified that they can be retrieved, you have the option to rotate the user’s password:
    $ sdm admin managedsecrets rotate AD Bob
Rotated managed secret: ms-1a234b5c67de8912
  6. Retrieve the new password to confirm that the rotation was successful. Notice that the Secret Value is different and there is now a date and time for the last rotation.
    $ sdm admin managedsecrets show AD Bob
ID                   ms-1a234b5c67de8912
Secret Engine ID     eng-12a3456b78cd9e1f
Name                 Bob
Last Rotated At      2024-08-28T14:17.30.00000Z
Next Rotation At     NEVER
Policy               password.excludeuppercase=false,password.length=0,password.numsymbols=0,password.numdigits=0.password.allowrepeat=false
Secret Store Path    /secret/data/ad/bob
Secret Value         map[expires_at:2024-08-28T16:00:00.12345Z last_rotated_at:2024-08-28T14:17.30.00000Z password:abcabcabcabcabcabcabcabcab,user_dn:cn=Bob Belcher,ou=example,dc=example,dc=com]
Tags
  7. Optionally log in to the Admin UI and go to Access > Credentials to view, rotate, and/or validate the managed secret.

KV Credential Management Setup

Your organization can use the KV secret engine to manage access to credentials in a secret store without rotating them. This section provides an example of how to use the CLI commands to manage KV secret engines and managed secrets.

CLI Example for KV

  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 kv-example
--secret-store-id se-1ab23ac6620e8038
--secret-store-root-path="/secret/data/kv"
  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__kv-example=true
  4. Define a managed secret that will manage the passwords for a user:
    $ sdm admin managedsecrets create kv 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 kv 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 kv alice email=alice.glick@strongdm.com
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 kv 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=alice.glick@strongdm.com,password=pass1
Tags
  8. List all managed secrets for the secret engine:
    $ sdm admin managedsecrets list kv                              
ID                      Secret Engine ID         Name    Last Rotated At     Tags
ms-01b0524966c590c6     eng-3b4b567891c23dd4     alice   <nil>
  9. Delete the managed secret:
    $ sdm admin managedsecrets delete kv alice
Deleted managed secret: ms-2de34ab567c8b910
  10. Optionally log in to the Admin UI and go to Access > Credentials to view and validate managed secrets.

Entitlement of Credentials to Users and Groups and Policy-Based Action Control

Once managed secrets and secret engines are fully configured, you may create policies to entitle managed secrets to users and/or groups of users, as well as enforce fine-grained policy-based access control (PBAC) for the users who are entitled to access those managed secrets. Entitlement means using policies to allow specific users or groups of users to access and perform specific actions on managed secrets. Your policy statements can specify the users permitted to access specific credentials and what actions users are permitted to perform, such as reading, retrieving, rotating, or validating managed secrets. These policies can also include annotations (to require users to justify their actions, or receive an MFA challenge) and context-based conditions (such as access based on the user’s location) for enhanced control and flexibility.

The sections that follow describe how to structure policy statements to allow users and/or groups to access and perform actions on managed secrets. For all other information about policies, please see Policies.

Actions for credential management

In a policy statement, StrongDM credential management actions are set in the format StrongDM::ManagedSecret::Action::"<ACTION>", where <ACTION> is the name of the action (for example, StrongDM::ManagedSecret::Action::"rotate").

The possible actions for managed secrets are:

  • read
  • retrieve
  • rotate
  • validate

The resource in the policy statement also must be set as resource is StrongDM::ManagedSecret.

In the Policy Editor, if you are typing into the editing area directly, enter the action(s) (and resource) in the following way.

permit (
    principal,
    action in [StrongDM::ManagedSecret::Action::"retrieve"],
    resource is StrongDM::ManagedSecret
);

If multiple actions on managed secrets are allowed, enter each action in the following way.

permit (
    principal,
    action in [StrongDM::ManagedSecret::Action::"read", StrongDM::ManagedSecret::Action::"retrieve", StrongDM::ManagedSecret::Action::"rotate", StrongDM::ManagedSecret::Action::"validate"],
    resource is StrongDM::ManagedSecret
);

Actions for managed secrets may be set in policy statements in combination with context and annotations. Examples are shown in the next section.

Example policy statements for credential entitlement and PBAC

This section provides some examples of policy statements that entitle credentials to users and groups, as well as enforce policy actions on credential operations.

Allow users to conduct particular credential management actions when the user’s employeeNumber matches the managed secret’s employeeNumber tag value:

permit (
    principal,
    action in [StrongDM::ManagedSecret::Action::"validate", StrongDM::ManagedSecret::Action::"rotate"],
    resource is StrongDM::ManagedSecret
) when {
    principal.employeeNumber != "" &&
        resource.tags["employeeNumber"] == principal.employeeNumber
    };

Allow retrieval of managed secrets where the user’s employeeNumber matches the value of the managed secret’s employeeNumber tag:

permit (
    principal,
    action in [StrongDM::ManagedSecret::Action::"retrieve"],
    resource is StrongDM::ManagedSecret
) when {
    principal.employeeNumber != "" &&
        resource.tags["employeeNumber"] == principal.employeeNumber
    };

Allow users with the “secrets-admin” role to perform public read/rotate/validate actions on managed secrets (note that the role value is the role ID rather than the role name in the example shown):

permit (
    principal in StrongDM::Role::"r-5e367aa86759a7b8",
    action in [StrongDM::ManagedSecret::Action::"read", StrongDM::ManagedSecret::Action::"rotate", StrongDM::ManagedSecret::Action::"validate"],
    resource is StrongDM::ManagedSecret
);

Allow users with the “production-access” role to perform retrieve/public read/rotate/validate actions on managed secrets tagged with env=production:

@justify("Please provide a reason to do this.")
permit (
    principal in StrongDM::Role::"r-3618ea926759a881",
    action in [StrongDM::ManagedSecret::Action::"read", StrongDM::ManagedSecret::Action::"retrieve", StrongDM::ManagedSecret::Action::"rotate", StrongDM::ManagedSecret::Action::"validate"],
    resource is StrongDM::ManagedSecret
) when {
    resource.getTag("env") == "production"
    };

Allow users with the “development-access” role to perform retrieve/public read/rotate/validate actions on managed secrets tagged with env=development:

@justify("Please provide a reason to do this.")
permit (
    principal in StrongDM::Role::"r-496d29476759a8c6",
    action in [StrongDM::ManagedSecret::Action::"read", StrongDM::ManagedSecret::Action::"retrieve", StrongDM::ManagedSecret::Action::"rotate", StrongDM::ManagedSecret::Action::"validate"],
    resource is StrongDM::ManagedSecret
) when {
    resource.getTag("env") == "development"
    };

Allow users with the “staging-access” role to perform retrieve/public read/rotate/validate actions on managed secrets tagged with env=development:

permit (
    principal in StrongDM::Role::"r-2725a45a6759a8ed",
    action in [StrongDM::ManagedSecret::Action::"read", StrongDM::ManagedSecret::Action::"retrieve", StrongDM::ManagedSecret::Action::"rotate", StrongDM::ManagedSecret::Action::"validate"],
    resource is StrongDM::ManagedSecret
) when {
    resource.getTag("env") == "staging"
    };

Allow retrieve/public read/rotate/validate actions on managed secrets tagged with “owner” equal to the principal’s email:

permit (
    principal,
    action in [StrongDM::ManagedSecret::Action::"read", StrongDM::ManagedSecret::Action::"retrieve", StrongDM::ManagedSecret::Action::"rotate", StrongDM::ManagedSecret::Action::"validate"],
    resource is StrongDM::ManagedSecret
) when {
    resource.getTag("owner") == principal.email
};

Allow admins to access managed secrets:

permit (
    principal,
    action in [StrongDM::ManagedSecret::Action::"read", StrongDM::ManagedSecret::Action::"rotate", StrongDM::ManagedSecret::Action::"validate"],
    resource is StrongDM::ManagedSecret
) when {
    principal.permissionLevel == "admin"
    };

Allow all credential management actions on secrets tagged with foo=bar:

permit (
    principal,
    action in [StrongDM::ManagedSecret::Action::"read", StrongDM::ManagedSecret::Action::"validate", StrongDM::Action::"rotate", StrongDM::ManagedSecret::Action::"retrieve"],
    resource is StrongDM::ManagedSecret
) when {
    resource.tags["foo"] == "bar"
};

Forbid access to managed secrets if there is an error:

@error("this is a test")
forbid (
    principal,
    action in [StrongDM::ManagedSecret::Action::"read", StrongDM::ManagedSecret::Action::"retrieve"],
    resource
) when {
    context.network.clientIp.isInRange(ip("99.174.173.5/32"))
};

Logging

Logs for credential retrieval and rotation are recorded in the following areas within StrongDM:

  • Activity logs: Secret engine and managed secrets activities
  • Credentials logs: All user activity related to rotation, validation, and retrieval operations
  • Policy logs: Any activity that matches the defined policy

All admin actions to set up credential management and rotation are recorded in logs, including when a secret engine or managed secret is created, updated, and deleted. Rotation and retrieval of managed secrets are logged when the expiration time of the managed secret is changed.

End User Interaction With Credentials

In the Admin UI in Access > Credentials, StrongDM users can view the list of managed secrets that they are eligible to view. In addition, users can see the actions (such as read, retrieve, rotate, and validate) they can perform on the managed secrets based on the access being provided by the admin.

If users are not entitled to view or take any action on managed secrets, the Credentials page is empty.