Engines: connecting/authenticating
Introduction
After DCT Authentication is complete, the HTTPS should be securely configured on DCT and able to be authenticated against. The next step is to register an engine with DCT so that it can fetch results. DCT connects to all engines over HTTPS, thus some configurations might be required to ensure it can communicate successfully.
Truststore for HTTPS
If the CA certificate that signed the engine's HTTPS certificate is not a trusted root CA certificate present in the JDK, then custom CA certificates can be provided to DCT. If these certificates are not provided, a secure HTTPS connection cannot be established and registering the engine will fail. The insecure_ssl engine registration parameter can be used to bypass the check, however, this should not be used unless the risks are understood.
Get the public certificate of the CA that signed the engine’s HTTPS certificate in PEM format. IT team help may be required to get the correct certificates. Base64 encode the certificate with:
cat mycertfile.pem | base64 -w 0Copy the Base64 encoded value from the previous step and configure in values.yaml file under truststoreCertificates section. e.g. section will look like this:
truststoreCertificates:
<certificate_name>.crt: <base64 encode certificate string value in single line><certificate_name> can be any logically valid string value for e.g. “engine”.
All the certificates configured in truststoreCertificates section will be read and included in the trustStore which would be then used for SSL/TLS communication between DCT and Delphix Engine.
Authentication with the Delphix Engine
All authentication with the Delphix Engine is done using the username and password of an Engine Administrator. There are two methods for storing these credentials with DCT:
Stored and encrypted on DCT itself: Credentials are saved securely within DCT.
Retrieved from a password vault: Credentials are fetched from an external vault. Currently, only the HashiCorp vault is supported.
Fetching the credentials from a vault is recommended for enhanced security.
Adding a Compliance Engine
When adding a compliance engine, it is necessary to add two types of users:
Masking Administrator
Engine Administrator
If an Engine Administrator is not provided, no performance metrics can be collected by DCT.
HashiCorp vault
There are two high-level steps to configuring a HashiCorp vault. The first is to set up authentication with the vault and register the vault. The second is to tell DCT how to get the specific engine credentials needed from that registered vault. A single vault can be used for multiple different Delphix Engines.
Vault authentication and registration
First, DCT needs to be able to authenticate with the vault. DCT supports the Token, AppRole, and TLS Certificates authentication methods. This is done by passing a command to the HashiCorp CLI. It is recommended to first ensure that successful authentication is done and one can retrieve the credentials with the HashiCorp CLI directly to ensure the correct commands are passed to DCT.
Adding a vault to DCT is done through API calls to the /v2/management/vaults/hashicorp endpoint. All authentication methods requires the location of the vault is provided through the env_variables property in the POST body like so:
"env_variables": {
"VAULT_ADDR": "https://10.119.132.40:8200"
}Token
To use the token authentication method, this needs to be included as part of the env_variables field. The full example to register the vault would appear as:
curl --location --request POST 'https://<hostname>/v2/management/vaults/hashicorp' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--header 'Authorization: apk <your API key>' \
--data-raw '{
"env_variables": {
"VAULT_TOKEN": "<your token>"
"VAULT_ADDR": "https://10.119.132.40:8200"
}
}'A response should be received similar to the lines below:
{
"id": 2,
"env_variables": {
"VAULT_TOKEN": "<your token>"
"VAULT_ADDR": "https://10.119.132.40:8200"
}
}Note the id of the vault, this will be needed in the next step to register the engine.
AppRole
To use the AppRole authentication method, this needs to be included as part the login_command_args field, as shown below.
"login_command_args":
[ "write", "auth/approle/login", "role_id=1", "secret_id=123"]The full example to register the vault would appear as:
curl --location --request POST 'https://<hostname>/v2/management/vaults/hashicorp' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--header 'Authorization: apk <your API key>' \
--data-raw '{
"env_variables": {
"VAULT_ADDR": "https://10.119.132.40:8200"
},
"login_command_args":
[ "write", "auth/approle/login", "role_id=1", "secret_id=123"]
}'A response should be received similar to the lines below:
{
"id": 2,
"env_variables": {
"VAULT_TOKEN": "<your token>"
"VAULT_ADDR": "https://10.119.132.40:8200"
}
}TLS certificates
The configuration of mutual TLS authentication requires an additional step. This feature currently is NOT supported for Kubernetes deployment of DCT. This will be covered in later releases.
Retrieving engine credentials
Once DCT can authenticate with the vault, it needs to know how to fetch the relevant engine credentials. When registering an engine, the user will need to provide the HashiCorp CLI commands through the hashicorp_vault_username_command_args and hashicorp_vault_password_command_args parameters.
The relevant part of the engine registration payload will look like the following:
'{
"hashicorp_vault_id": 1
"hashicorp_vault_username_command_args": ["kv", "get", "-field=username", "kv-v2/delphix-engine-secrets/engineUser"]
,
"hashicorp_vault_password_command_args": ["kv", "get", "-field=password", "kv-v2/delphix-engine-secrets/engineUser"]
}'The hashicorp_vault_id will be the ID that was returned as part of the previous step. Note that the exact paths to fetch the username and password will vary depending on the exact configuration of the vault.