> For the complete documentation index, see [llms.txt](https://docs.strongdm.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.strongdm.com/admin/access/secret-stores.md). # Secret Stores {% hint style="info" %} This page discusses the available options for secret stores in StrongDM and how to configure them. For information on managing secrets, rotating them, or entitling them to users, see the [StrongDM Vault](/admin/secrets.md) page, and for information on configuring resources to point at a secret store for credentials, see the relevant [resource guide](/admin/resources.md). {% endhint %} ## What Are Secret Stores? When managing your resources in StrongDM, you can store credentials with StrongDM as you configure each resource. Alternatively, you can use secret stores. Secret store integrations provide an option to store resource credentials in a centralized location. There are a variety of supported secret stores, including StrongDM Vault, StrongDM's secret store, and several third-party services. If your organization already manages and rotates credentials with a supported secret store provider, nothing about that workflow has to change. ## 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, often as part of a zero trust initiative. You can take advantage of these secret store integrations 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. {% hint style="info" %} Once you set up a resource with a specific secret store provider, you cannot assign a different one to that resource later. However, you can recreate the resource, or create an additional instance of the resource, as necessary. {% endhint %} ### Update Credentials When you add, change, or rotate credentials stored with a third-party secrets storage tool, StrongDM neither notices nor cares. However, if you move or remove a credential, you should update its path where you used it in credential configuration in StrongDM to avoid disrupting service. StrongDM's secret engines can also be used to manage secrets that are in your secret stores. StrongDM provides a key-value secret engine for simple management of credentials within a secret store, and also specialized secret engines to keep the actual credentials on particular services and resources rotated in tandem with the copies in the backing secret store. A secret store may have a variety of credentials stored in it, so there may be multiple StrongDM secret engines that use it. To learn more about secrets management through StrongDM (rather than a third-party service) see the [Secrets Management](https://github.com/strongdm/docs/blob/main/gitbook-content/admin/access/secrets-management.md) section. ### Credential Storage in Secret Stores Credentials for resources accessed through StrongDM can be stored in your secret store. Credentials that are used 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. ![](https://4180056444-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FF7eka9SH5TT8nJm2ZfWj%2Fuploads%2Fgit-blob-fc975b5e2bc9ecec2e3d4149ae2c238cf061be11%2Fsecretstores-aws.png?alt=media) #### **Allow credential storage in StrongDM** You have the option to exclusively use a third-party secret store(s) and globally disallow saving resource credentials directly with StrongDM. Conversely, you also have the option to allow credentials to be stored directly with StrongDM in your resource configurations as you set them up and have a mixed system. In this case, some resources would use third-party secret stores, while others would have their credentials stored in resource configurations. You can even have two versions of the same resource with different credentials, stored in different places, with different access levels. {% hint style="info" %} In addition to storing credentials in secret stores, you have the option to store them on StrongDM nodes that you host. To learn more, see [Provision Node Credentials](#provision-node-credentials). {% endhint %} ## Authentication With Secret Stores Your relay needs to be able to authenticate with the secret stores provider. Most providers require credentials on the relay itself, whereas some authenticate with cloud identity instead. Where credentials are required, there are two ways to supply them: provision them to the node with `sdm nodesecrets` in the CLI, or set them as environment variables on the relay server. A provisioned credential takes precedence over an environment variable of the same name. Environment variables remain fully supported. See [Provision Node Credentials](#provision-node-credentials) to learn about which credentials can be provisioned, how to provision them on hosts and in containers, and how to migrate from environment variables. The configuration guide for each of the following providers covers which values that provider needs. 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. {% hint style="info" %} If a resource goes offline due to the inability of your gateway(s) to locate proper credentials for it, existing connections to that resource that have already been authenticated will persist. {% endhint %} StrongDM currently supports the following secret store services: * [StrongDM Vault](/admin/access/secret-stores/strongdm-vault.md) * [AWS Secrets Manager](/admin/access/secret-stores/aws-secrets-manager.md) * [Azure Key Vault](/admin/access/secret-stores/azure-key-vault.md) * [CyberArk Conjur](/admin/access/secret-stores/cyberark-conjur.md) * [CyberArk PAM](/admin/access/secret-stores/cyberark-pam.md) * [Delinea Secret Server](/admin/access/secret-stores/delinea-secret-server.md) * [GCP Secret Manager](/admin/access/secret-stores/gcp-secret-manager.md) * [HashiCorp Vault](/admin/access/secret-stores/hashicorp-vault.md) ### 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. {% hint style="info" %} Keys for AWS Secrets Manager cannot be [provisioned to a node](#provision-node-credentials). {% endhint %} * AWS Documentation: [Use IAM Policies for Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_identity-based-policies.html) * AWS Tutorial: [Create and Retrieve a Secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials_basic.html) * AWS Article: [Authentication and Access Control for AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access.html). * You will need to store the `AWS_ACCESS_KEY_ID` and `AWS_ACCESS_KEY` for a key that has access to the Secrets Manager as environment variables on the relay server. * [Integrate AWS Secrets Manager with StrongDM](/admin/access/secret-stores/aws-secrets-manager.md) ### 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. * [Azure Key Vault Documentation](https://learn.microsoft.com/en-us/azure/key-vault/) * [Integrate Azure Key Vault with StrongDM](/admin/access/secret-stores/azure-key-vault.md) ### CyberArk Conjur {% hint style="info" %} This feature is part of the Enterprise plan. If it is not enabled for your organization, please contact StrongDM at the [StrongDM Help Center](https://help.strongdm.com/hc/en-us). {% endhint %} CyberArk Conjur is a secrets store platform that provides role based access control for secrets such as passwords and SSH keys. * [CyberArk Conjur Quick Start](https://www.conjur.org/get-started/quick-start/oss-environment/) * [Integrate CyberArk Conjur with StrongDM](/admin/access/secret-stores/cyberark-conjur.md) ### CyberArk PAM {% hint style="info" %} This feature is part of the Enterprise plan. If it is not enabled for your organization, please contact StrongDM at the [StrongDM Help Center](https://help.strongdm.com/hc/en-us). {% endhint %} 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. * [CyberArk PAM Documentation](https://docs.cyberark.com/pam-self-hosted/latest/en/Content/Resources/_TopNav/cc_Home.htm) * [Integrate CyberArk PAM with StrongDM](/admin/access/secret-stores/cyberark-pam.md) ### Delinea Secret Server {% hint style="info" %} This feature is part of the Enterprise plan. If it is not enabled for your organization, please contact StrongDM at the [StrongDM Help Center](https://help.strongdm.com/hc/en-us). {% endhint %} Delinea Secret Server is a service for securely storing and accessing secrets, such as API keys, passwords, certificates, and cryptographic keys. * [Delinea Secret Server Documentation](https://docs.delinea.com/online-help/products/secret-server/current) * [Integrate Delinea Secret Server with StrongDM](/admin/access/secret-stores/delinea-secret-server.md) ### 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](https://cloud.google.com/secret-manager/docs/quickstart) * Tutorial: [Authenticating as a Service Account](https://cloud.google.com/docs/authentication/production) * [Integrate GCP Secret Manager with StrongDM](/admin/access/secret-stores/gcp-secret-manager.md) ### 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. * Tutorial: [TLS Certificate Authentication](https://www.vaultproject.io/docs/auth/cert) * Tutorial: [Token Authentication](https://www.vaultproject.io/docs/auth/token) * [Integrate HashiCorp Vault with StrongDM](/admin/access/secret-stores/hashicorp-vault.md) ## Summary 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 Configuration ### Create a Secret Store To integrate with a new secret store: 1. In the Admin UI, go to **Settings** > **Secrets 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. ![](https://4180056444-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FF7eka9SH5TT8nJm2ZfWj%2Fuploads%2Fgit-blob-fc975b5e2bc9ecec2e3d4149ae2c238cf061be11%2Fsecretstores-aws.png?alt=media) #### 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 that specific configuration guide. 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. ### Provision Node Credentials Node credentials are the credentials (for example, a Delinea Secret Server password or a HashiCorp Vault token) that a node (a gateway, relay, or proxy worker) can use to authenticate to StrongDM and to external secret stores. You can provision the credentials a node uses to authenticate to StrongDM and to external secret stores instead of using environment variables, so that credentials no longer need to appear in service configuration files. You provide each value once (at a hidden prompt, from a pipe, or from a file), and afterward, only the key name appears in the CLI output. This section describes which node credentials may be provisioned, how they are provisioned, and how to manage them with the StrongDM CLI. #### Which credentials can be provisioned The following table shows which credentials can be provisioned through the node, along with the acceptable key names. Key names are the same names that [environment variables](/admin/deployment/environment-variables.md) use.
Secret Store TypeKey Names
Active DirectorySDM_ADCS_USER, SDM_ADCS_PW
Delinea DevOps Secrets Vault (DSV)DSV_CLIENT_ID, DSV_CLIENT_SECRET
Delinea Secret ServerDELINEA_USERNAME, DELINEA_PASSWORD
HashiCorp Vault (AppRole)VAULT_ROLE_ID, VAULT_SECRET_ID
HashiCorp Vault (token)VAULT_TOKEN
CyberArk ConjurCONJUR_AUTHN_LOGIN, CONJUR_AUTHN_API_KEY
CyberArk PAMPAM_USERNAME, PAM_PASSWORD
GCP Secret Manager / GCP CASGOOGLE_APPLICATION_CREDENTIALS_JSON
In addition to key names, node credentials can be provisioned via the following ways: * **Environment variables:** Environment variables named in the secret store's configuration * **Keyfactor:** Enrollment username and code variables named in the secret store's configuration #### Additional information The node's own credentials (the relay token and proxy cluster keys) are stored by `sdm install` automatically and need no manual provisioning. Node credential provisioning is not available for AWS and Azure secret stores. Only credentials are read from the node. Non-secret settings, such as server URLs, TLS options, or tuning variables (for example, `DELINEA_SERVER_URL` and `DELINEA_API_TENANT`) are read from the environment only; a value with one of those names in the node has no effect. #### Provision Node Credentials on a Host Install To get started with node credentials, use the CLI to provision credentials on a host install. The CLI commands `sdm install --relay` and `sdm install --worker` store the node's own credentials automatically during installation. Node credentials are managed afterward with `sdm nodesecrets`. Run `sdm nodesecrets set` and `sdm nodesecrets unset` as the user that the relay or worker service runs as. Each user has their own credential store, so credentials provisioned by a different user (including root) will not be available to the service. {% hint style="info" %} Changes made with `sdm nodesecrets set` or `sdm nodesecrets unset` take effect when the relay or proxy worker service restarts. You must restart the service for the credential changes to be applied. {% endhint %} #### Manage Node Credentials in the CLI After installation, node credentials are managed in the CLI with `sdm nodesecrets`. {% hint style="info" %} These CLI commands are available on host installs (that is, VMs and physical servers). In containers, credentials are provided through `SDM_SECRETS_FILE` instead; for more information, see [Provision Node Credentials in Containers](#provision-node-credentials-in-containers). {% endhint %} **Add a node credential** Use `sdm nodesecrets set ` to add a node credential. It prompts for the value twice and the input is hidden. For example: {% code overflow="wrap" %} ```sh sdm nodesecrets set DELINEA_PASSWORD ``` {% endcode %} You can provide the key name value at a hidden prompt on a terminal, as in the previous example, or you can pipe it in from a script, as in the following example: {% code overflow="wrap" %} ```sh printf '%s\n' "$PASSWORD" | sdm nodesecrets set DELINEA_PASSWORD ``` {% endcode %} Multi-line values (such as service-account keys, or PEM certificates) use `--from-file`. For example: {% code overflow="wrap" %} ```sh sdm nodesecrets set GOOGLE_APPLICATION_CREDENTIALS_JSON --from-file key.json ``` {% endcode %} Pass `-` to read from a pipe or redirect instead of a file: {% code overflow="wrap" %} ```sh sdm nodesecrets set GOOGLE_APPLICATION_CREDENTIALS_JSON --from-file - ``` {% endcode %} {% hint style="info" %} Values never appear on the command line, in shell history, or in output. {% endhint %} **List node credentials** Use `sdm nodesecrets list` to show credentials stored on the node secret store. Only names are shown, never values. {% code overflow="wrap" %} ```sh sdm nodesecrets list ``` {% endcode %} **Remove a node credential** Use `sdm nodesecrets unset ` to remove a value from the node secret store. For example: {% code overflow="wrap" %} ```sh sdm nodesecrets unset DELINEA_PASSWORD ``` {% endcode %} **View help text** You may view help text in the CLI by running the command with the `--help` or `-h` flag. For example: {% code overflow="wrap" %} ```shell $ sdm nodesecrets set --help NAME: sdm nodesecrets set - add or update node secrets; values are entered at a hidden prompt, never on the command line USAGE: sdm nodesecrets set [command options] KEY [KEY ...] DESCRIPTION: Values are single-line. On a terminal each value is asked for twice (hidden); with piped stdin, supply exactly one line per key. For a multi-line value (a service-account key, PEM material), use --from-file with exactly one KEY. Concurrent updates are last-writer-wins. OPTIONS: --from-file value read the value from FILE ('-' reads stdin whole); requires exactly one KEY ``` {% endcode %} For a copy of the help text for each CLI command, see the [CLI Reference docs for sdm nodesecrets](/references/cli/sdm.md). #### Provision Node Credentials in Containers {% hint style="info" %} The `sdm nodesecrets` CLI commands described in the previous section are available on host installs only. In a container, they refuse to run because containers are ephemeral. If using containers, you must provide credentials through `SDM_SECRETS_FILE` as described in this section. {% endhint %} The following steps show a general way to provision credentials in containers. The\ examples use Kubernetes; the same approach works with any container runtime that can\ mount a file and set an environment variable. 1. Mount a JSON file of key/value pairs (for example, from a Kubernetes Secret)\ containing the node credentials you want to provide. The file holds one entry per\ credential, using the key names from the table in [Which Credentials Can Be Provisioned](#which-credentials-can-be-provisioned): {% code overflow="wrap" %} ```sh {"DELINEA_USERNAME": "svc-sdm", "DELINEA_PASSWORD": "..."} ``` {% endcode %} 2. In the container's `env` block, point `SDM_SECRETS_FILE` at the path where you mounted that file. The following example assumes `/var/run/secrets/sdm/credentials.json`: {% code overflow="wrap" %} ```yml env: - name: SDM_SECRETS_FILE value: /var/run/secrets/sdm/credentials.json ``` {% endcode %} {% hint style="info" %} Where this is not configured, containers keep using environment variables as before. Running `sdm install` inside a container falls back to the previous environment-file behavior and says so with a warning. {% endhint %} #### How Credentials Are Chosen A provisioned credential always takes precedence over an environment variable of the same name. When a credential is served from the environment, the node logs a one-time informational notice per credential naming the migration path. Use these notices to find remaining environment-delivered credentials across a fleet. #### Migration From Environment Variables If you want to migrate from using environment variables to storing credentials on the node, follow these steps for each credential, in this order: 1. In the CLI, provide the value: `sdm nodesecrets set `. 2. Remove the corresponding line from the service's environment file or the container spec. 3. Restart the service. {% hint style="info" %} Removing the environment line is what stops environment delivery. Setting an empty value does not. {% endhint %} #### After Cloning or Re-imaging a Host {% hint style="warning" %} Credentials provisioned to a node cannot be used on a copy of that machine and cannot be recovered centrally. {% endhint %} On a cloned or re-imaged host, remove the node's secret store and provide the credentials again, using `sdm install` or `sdm nodesecrets set`. Error messages on such a host state the same remedy. Note that `sdm update` refuses to run on a host whose secret store cannot be read, with an error explaining why. ### Configure a Resource to Use a Secret Store 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](/admin/resources.md), 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 (or whatever credential the resource requires). These paths are the path within your secret store to the secret in question. Those paths may look something like `/path/to/mycredentials/username` or `/path/to/mycredentials/password`. If you’re using one secret with multiple key/value entries for specific credentials, the path may instead take the format of `/path/to/mycredentials?key=username`. This format may vary between secret store providers and will be indicated in the placeholder text for each field. If you are managing the credentials with a StrongDM Vault secret engine, the path of the secret engine (which can be seen in the secret engine's settings) will also be included, in the format `/secretenginepath/path/to/mycredentials?key=db_username`. {% hint style="info" %} The healthcheck for the new resource depends on the credentials being loaded from the secret store. If they are not, it will not go green. {% endhint %} 4. You're done. The resource is ready to be used within StrongDM. ## --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.strongdm.com/admin/access/secret-stores.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.