> For the complete documentation index, see [llms.txt](https://docs.strongdm.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.strongdm.com/admin/access/secret-stores/delinea-devops-secrets-vault.md). # 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](/admin/access/secret-stores.md). 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](https://docs.delinea.com/online-help/devops-secrets-vault/usage/cli-ref/client.htm) 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](/admin/access/secret-stores.md#provision-node-credentials) and [Configure your gateway or relay](#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: ```sh 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](/admin/access/secret-stores.md#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](#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](#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 `) | | `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](#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](#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
PropertyRequirementDescription
Display NameRequiredName for this secret store integration that is displayed throughout StrongDM
TypeRequiredType of secret store; select Delinea DevOps Secrets Vault (DSV)
TenantRequiredYour DSV tenant name (for example, example for https://example.secretsvaultcloud.com)
TLDOptionalTop-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](#authentication-to-dsv) and [Configure your gateway or relay](#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
PropertyDescription
Secret StoreType 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)
{% hint style="info" %} 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. {% endhint %} {% hint style="info" %} 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`). {% endhint %} ## 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. {% code overflow="wrap" %} ```shellscript # 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 ``` {% endcode %} 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](#configure-your-gateway-or-relay). ### Add a Delinea DSV Secret Store in Terraform ```hcl # 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](https://registry.terraform.io/providers/strongdm/sdm/latest/docs). ### 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](https://pkg.go.dev/github.com/strongdm/strongdm-sdk-go), [strongdm-sdk-go](https://github.com/strongdm/strongdm-sdk-go), [Go SDK Examples](https://github.com/strongdm/strongdm-sdk-go/tree/main/examples) * Java: [javadoc](https://javadoc.io/doc/com.strongdm/strongdm-sdk-java), [strongdm-sdk-java](https://github.com/strongdm/strongdm-sdk-java), [Java SDK Examples](https://github.com/strongdm/strongdm-sdk-java/tree/main/examples) * Python: [pdocs](https://strongdm.github.io/strongdm-sdk-python/), [strongdm-sdk-python](https://github.com/strongdm/strongdm-sdk-python), [Python SDK Examples](https://github.com/strongdm/strongdm-sdk-python/tree/main/examples) * Ruby: [RubyDoc](https://www.rubydoc.info/gems/strongdm), [strongdm-sdk-ruby](https://github.com/strongdm/strongdm-sdk-ruby), [Ruby SDK Examples](https://github.com/strongdm/strongdm-sdk-ruby/tree/main/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](/admin/access/secret-stores.md): How StrongDM secret store integrations work in general * [Delinea Secret Server](/admin/access/secret-stores/delinea-secret-server.md): StrongDM's other Delinea secret store integration, which this DSV integration's credential-handling model follows * [DevOps Secrets Vault documentation](https://docs.delinea.com/online-help/devops-secrets-vault/): Delinea's DSV product documentation * [Client](https://docs.delinea.com/online-help/devops-secrets-vault/usage/cli-ref/client.htm): Delinea's documentation on creating DSV roles and client credentials * [Architecture and Security](https://docs.delinea.com/online-help/devops-secrets-vault/concepts/arch-and-security/index.htm): Delinea's documentation on DSV authentication methods and token TTLs --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.strongdm.com/admin/access/secret-stores/delinea-devops-secrets-vault.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.