Introduction to HashiCorp Vault Secrets Management
HashiCorp Vault is a secrets manager: a service that stores credentials such as database passwords, access keys, and role identifiers, controls who may read them through policies, and hands them out to applications that authenticate to it. Teams use it so that a credential lives in one audited place and is changed there, not in every application that needs it.
The Qualytics Secrets Management option lets a connection fetch its credentials from Vault at the moment they are needed instead of storing them in Qualytics. You tell Qualytics how to log in to Vault and where the secret lives, then write ${key} in any connection field that should take its value from that secret. The login and the fetch happen every time the connection is opened, so a credential changed in Vault is picked up on the next use with no change in Qualytics.
Not only Vault
The form group is labelled HashiCorp Vault because Vault is the most common provider, but the integration is generic. Any secrets manager that offers a REST login endpoint returning a token in JSON, and a REST endpoint returning the secret as a JSON object, works with the same six fields. The JSONPaths and the header name are what adapt it to each product. One limit: the extracted token is sent as the header value exactly as returned, so a product that needs a prefix such as Bearer must return it as part of the token.
Notes
It belongs to the connection. Secrets management is configured on the connection, so every datastore that shares the connection resolves its secrets the same way. It is editable when you create a connection and read-only when you reuse an existing one.
The secret's engine decides one field. Vault's KV secrets engine comes in two versions, and the database secrets engine serves dynamic credentials. They return the key/value pairs at different depths in the response, so the Data JSONPath differs: $.data.data for KV version 2, $.data for KV version 1 and the database engine. The form pre-fills $.data. See How It Works.
Namespaces travel in the URL. On Vault Enterprise and HCP Vault, roles and secrets live inside namespaces, and the namespace must appear in both the Login URL and the Secret URL right after /v1/. A missing namespace does not produce a namespace error; it produces invalid role or secret ID. See How It Works.
Qualytics must reach Vault. The addresses Qualytics connects from are listed below every connection form. Your firewall must allow them to reach Vault, and Vault's hostname must resolve from inside the Qualytics deployment. A connection test that waits about two minutes and then fails with a gateway timeout has stalled somewhere in the chain, and Vault being unreachable is the most common place. See How It Works and Troubleshooting.
Deep Dive
-
How It Works
The four-step login-and-fetch flow, the six form fields and their correct values, the Data JSONPath by engine, the
${key}rule, namespaces, and network requirements.
How-tos
-
Prepare Vault
Store the secret, write the policy, enable AppRole, create the role, mint the credentials, and verify the whole chain from the Vault CLI before touching Qualytics.
-
Configure the Connection
Fill in the Secrets Management fields on a connection and reference the secret's keys from the connection fields.
Reference
-
Troubleshooting
Every connection-test message the integration can produce, grouped by the stage that failed, with its cause and fix.
-
FAQ
Caching, sharing one secret across connections, other secrets managers, and what can and cannot be referenced.