HashiCorp Vault FAQ
Answers to common questions about using HashiCorp Vault, or another secrets manager, with a Qualytics connection. Sections are grouped by topic; pick the heading closest to what you are working on.
How it behaves
Does Qualytics cache the secret?
No. The login and the fetch happen every time the connection is opened, including connection tests, syncs, profiles, and scans. This is what makes a credential changed in Vault take effect automatically, and it is also why Vault must stay reachable for as long as the datastore is in use. Only a failure to reach Vault is remembered: for five minutes after one, tests and operations fail right away without contacting Vault, and the message says when the next try happens. See How It Works.
What happens if Vault is down?
Every operation on datastores using that connection fails until Vault answers again, with a connection-test message that names the stage that failed. Nothing is stored in Qualytics to fall back on, by design. See Troubleshooting.
Do I need to re-enter anything when a credential changes?
Only if the credential that changed is the one Qualytics logs in to Vault with. A changed database password or access key inside the secret is picked up on the next use. A rotated AppRole secret ID must be updated in the Credentials Payload.
Setup choices
Which Vault auth method should I use?
Any method that returns a token from a POST works, and all of them return it at $.auth.client_token. AppRole is the usual choice for a service like Qualytics because it is not tied to a person's account and its secret ID can be rotated independently. See Prepare Vault.
Why does the form pre-fill $.data when my secret needs $.data.data?
$.data is correct for KV version 1 and for the database secrets engine. KV version 2, the default for new mounts, nests the key/value pairs one level deeper. Check the secret's API path: if it contains /data/, use $.data.data. See Choosing the Data JSONPath.
Can one secret serve several connections?
Yes. Any number of connections can point at the same Secret URL, each referencing the keys it needs. A separate role per team or per environment keeps the policies narrow.
Can a file, such as a keytab or a service account key, come from Vault?
Yes. Next to any connection file field, click Type a value instead and enter ${key} for the key that holds the file's contents, instead of uploading the file. The reference is checked when you save, and an unknown key is rejected with the keys the secret does hold. Store a keytab as its base64 form, since a reference is used exactly as stored. See File fields.
Can I reference a secret inside the Secrets Management fields themselves?
No. Substitution applies to the connection's own fields, such as host, username, password, access keys, and role ARN. The six Secrets Management fields are used as typed.
Other secrets managers
Which products besides Vault work?
Any product whose REST API can be driven with the six fields: a login POST that returns a token in a JSON body, and a GET that returns the secret as a JSON object. Examples include CyberArk Conjur, Azure Key Vault behind a REST gateway, and AWS Secrets Manager exposed through an API Gateway. Adjust the Token JSONPath, Data JSONPath, and Token Header Name to the product's responses. One limit to plan for: the extracted token is sent as the header value with nothing added, so a product that expects Authorization: Bearer <token> must return the token with the Bearer prefix already in it, which usually means a gateway in front of it. See How It Works.
Does Qualytics support a namespace header?
No. Namespaces are expressed in the URL paths, right after /v1/, which Vault accepts everywhere. See Namespaces.