Vault

Synopsis

Manages credential stores that securely resolve secrets at runtime, so sensitive values never appear in configuration files. DataStream supports four providers: VirtualMetric Vault (built-in encrypted store), Azure Key Vault, CyberArk Central Credential Provider, and HashiCorp Vault.

The Vault is administered through two surfaces:

The Vault page in the web dashboard — covered in the sections below. Secrets created here are synchronized to each Director and Agent and become resolvable in pipeline, device, and target configurations through $secret{id=<numeric-id>} tokens.
The YAML configuration reference — for infrastructure-as-code deployments (see YAML Configuration Reference).

Any string-valued field in a device, target, or other component configuration can reference a secret using a $secret{...} token; DataStream resolves the token at runtime.

Platform Configuration Required

VirtualMetric Vault encrypts secret values at rest using a 32-byte AES-256 key loaded from the credentialstore.key platform configuration value. The service does not start when this key is missing. Set the key once per deployment before enabling the Vault feature.

Accessing the Vault

To open the Vault management interface:

Click the hamburger menu in the top left corner.
Select Organization > Vault.

The page opens with two tabs: Secrets (default) and Provider Configurations. Use Secrets to manage individual credential entries consumed by devices and targets. Use Provider Configurations to manage connections to external vault providers (Azure Key Vault, CyberArk, HashiCorp Vault).

Secrets

A secret is a single credential entry — a password, API key, certificate, or other sensitive value — that devices and targets reference through a $secret{...} token. Each secret is stored by one of the supported providers. Secrets backed by VirtualMetric Vault store the value directly, encrypted at rest using AES-256-GCM with a service-level key. Secrets backed by any other provider store only a reference that DataStream resolves against the external provider at runtime.

Secrets Table

The central table displays essential information for each secret:

Friendly Name - Human-readable identifier. Click to open the secret detail drawer.
Provider - VirtualMetric Vault, CyberArk, Azure Key Vault, or HashiCorp Vault.
Configuration - The provider configuration the secret uses. Blank for VirtualMetric Vault secrets.
Value Format - Single-line or Multi-line.
Assigned Resources - Count of devices, targets, and other components currently referencing this secret.

Controls

Above the table, the Search field filters by friendly name, and the Provider dropdown filters by store type: All, VirtualMetric Vault, CyberArk, Azure Key Vault, or HashiCorp Vault. The Add new secret button appears in the top right corner.

At the bottom of the table, pagination controls let you adjust Items per page (10, 25, or 50; default 25) and navigate between pages.

On the right side of each row, a vertical ellipsis (⋮) opens the Actions dropdown:

Edit - Opens the secret's detail page.
Clone - Duplicates the secret. The new friendly name is prefixed with clone-.
Delete - Prompts for confirmation; see Edit, Clone, and Delete Secrets.

Create a Secret

To add a new secret:

On the Secrets tab, click Add new secret.
Complete the two-step wizard described below.
Click Create on the review step.

Step 1 — General Settings

Friendly Name - Unique, human-readable identifier. Required.
Description - Optional free-text note.
Provider - Select one of: VirtualMetric Vault, CyberArk, Azure Key Vault, HashiCorp Vault. Required.
Configuration - Required when the provider is not VirtualMetric Vault. Select one of the provider configurations defined on the Provider Configurations tab.

note

If you select a provider other than VirtualMetric Vault and no provider configurations exist for that provider, an alert appears and the Next button remains disabled. Create a provider configuration first (see Create a Provider Configuration), then return to this wizard.

Step 2 — Secret Configuration

Value Format - Single-line (compact input, for short credentials like tokens or passwords) or Multi-line (expanded text area, for PEM blocks, JSON payloads, and other long values).
Secret Value (VirtualMetric Vault) - The credential value itself. Stored encrypted.
Reference (CyberArk, Azure Key Vault, HashiCorp Vault) - The provider-specific lookup string that identifies the value inside the external vault. The helper text adjusts to the selected provider. See YAML Configuration Reference for the exact reference grammar of each provider.

Step 3 — Review and Complete Setup

Review the summary of your entries from Steps 1 and 2, then click Create to save the secret. Use Back to return to earlier steps.

info

VirtualMetric Vault stores the secret value itself, encrypted at rest with AES-256-GCM. The encryption key is loaded from the credentialstore.key platform configuration value. All other providers store only the reference; the actual value remains in the external vault and is fetched each time DataStream resolves the token.

Secret Details

Click a secret's Friendly Name to open the detail drawer on the right side of the page. The drawer summarises the secret's provider, configuration, value format, and current assigned-resource count. Click Manage to open the full detail page.

