Password vaults
Password vault support allows database connectors and file connectors (FTP and SFTP) to fetch login credentials from an external secret manager at runtime. DCT Compliance calls the vault to retrieve credentials only when it needs them — at connector test time and at job execution — and never stores them on the connector.
DCT supports four vault types: HashiCorp Vault (including Enterprise namespaces), CyberArk, GCP Secret Manager, and Azure Key Vault.
Two objects connect a file connector to an external secret manager:
-
Password vault — stores the details DCT uses to connect to the secret manager, such as the host, authentication type, and access credentials. One vault can support multiple credential paths and connectors.
-
Credential path — belongs to one vault and holds the vault-specific lookup keys DCT Compliance uses to retrieve a username and password. For example, a HashiCorp KV path, a CyberArk query string, or an Azure secret name.
Set credential_path_id on a file connector to point it at a credential path. When DCT needs credentials, it calls the vault through the credential path to fetch them.
Sensitive field handling
DCT encrypts and masks a fixed set of sensitive keys in vault configuration: privateKey, secretId, token, serviceAccountIdJson, and clientSecret. These values appear as ****** in all API and UI responses after creation. Other fields such as host, port, clientId, and tenantId appear in plaintext.
Credential path lookup parameters are not masked — they are lookup keys, not secrets.
Updating a vault
When you update a vault, DCT preserves any sensitive value you omit from the request. Re-submitting a GET response will not overwrite stored secrets.
You can perform the following operations: