Close
logodocs

Configure HashiCorp Vault Integration

Secret store integrations allow you to use your existing third-party secret stores with strongDM. Your credentials are stored in a tool that is controlled by you, and those credentials are never transmitted to strongDM in any form. If you would like to learn more about how this integration works and why you might wish to use it, please read the Secret Stores Reference.

This guide will walk you through how to integrate HashiCorp Vault with strongDM, as well as how to use it to connect to resources.

Limitations

The following are not supported for this integration:

  • HashiCorp Cloud Platform (HCP) Vault
  • Automatic rotation of the SecretID (i.e., VAULT_SECRET_ID environment variable)
  • Any other authentication method besides token-based authentication, TLS certificate-based authentication, or AppRole authentication
  • Any secrets engine that does not conform to the same URL structure as KV 1 or KV 2 (e.g., key management or SSH certificate signing)
  • Writing credentials to Vault (i.e., credentials must already be in Vault for strongDM to read them)

Requirements

Before you begin, ensure that you have the following:

  • A running Vault server (see the Vault Installation Guide)
  • Credentials to some of your resources, stored in the Vault instance
  • Correct paths to the credentials

Authentication to Vault

strongDM supports three authentication methods to enable your Relay to authenticate with Vault: token-based authentication, TLS certificate-based authentication, and AppRole authentication. For more information on these methods, see HashiCorp's Vault tutorials: Token Authentication, TLS Certificate Authentication, and AppRole Authentication.

Although token-based authentication for Vault secret stores may be a good resource for testing and quick implementation, token-based authentication is not recommended for production environments.

Token-based authentication

Set the VAULT_TOKEN environment variable to allow the Relay to authenticate with Vault.

  1. Get a token for Vault.
  2. Open the file /etc/sysconfig/sdm-proxy (unless you have moved or renamed your sdm-proxy file) for editing.
  3. In the file, add the following line to set the necessary environment variable (VAULT_TOKEN) on your Relay, being sure to replace <YOUR_TOKEN> with the actual value:
    VAULT_TOKEN=<YOUR_TOKEN>
  4. To enable the token to be periodically renewed automatically, also set the LEASE_RENEWAL_TTL environment variable. Be sure to replace <RENEWAL_RATE> with the specific increment of time after which you intend the token to be renewed. The rate is specified as a number of seconds with no suffix (e.g., 3600 for 3,600 seconds or 1 hour).
    LEASE_RENEWAL_TTL=<RENEWAL_RATE>
  5. Restart the sdm-proxy service (with something like sudo systemctl restart sdm-proxy, depending on your distribution).

TLS certificate-based authentication

Follow the Vault documentation regarding certificate authentication with Vault.

When you install the TLS certificates on the Relay, place them in a directory that is accessible to the sdm relay service. Save the file paths for use later. Note that the policy for the certificate used needs to allow access to the secret paths.

AppRole authentication

Set the environment variable inputs VAULT_ROLE_ID, VAULT_SECRET_ID, and VAULT_TOKEN_TTL to allow the Relay to authenticate with Vault.

  1. Get your RoleID and SecretID for Vault.
  2. Determine what value to set for VAULT_TOKEN_TTL, an integer number of seconds (e.g., 600) after which the Relay will refresh the credentials retrieved with VAULT_ROLE_ID and VAULT_SECRET_ID. Its value should be set to approximately match but not exceed the lifetime of tokens generated with the AppRole authentication method, which is the token_ttl setting that is configured when AppRole is enabled in Vault.
  3. Open the file /etc/sysconfig/sdm-proxy (unless you have moved or renamed your sdm-proxy file) for editing.
  4. In the file, add the following lines to set the necessary environment variables on your Relay, being sure to replace the placeholders with the actual values:
    VAULT_ROLE_ID=<YOUR_ROLE_ID>
    VAULT_SECRET_ID=<YOUR_SECRET_ID>
    VAULT_TOKEN_TTL=<YOUR_TOKEN_TTL>
    LEASE_RENEWAL_TTL=<YOUR_RENEWAL_RATE>
  5. Restart the sdm-proxy service (with something like sudo systemctl restart sdm-proxy, depending on your distribution).

Configure the Secret Store with the Admin UI

Once you have your Vault set up, credentials stored, and your Relay is able to access said credentials, it's time to register the Vault with strongDM.

  1. In the Admin UI, go to Network > Secret Stores.

  2. Click the add secret store button.

  3. On the Add Secret Store form, set the following:

    Secret Stores Settings
    Secret Stores Settings

    1. Display Name (Required): The name that you enter here will show up in the Admin UI.

    2. Secret Store Type (Required): Select either HashiCorp Vault, HashiCorp Vault (Token), or HashiCorp Vault (AppRole).

    3. Enter the appropriate authentication information for the selected Secret Store Type:

      1. For HashiCorp Vault (Token) (token-based authentication), enter the server address (e.g., https://vault.example.com:1235).
      2. For HashiCorp Vault (certificate-based authentication), enter the paths to the certificates stored on your Relay server.
      3. For HashiCorp Vault (AppRole) (AppRole authentication), enter the server address (e.g., https://vault.example.com:8200).
    4. Namespace (Optional): If you have a secret inside a Vault Enterprise namespace, you can use this option to allow strongDM to authenticate to a specified namespace and access the secret within it. Using either a root token or a token created inside the namespace, you can access the secret in the following ways:

      1. Set an empty string and use the secret path namespace/mysecret?key=username.

      2. Set namespace/ and use the secret path mysecret?key=username.

        If you try to use a token from namespace1/, for example, but you configure the secret store to use namespace2/, the secret store healthcheck will fail.

If you have configured the Relay correctly for secret store access and authentication, you will see the green online indicator.

Test Access to the Resource

Now, create a resource that uses the secret store, assign it to a Role that is assigned to a User, and verify that you can connect.

  1. In the Admin UI, add a new resource, such as a Server or Datasource, and choose the Vault Secret Store type.
  2. Fill out the information for a resource whose credentials you have stored in your Vault secret store.
  3. Select the Vault Secrets Store you created for the Secret Store field, and then fill in the path to the secrets that you have stored in your secret store.
    1. Vault accepts plaintext secrets, which you would use to store one credential field per secret, or JSON secrets, which could include many credential values with different keys. If using JSON, add the key along with the path to the credential, (e.g., example-secret?key=username). Note that Vault will even allow the direct import of JSON (e.g., vault kv put secret/foo @data.json).
    2. It is preferred that certificates be Base64-encoded. If the secret you are storing is a certificate, you should Base64-encode it, and then enter the path as follows when setting up a resource to use it: example-secret?key=certificate&encoding=base64.
  4. Submit the form.
  5. Go to Roles, create a Role with an access rule that grants access to the resource, and assign the Role to the User.
  6. Log in as that User in your local GUI (or have the User do so, if not yours) and verify that the resource exists, test a connection, and execute a query.

Congratulations! You have connected to a resource using secret stores.

If any errors occur, contact strongDM Support.

Installation — Previous
Configure GCP Secret Manager Integration
Next — Admin UI Guide
Admin UI Overview