Delinea DevOps Secrets Vault

Overview

Delinea DevOps Secrets Vault (DSV) is a cloud-native secrets management service for storing and accessing secrets such as passwords, API keys, SSH keys, certificates, and tokens. This guide describes how to integrate DSV with StrongDM as a secret store, and how to authenticate to DSV using static client credentials.

Secret store integrations allow you to use your existing third-party secret stores with StrongDM. Your credentials are stored in a service that is controlled by you, and those credentials are never transmitted to StrongDM in any form. If you would like to learn more about how the Secret Store integration works and why you might wish to use it, please read the Secret Stores Reference.

With this integration, StrongDM reads an existing secret from a path you specify in DSV and injects it into the brokered connection at connect time. The credential is fetched by your gateway or relay and is never stored on, or transmitted to, the StrongDM control plane.

Limitations

The following are not supported by this integration:

• Authentication methods other than client credentials: DSV also supports username/password and cloud-identity (for example, AWS IAM, Azure MSI, or GCP) authentication, but only OAuth client credentials (client ID/client Secret) authentication is currently supported for the StrongDM integration.
• Dynamic secrets: StrongDM reads whatever value currently exists at the configured path. DSV's dynamic secrets capability (generating short-lived, on-demand credentials) is not yet supported.
• Writing credentials to DSV: The secret must already exist at the configured path in DSV; StrongDM only reads secrets, it does not create or update them.
• Automatic rotation of the DSV Client Secret: If you rotate the client secret in DSV, you must also update it wherever it is configured for your gateway or relay. If the credential is provisioned to the node, run sdm nodesecrets set DSV_CLIENT_SECRET again to update it, and then restart the service.

Prerequisites

The following items are required to integrate DSV with StrongDM:

• StrongDM account with the Administrator permission level
• Healthy StrongDM gateway or relay to allow authentication with DSV
• DSV tenant, with at least one secret stored at a known path
• DSV role with read access to the secret path(s) you intend to use, and a client ID/client secret pair generated for that role (see Client in the Delinea documentation)
• Correct path(s) to the secret(s) stored in DSV

Authentication to DSV

StrongDM authenticates to your DSV tenant using OAuth 2.0 client credentials. Your gateway or relay presents a DSV client ID and client secret and receives a short-lived bearer access token (grant_type=client_credentials), which it uses to call the DSV secrets API. StrongDM automatically refreshes the access token before it expires; access tokens issued by DSV have a time-to-live (TTL) of up to one hour.

Client credentials authentication is the only authentication mode supported. The client ID and client secret are tied to a role in DSV, and that role's policies determine which secret paths StrongDM is able to read; grant the role read-only access to only the paths it needs.

The client secret is treated as sensitive material: it is not displayed or stored in cleartext in the Admin UI, and it is never typed into the control plane. Supply both the client ID and the client secret to your gateway or relay as node credentials, either provisioned to the node with sdm nodesecrets set, or set as environment variables. See Provision Node Credentials and Configure your gateway or relay below. The tenant name and TLD are set in the Admin UI.

Configure your gateway or relay

To allow communication with DSV, StrongDM needs to know what credentials to use. You can pass credentials by either provisioning credentials to the StrongDM node (gateway, relay, or proxy worker), or you can configure your gateway or relay environment with properties as environment variables.

Node credentials provisioning method (recommended)

You can provision DSV_CLIENT_ID and DSV_CLIENT_SECRET to the node instead of setting them as environment variables. On the gateway or relay, run:

sdm nodesecrets set DSV_CLIENT_ID
sdm nodesecrets set DSV_CLIENT_SECRET

Each value is entered at a hidden prompt and never appears in the environment file. A provisioned credential takes precedence over an environment variable of the same name. You must still restart the service.

Environment variables remain fully supported and no migration is required. See Provision Node Credentials for container support and how to migrate existing environment variables.

Environment variables method

Use the following steps to configure your gateway or relay environment with properties as environment variables.

1. Open the environment file for editing. The default location is /etc/sysconfig/sdm-proxy for gateways and relays, or /etc/sysconfig/sdm-worker for proxy clusters.
2. Add or edit the environment variables supported by DSV. The tenant name and TLD are configured in the Admin UI only; there are no corresponding environment variables. See Create a secret store in StrongDM.
3. Restart the service. If your system uses systemd, the command is sudo systemctl restart sdm-proxy for gateways and relays, or sudo systemctl restart sdm-worker for proxy clusters.

Environment Variables Supported by DSV

Environment variable	Requirement	Description
DSV_CLIENT_ID	Required	Client ID that StrongDM uses to authenticate to DSV; Generated in DSV for a role (for example, with dsv client create --role <role>)
DSV_CLIENT_SECRET	Required	Client secret associated with DSV_CLIENT_ID; treat this the same as any other sensitive credential by either provisioning it with sdm nodesecrets set DSV_CLIENT_SECRET, or setting it as an environment variable; see Authentication to DSV

Create a secret store in StrongDM

1. Log in to the StrongDM Admin UI.
2. Go to Settings > Secrets Management > Secret Stores tab.
3. Click Add secret store.
4. On the Add Secret Store form that displays, set all the required secret store properties.
5. Click Create secret store.

If you have configured the relay or gateway correctly for DSV access and authorization, you will see the green online indicator.

Secret store properties

