Credential Vault Integration for the LM Collector

The Credential Vault Integration for the LM Collector makes it possible for users to store and manage sensitive information (including credentials and secrets for hosts, devices, services, and so on) in an external credential vault. Currently only CyberArk is available, with more vault solutions to be added in future releases.

Highlights of this integration include:

• Support for multiple vault solutions.
• Support for multiple CyberArk Safes.
• Support for SSL-enabled traffic.

Collector configurations

The following table lists the configuration properties to set in the Collector agent.conf.

Property	Description	Default
vault.bypass	The boolean property is used to bypass the Vault API. If the value for the property is true, the Vault API calls won’t happen. If the property is set with value false, the vault API would be called.	true
vault.credentials.cache.expirationtime	The property specifies the integer value in minutes for the expiry of the credential in the Vault cache. After this time, the credentials in the Vault cache will be expired and needs to be re-fetched from the Vault.	60

Vault properties

Vault properties, such as Vault Metadata and Vault Keys, can be configured at the device or device group level for the Collector.

Note: CyberArk does not allow special characters, such as \ / : * ? ” < > <tab>, to be used in Safe names and object names.

Vault Metadata

The following table lists the Vault Metadata properties, which includes the type of Vault, the Vault URL, Request Headers, and so on.

Property	Description
vault.meta.url	The URL of the vault. This URL should contain the folder and application ID only.
vault.meta.safe	If vault.meta.type is CyberArk, you can specify a Safe. Although a Collector can include many Safes, each device can have only one Safe.
vault.meta.type	The type of vault. Currently, only CyberArk is supported for the Collector.
vault.meta.header	The headers required for HTTP Get Request. The value for this custom property would be the header separated with & and the header key value separated with = as shown in the below example: vault.meta.header – Content-Type=application/json&Accept-Encoding=gzip, deflate, br
vault.meta.keystore.type	The type of the key store. If this is not specified, the default type for the key store is JKS.
vault.meta.keystore.path	The path to the keystore file on the Collector.
vault.meta.keystore.pass	The password for the keystore file on the Collector.

Note: If you are using a CyberArk Root CA trust certificate, it should be imported into the Collector trust store.

Vault Keys

Vault keys need to be specified at the device level with suffix .lmvault. For example, ssh.user information should have the key specified as ssh.user.lmvault.

Property	Description
.lmvault	The custom property for which value should be retrieved from the Vault must be specified at the device level by adding suffix .lmvault. The value of such property would be the path of the key in the Vault. For example: ssh.user.lmvault = ssh\ssh.user
.lmvault : Multi-Safe	The multi-Safe approach allows fetching the values for lmvault properties from different safes within the Vault. The LM vault property value should be specified in the format safe:path. For example, the property referring to the safe sshcreds and object path as ssh\ssh.user can be specified as: ssh.user.lmvault = sshcreds:ssh\ssh.user The Safe specified at the property level would override the value specified at the device level through the “vault.meta.safe” property.