Password vault configuration

Introduction

The Continuous Compliance Engine supports the use of HashiCorp and CyberArk password vaults for connections to DB2, MariaDB, MSSQL, MySQL, Oracle, PostgreSQL, and Sybase databases. Utilizing this feature requires the presence of either a HashiCorp or CyberArk vault, as well as additional configuration actions on the Continuous Compliance Engine.

Password vault authentication is not supported for containerized masking deployments at this time.

Configuring a password vault on the appliance

Before attempting to access a password vault, the CA certificate for the vault must first be added to the Compliance Engine's trust store. Certificates can be managed through the Delphix Server Setup UI and the steps for doing so can be found on the TrustStore settings page.

Currently, password vaults and the associated credential paths can only be configured on the appliance using the API. The Continuous Compliance Engine's web API includes two endpoints, password-vaults and credential-paths for managing the setup of vaults and credentials.

Setting up a password vault

The POST action on the password-vaults endpoint is used to provide information on the type of vault to be accessed and the location of the server hosting the vault.

You must put certificates and private keys in a single line (one-liner). To convert an existing certificate or private key to one line (from Linux), you can run:

CODE

awk 'NF {sub(/\r/, ""); printf "%s\\n",$0;}' file_name

For a HashiCorp vault, the body of the request will be similar to:

CODE

{
  "name": "HashiVault",
  "vaultType": "HASHICORP",
  "configJson": {
    "host": "123.45.67.89",
    "port": 8200,
    "namespace": "sample/child",
    "authType": "TOKEN",
    "token": "hvs.kvITvwsi4gs"
  },
  "description": "Vault description is optional"
}

Namespaces are only relevant when using the Enterprise version of the HashiCorp product. If this field is specified, it should match the namespace being used on the HashiCorp server.

To use either AppRole or Certificate based authentication, the following substitutions can be made to the above example:

CODE

"authType": "APPROLE",
    "roleId": "your-role-id",
    "secretId": "your-secret"

or

CODE

"authType": "CERTIFICATE",
    "certificate": "-----BEGIN CERTIFICATE-----\nMIa1ZqA=\n-----END CERTIFICATE-----",
    "privateKey": "-----BEGIN RSA PRIVATE KEY-----\nUw9aPq\n-----END RSA PRIVATE KEY-----",
    "roleName": "sampleRole"

For CyberArk, the request body will be similar to:

CODE

{
  "name": "CyberVault",
  "vaultType": "CYBERARK",
  "configJson": {
    "host": "cyberark01.myserver.com",
    "port": 443,
    "appId": "MyApp",
    "authType": "CERTIFICATE",
    "certificate": "-----BEGIN CERTIFICATE-----\nMIa1ZqA=\n-----END CERTIFICATE-----"
    "privateKey": "-----BEGIN PRIVATE KEY-----\nMIa1ZqA=\n-----END PRIVATE KEY-----"
  },
  "description": "Vault description is optional"
}

Setting up a credential path

Credential paths are used to specify the location of the credentials within a password vault.

HashiCorp

The Continuous Compliance Engine currently supports two types of HashiCorp secrets engines: database and key-value-v2.

The request body for a HashiCorp credential path will be similar to:

CODE

{
  "credentialPathName": "HashiCredentialPath",
  "description": "Credential path description is optional",
  "passwordVaultId": 1,
  "credentialParameters": {
    "engineType": "KEY_VALUE_V2",
    "engine": "secret-engine-name",
    "path": "secret-path",
    "usernameKey": "username",
    "passwordKey": "password"
  }
}

Database secrets engines support dynamic secrets by generating database credentials based on configured roles. When using a database secrets engine, set engineType to DATABASE and use role to specify the name of the role to create credentials against.

CODE

"credentialParameters": {
    "engineType": "DATABASE",
    "engine": "database-engine-name",
    "role": "my-role",
    "usernameKey": "username",
    "passwordKey": "password"
  }

CyberArk

The request body for a CyberArk credential path will be similar to:

CODE

{
  "credentialPathName": "CyberCredentialPath",
  "description": "Credential path description is optional",
  "passwordVaultId": 1,
  "credentialParameters": {
    "queryString": "Safe=DevTest;Folder=Root;Object=postgres01"
}

Configuring the database connector

Database connectors can be configured to use a password vault through either the Continuous Compliance Engine UI or the APIs.

UI configuration

When creating or editing a DB2, MariaDB, MSSQL, MySQL, Oracle, PostgreSQL, or Sybase database connector, check the Use Password Vault option and then select the required credential path from the Credential Path dropdown. If the “Test Connection” run succeeds then it is complete.

API configuration

CredentialPathId is an optional field when creating a DB2, MariaDB, MSSQL, MySQL, Oracle, PostgreSQL, or Sybase database connector via the API. Setting this value to the id of an existing credential path object will result in the connector using password vaults to retrieve the credential. As an example:

CODE

{
  "connectorName": "psql-connector",
  "databaseType": "POSTGRES",
  "environmentId": 1,
  "host": "mpv-psql.mydb.co",
  "port": 5432,
  "databaseName": "postgres",
  "schemaName": "public",
  "credentialPathId": 1
}