Skip to main content

Vault

Synopsis​

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

The four external providers — Azure Key Vault, CyberArk, HashiCorp Vault, and AWS Secrets Manager — are gated. Below Enterprise their cards are locked when you choose a provider, and only the built-in VirtualMetric Vault can be selected.

The Vault is administered through two surfaces:

  • The Vault page in the web interface — 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:

  1. Click the hamburger menu in the top left corner.
  2. Select Content Management > 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, AWS Secrets Manager).

note

Vault requires Director 1.10 or later. Both tabs show an alert when any connected Director or cluster is below that version — secrets resolve normally on the Directors that are current, and not at all on the ones that are behind.

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, HashiCorp Vault, or AWS Secrets Manager.
  • 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, HashiCorp Vault, or AWS Secrets Manager. 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.

Actions Menu​

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

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

Create a Secret​

To add a new secret:

  1. On the Secrets tab, click Add new secret.
  2. Complete the three-step wizard described below.
  3. Click Complete setup on the review step.

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, AWS Secrets Manager. 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.

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, AWS Secrets Manager) - The provider-specific lookup string that identifies the value inside the external vault. The helper text adjusts to the selected provider; for AWS Secrets Manager it reads: "The secret's name or ARN. Add #key to read one field of a JSON secret, e.g. prod/amq#password." See YAML Configuration Reference for the exact reference grammar of each provider.

Review and Complete Setup

Review the summary of your entries from the preceding steps, then click Complete setup 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 friendly name, description, provider, configuration, and current assigned-resource count. Click Manage secret to open the full detail page.

The detail page has three tabs:

  • General Settings - Friendly Name, Description, and Provider. Click Manage secret details to modify the Friendly Name and Description.
  • Secret Configuration - Value Format and the stored value or reference. Click Manage secret configuration 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 secret, or use the Manage secret row action) and click Manage secret details on the General Settings tab or Manage secret configuration on the Secret Configuration tab. Save changes to apply them immediately.

Clone - In the Secrets table, open the row action menu and select Clone secret. 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 secret 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, HashiCorp Vault, or AWS Secrets Manager. 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, HashiCorp Vault, or AWS Secrets Manager.
  • 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, HashiCorp Vault, or AWS Secrets Manager. 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.

Actions Menu​

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

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

Create a Provider Configuration​

To add a new provider configuration:

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

General Settings

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

Provider Configuration

