Integrating the Password Vault With the TA Master

Beginning with Tidal Automation Version 6.5.7, TA supports the integration of HashiCorp Password Vault with the TA Master. The Password Vault stores runtime user credentials.

When the TA Master starts, a request is made to the Password Vault for the runtime user credentials. These credentials are then cached in the TA Master’s memory. When the TA Master establishes a connection with an Agent or Adapter, it performs a lookup in the TA Master’s memory. The TA Master cache is refreshed with the latest runtime user credentials from the Password Vault at specific configurable intervals. The default is every 5 minutes.

Setting Up the Password Vault

Note: For information on the Password Vault setup, see CLI quick start.

Integrating the Password Vault with the TA Master

Follow these steps to integrate the Password Vault with the TA Master:

  • Enabling the Password Vault’s Key-Value Secrets Engine to access the TA path.

  • Authenticating TA to interact with the Password Vault.

Enabling the Password Vault’s Key-Value Secrets Engine to access the TA Path

The first step in integrating the Password Vault with TA is to enable the Key Value (KV) Secrets Engine of the Password Vault to access the TA path.

To enable the KV Secrets Engine to access the TA path:

  1. Click the Secrets tab in the Password Vault UI.

  1. Click Enable New Engine from the Secrets Engine page.

  1. Choose KV (datastore) under the Generic section from the Enable a Secrets Engine dashboard.

  1. Perform these steps on the Enable KV Secrets Engine page:

    • Change the Path to “tidal”.

    • Choose the Version as “2”.

    • Click Enable Engine.

      The KV Secret Engine is now mounted to the path "tidal".

  1. Click “tidal” on the Secrets Engine page.

  2. Click Create Secret to create a new secret in the “tidal” secret engine. Perform these steps on the Create Secret page:

    • Enter the Path for this secret as “runtimeusers”.

      Note: The secret must be named "runtimeusers".

    • Enter the username and password of the TA runtime user.

    • Click Add.

      The secret lives at the path “/tidal/data/runtimeusers”.

Secrets for a runtime user must have this format: 

{runtimeuser}/password

Example: tidalrunuser/password1

Secrets for a Service user must have this format: 

{runtimeuser}-{ServiceGUID}/password

Example: tidalrunuser-{737E2AFA-BF13-4968-9AB1-1AAB0E295A9D}-AmazonEC2Password

Note: When the Password Vault is first initialized, runtime user password credentials will be exported from the database and imported into the Password Vault when the TA Master starts up. If, in the future, the Password Vault is turned off, the credentials will be placed back in the database. Any new credentials entered in TA will not be in the database but will be stored in the Password Vault when Write mode is enabled.

Authenticating TA to interact with the Password Vault

The next step in integrating the Password Vault with TA is to authenticate TA to access and interact with it.

Prerequisite: This step can be performed after initializing the Password Vault.

When a vault is initialized, a root token is provided to allow interaction with the password vault. This token should not be used for a production environment. Instead, the root token can be used to enable AppRole authentication. For more information about enabling AppRole authentication, see AppRole pull authentication.

Note: Approle authentication allows for the generation of periodic tokens. Periodic tokens have a TTL (time-to-live) but do not have a maximum TTL, so these tokens may live for an infinite duration of time as long as they are renewed within their TTL. This is useful for long-running services such as Tidal Automation that do not want to handle regenerating a token. If a periodic token is not handled correctly, the token will expire, and the Master will no longer be able to read from the Password Vault.

To give permissions on the new “tidal” path created in Enabling the Password Vault’s Key Value Secrets Engine to access the TA Path, create a new policy in the Password Vault as provided in these steps:

  1. Navigate to the Policies tab in the Password Vault UI.

  1. Click Create ACL policy on the ACL Policies page.

  1. Enter the Name as “tidal-policy”.

  1. Enter or copy and paste the policy details in the Policy field:

path "tidal/*"
{
capabilities = ["create", "read", "update", "list", "sudo"]
}
path "auth/token/*" { capabilities = ["sudo"]
}

  1. Click Create policy.

Configuring the TA Master for Using the Password Vault

The TA Master must be updated with a new master.props values that will be used for connecting with the vault. These values establish a connection with the vault and load the runtime user credentials into the Master’s memory for lookups. For more information about the parameters added to master.props file concerning the Password Vault integration, see Configuring the Master Parameters (master.props).

The Password Vault secrets are stored in key-value pairs on a file system path so the TA Master can quickly read the runtime user credentials. The name of the secret must be called “runtimeusers”. The path to the secret is configurable in the “Path” parameter in the master.props file.

Unlike the prior versions, to store the Secret -Id in the sysval, users must create a file in the configuration called secretid and paste the secretid in the file. The Master reads this file, uses the secretid in the file to create the sysval ID 192, and then deletes the file.

Note: Do not use any file format extensions while creating the file.

Note: If OpenJDK is used for configuration and the exception “javax.net.ssl.SSLHandshakeException: extension (5) should not be presented in certificate_request” is thrown, add the parameter in the JVMARGS of the master.props file.

Example: JVMARGS=-Xms2048m -Xmx2048m -Djdk.tls.client.protocols=TLSv1.2