Property	Requirement	Description
Display Name	Required	Name for this secret store integration that is displayed throughout StrongDM
Type	Required	Type of secret store; select Delinea DevOps Secrets Vault (DSV)
Tenant	Required	Your DSV tenant name (for example, example for https://example.secretsvaultcloud.com)
TLD	Optional	Top-level domain that specifies the geographic region or domain extension for your Delinea tenant; possible values are .com, .eu, .com.au, .ca, or .sg; defaults to .com

Neither the client ID nor the client secret is entered in the Admin UI. Both are supplied to the gateway or relay as described in the Authentication to DSV and Configure your gateway or relay sections of this guide.

Connect to a StrongDM Resource

Now that you have set up the secret store integration, you can use the DSV secret store to connect to different StrongDM resources.

1. In the Admin UI, go to Resources > Managed Resources.
2. Click Add Resource.
3. On the form that displays, set the properties for your resource, including the secret store properties.
4. When all required fields are complete, click Create.

When the resource is ready, the Health icon indicates a positive, green status.

DSV properties

Property	Description
Secret Store	Type of secret store; select Delinea DevOps Secrets Vault (DSV)
Username (path)	Path to your secret in the format <PATH>?key=<FIELD>, where <PATH> is the path to the secret in DSV and <FIELD> is the name of the field in the secret's data object that holds the username (for example, us-east:server02?key=username)
Password (path)	Path to your secret in the format <PATH>?key=<FIELD>, where <PATH> is the path to the secret in DSV and <FIELD> is the name of the field in the secret's data object that holds the password (for example, us-east:server02?key=password)

DSV stores paths in colon-separated form internally (for example, us-east:server02), but StrongDM accepts either colons or slashes. Both us-east:server02?key=username and us-east/server02?key=username resolve to the same secret, so use whichever matches your convention.

DSV secrets store their values in a data object that can hold multiple key/value fields (for example, username and password on the same secret); the ?key= parameter selects which field to use. It is preferred that certificates be Base64-encoded. If the secret you are storing is a certificate, Base64-encode it, then append &encoding=base64 to the path (for example, us-east:server02?key=certificate&encoding=base64).

Additional Information

In addition to the Admin UI, the DSV secret store can be created, updated, and deleted using the CLI, Terraform provider, and SDKs.

Add a Delinea DSV Secret Store in the CLI

To add a Delinea DSV secret store in the CLI instead of the Admin UI, use the sdm admin secretstores create command.

# Create Delinea DSV secret store
sdm admin secretstores create delineaDSV --name="Example DSV" --tenant="example"

# Create a Postgres datasource that uses the Delinea DSV secret store
sdm admin resources create postgres --name="Example Postgres" --hostname="db.example.com" --port=5432 --secret-store-id="se-e1b2" --username-path="us-east:server02?key=username" --password-path="us-east:server02?key=password"

# Run secret store healthcheck
sdm admin secretstores healthcheck se-e1b2

# Check that the secret store is reachable
sdm admin secretstores status

As with the Admin UI, the client secret is not passed as a CLI flag; it must be supplied to the node as described in Configure your gateway or relay.

Add a Delinea DSV Secret Store in Terraform

# Install StrongDM provider
terraform {
  required_providers {
    sdm = {
      source  = "strongdm/sdm"
      version = "~> 18.0"
    }
  }
}

# Configure StrongDM provider
provider "sdm" {
  # Add API access key and secret key from Admin UI
  api_access_key = "njjSn...5hM"
  api_secret_key = "ziG...="
}

# Create a Delinea DSV secret store
resource "sdm_secret_store" "example-dsv" {
  delinea_dsv_store {
    name   = "Example DSV"
    tenant = "example"
    # tld  = "com"   # optional; defaults to "com"
  }
}

# Create a Postgres datasource that uses the Delinea DSV secret store
resource "sdm_resource" "example-postgres" {
  postgres {
    name            = "Example Postgres"
    hostname        = "db.example.com"
    port            = 5432
    secret_store_id = sdm_secret_store.example-dsv.id
    username_path   = "us-east:server02?key=username"
    password_path   = "us-east:server02?key=password"
  }
}

For additional information, see the Terraform provider documentation.

Use the SDKs

In addition to the Admin UI, CLI, and Terraform, you may add the DSV secret store with any of the following SDK options: Go, Java, Python, and Ruby.

Please see the following references for more information and examples.

• Go: pkg.go.dev, strongdm-sdk-go, Go SDK Examples
• Java: javadoc, strongdm-sdk-java, Java SDK Examples
• Python: pdocs, strongdm-sdk-python, Python SDK Examples
• Ruby: RubyDoc, strongdm-sdk-ruby, Ruby SDK Examples

Health check and diagnostics

Once you've configured your gateway or relay to authenticate to DSV, you can check the secret store's health on the Diagnostics tab for that secret store in the Admin UI. The diagnostics panel indicates whether credentials are available, and details any errors encountered while authenticating to DSV or fetching a secret. If the secret store is down or unreachable, resources using it will be reported as unhealthy, though existing, already-authenticated connections will persist.

Related documentation

• Secret Stores Reference: How StrongDM secret store integrations work in general
• Delinea Secret Server: StrongDM's other Delinea secret store integration, which this DSV integration's credential-handling model follows
• DevOps Secrets Vault documentation: Delinea's DSV product documentation
• Client: Delinea's documentation on creating DSV roles and client credentials
• Architecture and Security: Delinea's documentation on DSV authentication methods and token TTLs