Secret Stores Reference
Last modified on August 10, 2022
What are Secret Stores?
Secret store integrations provide the option to store resource credentials in a third-party tool controlled by you, rather than saving them with strongDM. If your organization already manages and rotates credentials with a supported secret store provider, nothing about that workflow will have to change.
Why Secret Stores?
Secret Stores enable organizations to easily manage and automate the storage and rotation of credentials using third-party secrets 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. When you choose to store credentials for your resources in secret stores, your credentials will never be 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 Secret Stores:
- Configure a secret store provider for use with strongDM.
- Set up relay servers to be able to authenticate with the secret store.
- 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.
When you add, change, or rotate credentials, strongDM will neither notice nor care. However, if you move or remove a credential within the secret store itself, you must update its path within strongDM to avoid disrupting service.
All credentials for resources accessed through strongDM are stored in your secret store. Credentials to access your secrets 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.
Allowing credential storage in strongDM
You have the option to exclusively use secret stores and globally disallow saving resource credentials directly with strongDM.
Conversely, you also have the option to allow credentials to be stored with strongDM and have a mixed system. In this case, some resources would use secret stores, while others would have their credentials stored with strongDM. You can even have two versions of the same resource, one with stored credentials, the other without.
Authentication with Secret Stores
Your relay needs to be able to authenticate with the secrets 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:
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.
- AWS Documentation: Use IAM Policies for Secrets Manager
- AWS Tutorial: Create and Retrieve a Secret
- AWS Article: Authentication and Access Control for AWS Secrets Manager.
- You will need to store the
AWS_ACCESS_KEYfor a key that has access to the Secrets Manager as environment variables on the relay server.
- strongDM AWS Secret Store Configuration Guide
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.
- Tutorial: TLS Certificate Authentication
- Tutorial: Token Authentication
- strongDM Vault Secret Store Configuration Guide
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.
- Quickstart: Create and Access Secrets Using Secret Manager
- Tutorial: Authenticating as a Service Account
- strongDM GCP Secret Store Configuration Guide
Putting it together
Without secret stores:
- A user attempts to access a resource and their request is routed to a gateway.
- The gateway queries strongDM, verifying that the user’s connection is authorized.
- strongDM sends back encrypted credentials to the gateway to authenticate with the resource.
- The gateway reaches out to the resource and authenticates.
- 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.