Articles in this section

Configuring HashiCorp Vault in StorageGuard

Avatar
Garry Savulkin
  • Updated

[ Applies to ] StorageGuard 9.2.7 and later   /   HashiCorp Vault KV secrets engine (v1 and v2)   /   Scan credentials

StorageGuard can read the credentials of a scan account from HashiCorp Vault each time it scans, instead of storing them itself. When the secret changes in Vault, StorageGuard uses the new value on the next scan. This article explains how to create a HashiCorp credential in StorageGuard and use it in a connectivity policy.

Before you begin

  • StorageGuard 9.2.7 or later.
  • A running HashiCorp Vault server. To install one, see Install Vault on the HashiCorp website.
  • A secret in a Vault key/value (KV) secrets engine that holds the credentials of the scan account.
  • The path of that secret, and the version of the KV secrets engine it is stored in (v1 or v2).
  • A Vault policy that allows StorageGuard to read the secret.
  • A StorageGuard account with administrative privileges.

Tip: To confirm the path before you configure StorageGuard, read the secret with the Vault CLI. The vault kv commands take the same path you'll enter in StorageGuard, for both KV versions:

vault kv get secret/my-app/db-creds

Create the HashiCorp credential

  1. Log in to the StorageGuard web interface.
  2. Go to Settings > Scan > Authentication > Credentials.
  3. Click Add new.
  4. In the Type list, select Hashicorp.
  5. In Name, enter a descriptive name. You'll select the credential by this name in connectivity policies.
  6. In Secret Path, enter the path of the secret. See Enter the secret path.
  7. Click Apply.

Enter the secret path

Enter the full path to the secret, in the form <mount>/<path to secret>. Use the logical path, the same one the vault kv CLI commands use, whatever the KV version.

KV version Enter Don't enter
KV v2 secret/my-app/db-creds secret/data/my-app/db-creds or secret/metadata/my-app/db-creds
KV v1 secret/my-app/db-creds —

Note: In KV v2, Vault's HTTP API and policies insert data/ after the mount, but StorageGuard expects the path without it. If you copied the path from a Vault policy or an API URL, remove data/ or metadata/.

Tip: The Vault policy for a KV v2 secret does include data/. For example, a policy that lets StorageGuard read the secret above looks like this:

path "secret/data/my-app/db-creds" {
  capabilities = ["read"]
}

Use the credential in a connectivity policy

  1. Go to Settings > Scan > Authentication > Policies and create a new connectivity policy.
  2. In the Credentials field, select the HashiCorp credential you created.
  3. Save the policy and assign it to the systems (CIs) or system groups that use this account.
  4. Run a scan of one of those systems and confirm that it completes without authentication errors.

Note: You can use one HashiCorp credential in several connectivity policies, and assign one connectivity policy to several systems or system groups.

Troubleshooting

Symptom Likely cause Resolution
The secret isn't found The path includes data/ or metadata/, the mount name is wrong, or the secret doesn't exist. Enter the logical path. Check it with vault kv get <path>.
Vault denies access to the secret The Vault policy doesn't grant read on the secret. Grant read on the secret. For KV v2, the policy path must include data/.
The secret is read but the scan fails to log in The values in the secret are wrong or not in the format StorageGuard expects. Check the user name and password stored in the secret.

[ Still need help? ]

If StorageGuard still can't read the secret, submit a request and include the secret path (without its values), the KV version, and the scan log.

Related articles

Comments

0 comments

Please sign in to leave a comment.