HashiCorp Vault integration¶
Connect DXDT to HashiCorp Vault for read-only, metadata-only security-posture visibility: seal/health state and version, mounted secret engines, enabled auth methods, ACL policy names, and what the supplied token itself is permitted to do. By design DXDT never reads secret values — only posture metadata.
| Setup time | ~8 minutes |
| Difficulty | Moderate |
Access required: Your Vault address and a read-only token whose policy grants read/list on the system posture paths (mounts, auth, policies, health). For Vault Enterprise, the relevant namespace.
Prerequisites¶
- The Vault address, e.g.
https://vault.acme.internal:8200, reachable from DXDT. - Ability to write an ACL policy and issue a token against it (or an existing least-privilege token).
- For Vault Enterprise only: the namespace DXDT should operate within.
Setup¶
1. Write a read-only posture policy¶
Create an ACL policy granting only read/list on the system paths DXDT inspects — for example sys/health, sys/mounts, sys/auth, sys/policies/acl, and auth/token/lookup-self. Do not grant capabilities on any secret data paths.
- Example capability line: path "sys/mounts" { capabilities = ["read", "list"] }.
- Repeat
read/listforsys/auth,sys/policies/acl, andsys/health. - Deliberately omit all
kv, database, PKI, and other secret-engine data paths.
2. Issue a token against the policy¶
Create a token bound to that policy, e.g. vault token create -policy=dxdt-readonly -ttl=768h. Copy the token value — this becomes vault_token. Plan to rotate it before expiry.
3. Identify the address and namespace¶
Use your Vault API address as vault_addr (e.g. https://vault.acme.internal:8200). If you run Vault Enterprise and want DXDT scoped to a specific namespace, set namespace; otherwise leave it blank (Vault Community/OSS has no namespaces).
4. Enter the configuration in DXDT¶
In the DXDT marketplace, open the Vault plugin. Enter vault_addr, paste the vault_token, and set namespace only for Vault Enterprise. Save to install.
Configuration fields¶
| Field | Where to find it |
|---|---|
Vault Address (vault_addr) |
Vault API address, e.g. https://vault.acme.internal:8200. Required. |
Vault Token (vault_token) |
Read-only token bound to a policy granting read/list on posture paths only (no secret data). Required. Sent as X-Vault-Token. |
Namespace (Vault Enterprise, optional) (namespace) |
Optional — Vault Enterprise namespace, sent as X-Vault-Namespace. Leave blank for Vault Community/OSS. |
Verify the connection¶
On save, DXDT calls ping (sys/health), returning seal status, version, and HA mode. You can then ask DXDT to list mounts or run token info to confirm the read-only posture data is accessible.
Security
By design DXDT reads Vault security posture and metadata ONLY — there is no command that reads secret values, and the integration is entirely read-only. Bind the token to a policy that grants read/list on sys/* posture paths exclusively and never on any secret-data path. Rotate the token on a schedule.
Troubleshooting¶
403 permission denied on list mounts/auth/policies
The token's policy does not grant read/list on the corresponding sys/* paths. Add read/list capabilities for sys/mounts, sys/auth, and sys/policies/acl to the policy and re-issue the token.
Token expired / 403 on token info
The token has passed its TTL or been revoked. Issue a fresh token against the read-only policy and update vault_token.
404 or namespace errors on Enterprise
namespace is missing or wrong for a Vault Enterprise deployment. Set namespace to the correct Enterprise namespace; leave it blank on Community/OSS.
Vendor documentation: https://developer.hashicorp.com/vault/docs/concepts/policies