The fields shown depend on the provider selected under General Settings. 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, a Managed Identity toggle, and — when it is off — Tenant ID, Client ID and Client Secret. Turning the toggle on is what selects managed-identity authentication in the interface; it clears the three credential fields. In YAML there is no toggle: omitting all three fields is what selects 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.

  • AWS Secrets Manager - Three sections:

    • Connection - Region (required), Connection Timeout (default 30 seconds), and Cache TTL (default 300 seconds).
    • Authentication - A Credential source choice, then the optional Role ARN (the IAM role to assume through STS) and External ID (sent with the role ARN when the role's trust policy requires one). Default chain (instance profile, IRSA) takes no credentials, and shows a warning that it resolves on Directors only, because rule actions read secrets on the platform and need an access key — see the platform-reads note under AWS Secrets Manager. Access key shows Access key ID, Secret access key, and Session token (optional, for temporary credentials).
    • Advanced - Endpoint, for a VPC endpoint. Must be an https URL; leave it empty to use the region's public endpoint.

    The credential source is a choice in the interface only and is not saved. Default chain writes no key or secret; Access key writes key, secret, and session. A saved store with a key or secret reopens with Access key selected.

note

TLS certificate and CA material given as a file name must exist in the service root directory before the configuration can authenticate successfully.

Review and Complete Setup

Review the summary of your entries from the preceding steps, then click Complete setup 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 Manage configuration row action to open the detail page directly.

The detail page has three tabs:

  • General Settings - Configuration Name, Description, and Provider. Click Manage configuration details to modify the name and description.
  • Provider Configuration - The provider-specific fields entered during creation. Click Manage provider configuration 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 Manage configuration details on the General Settings tab or Manage provider configuration on the Provider Configuration tab. Save changes to apply them immediately.

Delete - From the table row action menu or the detail page actions, select Delete configuration 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.

A value fetched from an external provider is held for that store's cache_ttl — five minutes by default. Rotating the secret in the backing vault without changing the store definition therefore takes effect only once the cached value expires. Set the store's cache_ttl to 0 where a rotation has to take effect immediately.

The following field categories most commonly consume vault secrets:

CategoryExample FieldsWhere Used
Username / Passwordusername, passwordSSH devices, Windows agentless listeners, database targets, HTTP basic-auth targets
Client ID / Client Secretclient_id, client_secretAzure targets, OAuth-protected HTTP targets, Entra ID-authenticated devices
API Tokens and Keystoken, api_key, bearer_tokenHTTP targets, SaaS connectors, threat-intel feeds
SSH Key Materialprivate_key, passphraseLinux agentless devices, SFTP targets
TLS Materialcertificate, key, and CA contentsAny 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:

FormatDescription
$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 | awssecretsmanager
    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:

FieldRequiredDefaultDescription
nameYUnique credential store identifier
typeYProvider type: local, azurevault, cyberark, hashicorpvault, or awssecretsmanager
descriptionN-Optional description
cache_ttlN300How long a fetched secret is held in memory, in seconds. 0 disables caching for this store

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

FieldRequiredDefaultDescription
properties.<key>N-Arbitrary key-value pairs storing secret values directly

Ref format:

RefResolves 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

FieldRequiredDefaultDescription
urlYAzure Key Vault URL (must use https)
tenant_idN*-Azure AD tenant ID
client_idN*-Azure AD application (client) ID
client_secretN*-Azure AD client secret
timeoutN30Request timeout in seconds

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

Ref format:

RefResolves 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

FieldRequiredDefaultDescription
urlYCyberArk PVWA base URL (must use https)
app_idYApplication ID registered in CyberArk
safeN-Default safe name, used when ref omits it
folderN-Default folder name, used when ref omits it
timeoutN30Request timeout in seconds
tls.statusNfalseEnable mutual TLS client certificate authentication
tls.cert_nameN*"cert.pem"Client certificate file name
tls.key_nameN*"key.pem"Client private key file name
ca_nameN-Custom CA certificate file name for server verification

* = Required when tls.status is true.

Ref format:

RefSafeFolderObject
ObjectFrom store configFrom store configObject
Safe/ObjectSafeFrom store configObject
Safe/Folder/ObjectSafeFolderObject

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

FieldRequiredDefaultDescription
urlYHashiCorp Vault server URL
tokenYVault authentication token
mountN"secret"KV secrets engine mount path
kv_versionN2KV engine version: 1 or 2
namespaceN-Vault Enterprise namespace
timeoutN30Request timeout in seconds
tls.statusNfalseEnable mutual TLS client certificate authentication
tls.cert_nameN*"cert.pem"Client certificate file name
tls.key_nameN*"key.pem"Client private key file name
ca_nameN-Custom CA certificate file name for server verification

* = Required when tls.status is true.

Ref format:

RefBehavior
path/to/secretReturns the value when the secret holds exactly one field. A secret with more than one field is an error asking you to name the field with #field
path/to/secret#fieldReturns 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.

AWS Secrets Manager​

Fetches a secret's current value (the AWSCURRENT version stage) from AWS Secrets Manager. The store only reads: it never writes or rotates secrets, and it does not read Systems Manager Parameter Store.

Type: awssecretsmanager

FieldRequiredDefaultDescription
regionYAWS region of the secret, e.g. eu-west-1
keyN*-Access key ID. Accepts plain text, ${ENV} or $secret{...}
secretN*-Secret access key. Same forms as key
sessionN-Session token, for temporary credentials. Used only with key and secret
role_arnN-IAM role assumed through STS before reading
external_idN-External ID sent when assuming role_arn
endpointN-Secrets Manager endpoint override, e.g. a VPC interface endpoint. Must use https. Applies to Secrets Manager only; STS keeps its regional endpoint
timeoutN30Request timeout in seconds, for the whole lookup including STS

* = Optional. See the credential resolution order below.

Credential resolution, in precedence order:

ConfigCredentials used (Director)
key and secret setThat static key, plus session if set
Either one missingThe AWS default chain: environment, shared config, IRSA / web identity, then the instance profile
role_arn setThe identity above assumes role_arn (with external_id), and the secret is read as that role
note

The platform's own reads of a store — for example, secrets used by rule actions — never use the AWS default chain. They read only with the store's own key and secret, optionally assuming role_arn with them. A store without key and secret works on Directors (instance profile, IRSA) but is refused with a configuration error for platform-side reads, because the platform's ambient AWS identity belongs to the platform, not to the tenant.

Ref format:

RefResolves to
<secret-name> or <full secret ARN>The whole SecretString
<name or ARN>#<json-key>The SecretString parsed as a JSON object, and that key's value
  • A #json-key value that is a string is returned as-is. A number or a boolean is returned as its JSON text, e.g. 5432 or true. An object, an array or null is refused.
  • A missing key is an error that names the key, never the value. The same applies when #json-key is given and the SecretString is not a JSON object.
  • A secret that holds only SecretBinary is refused: binary secrets are not supported.
  • An empty value is an error.

Failures: a secret that is not found, access denied on secretsmanager:GetSecretValue, a KMS decrypt failure, and STS refusing role_arn (trust policy or external ID) are permanent — they fail again until fixed. Throttling and network errors are transient. No error or log line carries the secret's value.

Required IAM permissions, for the identity the secret is read as:

  • secretsmanager:GetSecretValue on the secret. Use arn:aws:secretsmanager:REGION:ACCOUNT_ID:secret:NAME-* as the resource, because AWS appends six random characters to a secret's ARN.
  • kms:Decrypt on the key, only when the secret is encrypted with a customer-managed KMS key. The default aws/secretsmanager key needs no grant.
  • sts:AssumeRole on role_arn, only when it is set.

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.

FieldRequiredDefaultDescription
nameYHuman-readable secret entry identifier
idYNumeric identifier used in $secret{id=<value>} tokens
descriptionN-Optional description
properties.credential_storeYName of a credential store defined in the credentials: section
properties.credential_refYReference 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:

  1. Parse the token to extract either store/ref parameters or an id parameter
  2. If id is provided, look up the credential_store and credential_ref from the secrets registry
  3. Find the named credential store in the credentials configuration
  4. Look up the registered provider for the store's type
  5. 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​

When tls.cert_name, tls.key_name, or ca_name is given as a file name, the file must be placed in the service root directory. These fields also accept an in-root absolute path or inline PEM content.

URL Requirements​

Azure Key Vault and CyberArk providers require https URLs. Connections using http are rejected. An AWS Secrets Manager endpoint override must also use https.

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

AWS Secrets Manager​

Assuming a role with the Director's default credential chain...

credentials:
  - name: aws-prod
    type: awssecretsmanager
    properties:
      region: eu-west-1
      role_arn: arn:aws:iam::123456789012:role/vmetric-secrets-reader
      external_id: ${AWS_EXTERNAL_ID}

Reading the password key of a JSON secret...

password: $secret{store=aws-prod,ref=prod/db#password}

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}