Secrets

Overview

Secrets, or the credentials that authenticate your users to resources, are not revealed to the users when they connect to the resource through StrongDM. The node that delivers a user's traffic to the resource reaches out to StrongDM to obtain credentials for the user, injects them, and authenticates the user without ever revealing the credentials. When you store credentials with StrongDM directly as you configure resources (by filling in a username and password, access keys, certificate data, etc.) that is the extent of the process.

Secret stores are an alternative that allow you more options for the way you manage your secrets.

Secret Stores

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:

A secret store can be used for authentication to resources as an alternative to adding credentials directly to resources. When credentials are stored directly in resource configuration, the node that authenticates user traffic to the resource uses those credentials. When configured to use secret stores, the node instead reaches out to the secret store to obtain those credentials and authenticate the user to the resource.

Secret stores are used for two primary reasons:

  1. Security Requirements: In some cases, if you already use a secret store internally, your security protocols may require that you not store resource credentials directly with other services like StrongDM, and continue to use your approved secret store.

  2. Centralized Credential Management: A secret store provides a central place to manage credentials, so that they can be created, rotated, and deleted from one place, which is of increasing usefulness with larger sets of resources.

To learn more about how secret stores work with StrongDM, see the Secret Stores section.

Secret Stores

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.

If your organization uses a secret store provider for credentials, you likely use that provider's interface to manage your secrets. However, in some cases, it might be preferable for administrators to be able to use StrongDM to manage credentials for resources that StrongDM is proxying traffic to.

StrongDM secret engines can manage secrets within supported secret stores (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, Hashicorp Vault, or our own secret store, StrongDM Vault), and in some cases, rotate credentials within the resource itself, as well.

The Key Value secret engine can be used to manually create, update, or delete secrets within a supported secret store. This is useful when manual updates to the secrets are possible within StrongDM, or automation can be configured. It is also useful for the management of secrets that do not pertain to resource connection, such as end users fetching an administrative Windows credential for themselves.

The other secret engine types can be used to update, delete, or rotate user credentials within their resource type (for example, the Active Directory secret engine can be used to manage Active Directory credentials). At the same time, it also creates and keeps in sync a copy of the credentials in the supported secret store of your choice, which makes them available to authenticate StrongDM users to your resources.

StrongDM policies can also be used to entitle specific users to access secrets, manually retrieving them for various purposes outside of StrongDM resource access. For example, this process might be used to audit and log retrieval of a Windows administrator credential when needed by users.

For more information about using StrongDM to manage your secrets (in whichever secret store you prefer to use) see the secrets management section.

Secrets Management

Certificate Authorities

A certificate authority (CA) allows your organization’s SSH and RDP resources to authenticate with trusted certificates. Using certificate authentication eliminates the need to manage unique key pairs for each of your servers. StrongDM offers a CA for your organization to use, or you can connect with any supported third party service to use another CA. See the Certificate Authorities section for more details.

Certificate Authorities

Conclusions

When deploying StrongDM, consider which method you plan to use to manage the credentials that you will use to authenticate StrongDM to resources.

  • Store credentials with each resource record as you configure it. This option is simplest, and a good option for organizations that do not already use secret stores or who do not have large amounts of resources.

    • Next step: Check out our resource guides on how to configure a resource with StrongDM.

  • Set up a StrongDM Vault secret store and use StrongDM to manage those credentials centrally, rather than having to edit each resource when needing to update credentials.

  • Use your organization's third-party secret store. Set up the secret store integration with StrongDM, then configure resources to simply check a path within that secret store for the credentials, leaving you free to rotate and change them as desired from within your third-party tool without updating StrongDM resources.

    • Next Step: Review the supported secret store providers and read the guide on how to connect the one you choose to StrongDM.

  • Bring your own secret store, but use StrongDM to manage it, removing the need to use another tool to manage secrets when your admins already use StrongDM to manage access.

  • For resource types that require a Certificate Authority, you may choose to use StrongDM's CA or integrate with a third party option.

Last updated

Was this helpful?