The detail page has three tabs:

General Settings - Friendly Name, Description, and Provider. Click Edit to modify the Friendly Name and Description.
Secret Configuration - Value Format and the stored value or reference. Click Edit to modify.
Activity Logs - Audit trail of all actions performed on this secret.

warning

Provider and Configuration cannot be changed after a secret is created. To move a secret to a different provider or configuration, delete the secret and create a new one. This constraint is enforced in both the UI and the backend API.

Edit, Clone, and Delete Secrets

Edit - Open the detail page (click the Friendly Name, then Manage, or use the row action menu) and click Edit on the General Settings or Secret Configuration tab. Save changes to apply them immediately.

Clone - In the Secrets table, open the row action menu and select Clone. DataStream opens the Create Secret wizard pre-filled with the source secret's values. The Friendly Name is prefixed with clone- and must be changed to a unique value before the new secret can be saved.

Delete - From the table row action menu or the detail page actions, select Delete and confirm.

warning

If a secret is currently assigned to any device, target, or other resource, deletion is blocked. DataStream displays an error modal listing each resource that still references the secret. Remove the secret from every listed resource, then retry the delete operation.

Provider Configurations

A provider configuration is a reusable connection definition for an external vault — the URL, credentials, and options DataStream uses to talk to Azure Key Vault, CyberArk, or HashiCorp Vault. One configuration can back many secrets. VirtualMetric Vault does not appear here because it is built-in and has no external connection to configure.

Provider Configurations Table

The central table displays essential information for each configuration:

Configuration Name - Unique identifier. Click to open the configuration detail drawer.
Provider - CyberArk, Azure Key Vault, or HashiCorp Vault.
Description - Free text, or - when empty.
Assigned Secrets - Count of secrets that reference this configuration.

Controls

Above the table, the Search field filters by configuration name, and the Provider dropdown filters by provider type: All, CyberArk, Azure Key Vault, or HashiCorp Vault. The Add new provider configuration button appears in the top right corner.

Pagination matches the Secrets tab: 10, 25, or 50 items per page (default 25).

note

The Provider filter on this tab excludes VirtualMetric Vault because it is built-in and has no external configuration to manage.

On the right side of each row, the Actions dropdown (⋮) offers:

Edit - Opens the configuration's detail page.
Delete - Prompts for confirmation; see Edit and Delete Provider Configurations.

Unlike the Secrets tab, this tab has no Clone action.

Create a Provider Configuration

To add a new provider configuration:

On the Provider Configurations tab, click Add new provider configuration.
Complete the three-step wizard described below.
Click Create on the review step.

Step 1 — General Settings

Configuration Name - Unique identifier. Required.
Description - Optional free text.
Provider - CyberArk, Azure Key Vault, or HashiCorp Vault. Required. VirtualMetric Vault is not available here.

Step 2 — Provider Configuration

The fields shown depend on the provider selected in Step 1. For the exact field semantics, defaults, and reference-format rules, see YAML Configuration Reference.

CyberArk - URL, Application ID, default Safe, default Folder, timeout, optional mutual TLS (enable toggle plus certificate and key file names), and optional CA certificate file name.
Azure Key Vault - Vault URL, Tenant ID, Client ID, Client Secret. Leave Tenant ID, Client ID, and Client Secret empty to use managed identity.
HashiCorp Vault - URL, Token, Mount path (default secret), KV version (1 or 2, default 2), Namespace (Enterprise only), timeout, optional mutual TLS, and optional CA certificate file name.

note

TLS certificate and CA files referenced by name must exist in the service root directory before the configuration can authenticate successfully.

Step 3 — Review and Complete Setup

Review the summary of your entries from Steps 1 and 2, then click Create to save the configuration. Use Back to return to earlier steps.

Provider Configuration Details

Click a configuration's Configuration Name to open the detail drawer, or use the Edit row action to open the detail page directly.

The detail page has three tabs:

General Settings - Configuration Name, Description, and Provider. Click Edit to modify the name and description.
Provider Configuration - The provider-specific fields from Step 2 of the wizard. Click Edit to modify.
Activity Logs - Audit trail of all actions performed on this configuration.

warning

Provider cannot be changed after a configuration is created. To migrate to a different provider, create a new configuration, reassign dependent secrets, and delete the old configuration. This constraint is enforced in both the UI and the backend API.

Edit and Delete Provider Configurations

Edit - Open the detail page and click Edit on either the General Settings or Provider Configuration tab. Save changes to apply them immediately.

Delete - From the table row action menu or the detail page actions, select Delete and confirm.

warning

If any secret currently references the configuration, deletion is blocked. DataStream displays an error modal listing each secret that must be deleted or reassigned before the configuration can be removed.

Using Vault Secrets in Device and Target Configurations

Once a secret is created, any string-valued configuration field in a device, target, or other component can reference it using a $secret{id=<numeric-id>} token. Because the token resolves at runtime, the underlying credential can be rotated in the Vault page without touching any device or target definition.

The following field categories most commonly consume vault secrets:

Category	Example Fields	Where Used
Username / Password	`username`, `password`	SSH devices, Windows agentless listeners, database targets, HTTP basic-auth targets
Client ID / Client Secret	`client_id`, `client_secret`	Azure targets, OAuth-protected HTTP targets, Entra ID-authenticated devices
API Tokens and Keys	`token`, `api_key`, `bearer_token`	HTTP targets, SaaS connectors, threat-intel feeds
SSH Key Material	`private_key`, `passphrase`	Linux agentless devices, SFTP targets
TLS Material	certificate, key, and CA contents	Any device or target using mutual TLS when certificates are stored as values

Token grammar and the mapping from tokens to credential-store references is documented in Secret Token Syntax below. Per-field usage is documented on each component's own reference page — this section is a map of where secrets apply, not a per-field catalog.

tip

Prefer the $secret{id=<id>} form over $secret{store=...,ref=...} for production configurations. Registry-based IDs let you change the underlying store or reference without editing every component that consumes the secret.

YAML Configuration Reference

The sections below describe how to declare credential stores and secrets directly in YAML. YAML-driven management is the source-of-truth format for the configuration files that DataStream loads at startup; the GUI surfaces the same concepts for interactive administration.

Secret Token Syntax

Any configuration field that accepts a string value can use a secret token instead of a plain-text value. Three token formats are supported:

Format	Description
`$secret{store=<name>,ref=<value>}`	Resolve a secret from a named credential store using the given reference
`$secret{id=<id>}`	Resolve a secret by its ID from the secrets registry
`$env{VAR_NAME}`	Read a value from an environment variable

When DataStream encounters a token, it resolves the value before using it. Plain-text values are passed through unchanged.

Direct store reference — specifies the store name and reference explicitly:

$secret{store=azure-prod,ref=linux-root-password}

ID-based lookup — resolves the store name and reference from the secrets registry:

$secret{id=2142151252151}

The secrets registry entry must contain credential_store and credential_ref properties that map to a configured credential store.

Schema

Credential stores are declared under the credentials: section. The optional secrets: section defines a registry of secret entries that map stable IDs to store/ref pairs for use with $secret{id=...} tokens.

credentials:
  - name: <string>
    type: local | azurevault | cyberark | hashicorpvault
    description: <string>
    status: <boolean>
    properties:
      # provider-specific fields — see sections below

secrets:
  - name: <string>
    id: <numeric>
    description: <string>
    properties:
      credential_store: <string>
      credential_ref: <string>

Credentials

Credential Store

Common fields shared by all provider types:

Field	Required	Default	Description
`name`	Y		Unique credential store identifier
`type`	Y		Provider type: `local`, `azurevault`, `cyberark`, or `hashicorpvault`
`description`	N	-	Optional description

VirtualMetric Vault

Stores credentials directly in the configuration file as key-value pairs under properties. The ref value in a secret token maps to a property key name.

Type: local

Field	Required	Default	Description
`properties.<key>`	N	-	Arbitrary key-value pairs storing secret values directly

Ref format:

Ref	Resolves to
`<property_key>`	Value of the matching property

Azure Key Vault

Fetches secrets from Azure Key Vault using the REST API. Authenticates with client credentials when tenant_id, client_id, and client_secret are provided. Falls back to managed identity when these fields are omitted.

Type: azurevault

Field	Required	Default	Description
`url`	Y		Azure Key Vault URL (must use `https`)
`tenant_id`	N*	-	Azure AD tenant ID
`client_id`	N*	-	Azure AD application (client) ID
`client_secret`	N*	-	Azure AD client secret

* = Optional. When omitted, authentication falls back to managed identity.

Ref format:

Ref	Resolves to
`<secret_name>`	Value of the named secret in Key Vault

CyberArk

Fetches credentials from CyberArk Central Credential Provider (CCP) using the REST API. Authenticates with an Application ID and supports optional mutual TLS for client certificate authentication. A custom CA certificate can be configured independently of mutual TLS for server certificate verification.

Type: cyberark

Field	Required	Default	Description
`url`	Y		CyberArk PVWA base URL (must use `https`)
`app_id`	Y		Application ID registered in CyberArk
`safe`	N	-	Default safe name, used when `ref` omits it
`folder`	N	-	Default folder name, used when `ref` omits it
`timeout`	N	`30`	Request timeout in seconds
`tls.status`	N	`false`	Enable mutual TLS client certificate authentication
`tls.cert_name`	N*	`"cert.pem"`	Client certificate file name
`tls.key_name`	N*	`"key.pem"`	Client private key file name
`ca_name`	N	-	Custom CA certificate file name for server verification

* = Required when tls.status is true.

Ref format:

Ref	Safe	Folder	Object
`Object`	From store config	From store config	`Object`
`Safe/Object`	`Safe`	From store config	`Object`
`Safe/Folder/Object`	`Safe`	`Folder`	`Object`

HashiCorp Vault

Fetches secrets from HashiCorp Vault using the KV secrets engine (v1 or v2). Authenticates with a static Vault token. Supports Vault Enterprise namespaces.

Type: hashicorpvault

Field	Required	Default	Description
`url`	Y		HashiCorp Vault server URL
`token`	Y		Vault authentication token
`mount`	N	`"secret"`	KV secrets engine mount path
`kv_version`	N	`2`	KV engine version: `1` or `2`
`namespace`	N	-	Vault Enterprise namespace
`timeout`	N	`30`	Request timeout in seconds
`tls.status`	N	`false`	Enable mutual TLS client certificate authentication
`tls.cert_name`	N*	`"cert.pem"`	Client certificate file name
`tls.key_name`	N*	`"key.pem"`	Client private key file name
`ca_name`	N	-	Custom CA certificate file name for server verification

* = Required when tls.status is true.

Ref format:

Ref	Behavior
`path/to/secret`	Returns the first field value found in the secret
`path/to/secret#field`	Returns the value of the specified field

note

When using KV v2 (default), the API path automatically includes /data/ between the mount path and the secret path. No manual adjustment is needed.

Secrets Registry

Defines named secret entries under the top-level secrets: section. Each entry maps a stable ID (the entry name) to a target credential store and reference, enabling indirection so that components can use $secret{id=<name>} tokens without hard-coding the store and ref.

Field	Required	Default	Description
`name`	Y		Human-readable secret entry identifier
`id`	Y		Numeric identifier used in `$secret{id=<value>}` tokens
`description`	N	-	Optional description
`properties.credential_store`	Y		Name of a credential store defined in the `credentials:` section
`properties.credential_ref`	Y		Reference passed to the credential store to fetch the value

Resolution Details

Resolution Flow

When DataStream encounters a $secret{...} token in a configuration field, it follows this sequence:

Parse the token to extract either store/ref parameters or an id parameter
If id is provided, look up the credential_store and credential_ref from the secrets registry
Find the named credential store in the credentials configuration
Look up the registered provider for the store's type
Invoke the provider with the ref value to retrieve the secret

Supported Fields

Any string-valued configuration field can use secret tokens. Common use cases include authentication fields in devices, targets, and other components:

username and password — login credentials
private_key and passphrase — SSH key-based authentication
client_secret — OAuth and API credentials
token — API tokens and bearer credentials

TLS Certificate Location

TLS certificate and key files referenced by tls.cert_name, tls.key_name, and ca_name must be placed in the service root directory.

URL Requirements

Azure Key Vault and CyberArk providers require https URLs. Connections using http are rejected.

Examples

VirtualMetric Vault

Storing SSH credentials locally in the configuration...

credentials:
  - name: local-ssh-creds
    type: local
    properties:
      username: admin
      password: s3cur3-p4ss
      private_key: |
        -----BEGIN RSA PRIVATE KEY-----
        MIIEpAIBAAKCAQEA...
        -----END RSA PRIVATE KEY-----

Referencing a value from this store...

$secret{store=local-ssh-creds,ref=password}

Azure Key Vault

Connecting with client credentials...

credentials:
  - name: azure-prod
    type: azurevault
    properties:
      url: https://mycompany-kv.vault.azure.net
      tenant_id: a1b2c3d4-e5f6-7890-abcd-ef1234567890
      client_id: 12345678-abcd-ef01-2345-6789abcdef01
      client_secret: my-client-secret-value

Using managed identity (omit tenant_id, client_id, client_secret)...

credentials:
  - name: azure-managed
    type: azurevault
    properties:
      url: https://mycompany-kv.vault.azure.net

CyberArk

Basic configuration with default safe and folder...

credentials:
  - name: cyberark-prod
    type: cyberark
    properties:
      url: https://cyberark.company.com
      app_id: VirtualMetric
      safe: DevOps
      folder: Root

With mutual TLS and custom CA...

credentials:
  - name: cyberark-secure
    type: cyberark
    properties:
      url: https://cyberark.company.com
      app_id: VirtualMetric
      safe: DevOps
      tls:
        status: true
        cert_name: cyberark-client.pem
        key_name: cyberark-key.pem
      ca_name: cyberark-ca.pem

HashiCorp Vault

KV v2 engine (default)...

credentials:
  - name: hashicorp-prod
    type: hashicorpvault
    properties:
      url: https://vault.company.com
      token: hvs.CAESI...
      mount: secret

KV v1 engine with Enterprise namespace...

credentials:
  - name: hashicorp-legacy
    type: hashicorpvault
    properties:
      url: https://vault.company.com
      token: hvs.CAESI...
      mount: kv-v1
      kv_version: 1
      namespace: admin/production

Secrets Registry

Defining a registry of named secret entries that map to credential stores...

secrets:
  - name: linux-admin-creds
    id: 1001
    description: Production Linux admin credentials
    properties:
      credential_store: cyberark-prod
      credential_ref: DevOps/Root/linux-admin

  - name: api-key
    id: 1002
    description: External API authentication key
    properties:
      credential_store: hashicorp-prod
      credential_ref: api/credentials#api_key

Using Secret Tokens in Configuration

Direct reference — specifies the store and ref inline...

- name: linux-server
  type: linux
  properties:
    address: 192.168.1.100
    username: $secret{store=cyberark-prod,ref=DevOps/Root/linux-admin}
    password: $secret{store=cyberark-prod,ref=DevOps/Root/linux-password}

ID-based lookup — references a registered secret entry by its numeric id...

- name: linux-server
  type: linux
  properties:
    address: 192.168.1.100
    username: $secret{id=1001}
    password: $secret{id=1001}

Mixing secret tokens with environment variables...

- name: api-target
  type: http
  properties:
    url: https://api.example.com
    token: $secret{id=1002}
    proxy_password: $env{PROXY_PASS}

Vault

Synopsis

Accessing the Vault

Secrets

Secrets Table

Controls

Actions Menu

Create a Secret

Secret Details

Edit, Clone, and Delete Secrets

Provider Configurations

Provider Configurations Table

Controls

Actions Menu

Create a Provider Configuration

Provider Configuration Details

Edit and Delete Provider Configurations

Using Vault Secrets in Device and Target Configurations

YAML Configuration Reference

Secret Token Syntax

Schema

Credentials

Credential Store

VirtualMetric Vault

Azure Key Vault

CyberArk

HashiCorp Vault

Secrets Registry

Resolution Details

Resolution Flow

Supported Fields

TLS Certificate Location

URL Requirements

Examples

VirtualMetric Vault

Azure Key Vault

CyberArk

HashiCorp Vault

Secrets Registry

Using Secret Tokens in Configuration

Synopsis​

Accessing the Vault​

Secrets​

Secrets Table​

Controls​

Actions Menu​

Create a Secret​

Secret Details​

Edit, Clone, and Delete Secrets​

Provider Configurations​

Provider Configurations Table​

Controls​

Actions Menu​

Create a Provider Configuration​

Provider Configuration Details​

Edit and Delete Provider Configurations​

Using Vault Secrets in Device and Target Configurations​

YAML Configuration Reference​

Secret Token Syntax​

Schema​

Credentials​

Credential Store​

VirtualMetric Vault​

Azure Key Vault​

CyberArk​

HashiCorp Vault​

Secrets Registry​

Resolution Details​

Resolution Flow​

Supported Fields​

TLS Certificate Location​

URL Requirements​

Examples​

VirtualMetric Vault​

Azure Key Vault​

CyberArk​

HashiCorp Vault​

Secrets Registry​

Using Secret Tokens in Configuration​

Synopsis

Accessing the Vault

Secrets

Secrets Table

Controls

Actions Menu

Create a Secret

Secret Details

Edit, Clone, and Delete Secrets

Provider Configurations

Provider Configurations Table

Controls

Actions Menu

Create a Provider Configuration

Provider Configuration Details

Edit and Delete Provider Configurations

Using Vault Secrets in Device and Target Configurations

YAML Configuration Reference

Secret Token Syntax

Schema

Credentials

Credential Store

VirtualMetric Vault

Azure Key Vault

CyberArk

HashiCorp Vault

Secrets Registry

Resolution Details

Resolution Flow

Supported Fields

TLS Certificate Location

URL Requirements

Examples

VirtualMetric Vault

Azure Key Vault

CyberArk

HashiCorp Vault

Secrets Registry

Using Secret Tokens in Configuration