Secret Stores

Last modified on September 17, 2024

What are Secret Stores?

Secret store integrations provide an option to store resource credentials in a centralized location. When managing your resources in StrongDM, you can use the Strong Vault, StrongDM’s secret store. Alternatively, you can use any supported third-party secret store option that you prefer. If your organization already manages and rotates credentials with a supported secret store provider, nothing about that workflow has to change.

You can configure secret store integrations to provide zero-trust authentication to your resources. In addition to Strong Vault, which is StrongDM’s built-in secret store offering, StrongDM supports integration with the following services to manage secrets:

Why Secret Stores?

Secret stores enable organizations to easily manage and automate the storage and rotation of credentials using third-party secret stores.

Some organizations’ security policies forbid the storage of credentials outside of a designated secret store provider. You can take advantage of this integration to adhere to that requirement while using StrongDM.

If you choose to store credentials for your resources in third-party secret stores, your credentials are not recorded on our servers. Your gateway servers request credentials directly from the secret stores to enable authentication.

How do Secret Stores work?

To set up integrations with third-party secret stores:

  1. Configure a secret store provider for use with StrongDM.
  2. Set up relay servers to be able to authenticate with the secret store.
  3. Each time you set up a new resource, give StrongDM a path to the credential it needs in the store.

When a client connects to a resource, the relay authenticates to your secret store provider, and fetches credentials for the resource. Those credentials never leave your relay server, and are never stored or recorded by StrongDM.

Updating credentials

When you add, change, or rotate credentials stored with a third-party secrets management tool, StrongDM neither notices nor cares. However, if you move or remove a credential, you must update its path within StrongDM to avoid disrupting service.

Credential storage

All credentials for resources accessed through StrongDM are stored in your secret store. Credentials to access your secret stores provider are kept on the relays you host. No credentials, either for your secret store provider or for your individual resources, are ever transmitted to StrongDM.

Secret Settings
Secret Settings

Allowing credential storage in StrongDM

You have the option to exclusively use a third-party secret store(s) and globally disallow saving resource credentials directly in the Strong Vault.

Conversely, you also have the option to allow credentials to be stored with Strong Vault and have a mixed system. In this case, some resources would use third-party secret stores, while others would have their credentials stored in the Strong Vault. You can even have two versions of the same resource with different credentials, stored in different places, with different access levels.

Authentication with secret stores

Your relay needs to be able to authenticate with the secret stores provider. If the secret store is down or inaccessible, that resource will be unavailable as well. The diagnostics panel for the resource indicates whether credentials are available, and details any errors that may occur during the process.

StrongDM currently supports the following secret stores:

Strong Vault

StrongDM comes with an integrated vault called Strong Vault. It’s the default secret store option when setting up a resource with StrongDM and requires no special configuration. It can store passwords, certificates, and keys, based on what is necessary for access to each type of resource. Those credentials are securely encrypted and not retrievable after setup, but they can be changed as needed.

AWS Secrets Manager

AWS Secrets Manager is managed and hosted on AWS. StrongDM supports two authentication modes with AWS Secrets Manager: authentication with an AWS Access Key ID and Access Key, saved on the relay; and authorizing the relay to access Secrets Manager using AWS IAM.

Azure Key Vault

Azure Key Vault is a cloud service for securely storing and accessing secrets such as API keys, passwords, certificates, and cryptographic keys.

CyberArk Conjur

CyberArk Conjur is a secrets management platform that provides role based access control for secrets such as passwords and SSH keys.

CyberArk PAM

CyberArk Privileged Access Manager (PAM) accounts facilitate access to privileged accounts on your resources and can store basic account properties as well as secret information such as passwords or keys.

Delinea Secret Server

Delinea Secret Server is a service for securely storing and accessing secrets, such as API keys, passwords, certificates, and cryptographic keys.

GCP Secret Manager

GCP Secret Manager is a secret store provider which can be administrated from Google’s developer admin panel. It accepts plaintext or JSON secrets.

HashiCorp Vault

Vault is a secret store tool which is self-hosted on your own infrastructure. StrongDM supports authenticating to HashiCorp Vault instances with either a TLS Certificate or Token Authentication.

Putting it together

Secret Stores Diagram
Secret Stores Diagram

Without secret stores:

  1. A user attempts to access a resource and their request is routed to a gateway.
  2. The gateway queries StrongDM, verifying that the user’s connection is authorized.
  3. StrongDM sends back encrypted credentials to the gateway to authenticate with the resource.
  4. The gateway reaches out to the resource and authenticates.
  5. A secure tunnel is established from client to resource.

With secret stores, this process is similar, with a key difference. The gateway still reaches out to StrongDM for authorization, but is not given any credentials for the resource (StrongDM does not have them). Instead, the gateway then reaches out to the assigned secret store provider to collect the credentials.

Secret Store Integration Settings

Create a secret store

To integrate with a new secret store:

  1. In the Admin UI, go to Settings > Credentials Management and to the Secret Stores tab.
  2. Click the add secret store button.
  3. On the Add Secret Store form:
    1. Enter a Display Name.
    2. Select the Secret Store Type.
    3. Fill in any remaining fields shown for your type.
      Secret Stores Settings
      Secret Stores Settings

Connection Details

Credentials for authenticating to the secret store reside on your Gateway/Relay servers. To learn how to integrate a specific secret store provider with StrongDM, read the configuration guides.

Once you’ve configured gateway servers to authenticate to the secret store, you can check its health on the Diagnostics tab.

Other Settings

In Settings > Security, you can set Allow credentials to be stored in StrongDM to No in order to require that all new resources use secret store integrations instead. Note that disabling this option does not affect existing resources (which will continue to function as they always have), only the creation of new ones.

Configure a Resource

Once your secret store integration is configured and you have set up authentication on your relay servers, you need to create resources that read their credentials from the secret store.

  1. In the Admin UI, add a new resource, such as a Server or Datasource.

  2. Fill in the fields as normal, but for the Secret Store field, choose your secret store.

  3. Fill in the path to the username and password. Those paths may look something like /path/to/credentials/db_username or /path/to/credentials/db_password. If you’re using one credential with multiple key/value entries, the path may instead take the format of /path/to/credentials?key=db_username. This format may vary between secret store providers and will be indicated in the placeholder text for each field.

  4. You’re done. The resource is ready to be used within StrongDM.

You can find resources and information about the following StrongDM topics in this section: