Close
logodocs

Add Resources with Secret Store Authentication

This feature is currently in closed-access beta. Functionality and documentation may change.

You can use credentials kept in Secret Stores to set up any type of resource in strongDM.

Add Resources using Secret Stores

When adding a new resource, after you've selected a Secret Store option, all fields that it can reference contain "/path/key" in their label. These typically consist of a username and password, but can include other credentials such as keys or tokens.

See the below example when adding a Datasource:

Datasource - Secret Stores
Datasource - Secret Stores

Learn more by reading the Configure a Resource section of Secret Stores Settings.

Add SSH Servers with Secret Stores

SSH resources support three different types of authentication with Secret Stores: Certificate-Based, Public Key, and Customer-Managed Key.

Certificate-Based Authentication

In the setup for a Certificate-Based SSH resource, you can use a username that is kept in a Secret Store. The certificate authority and the public key generated by it will continue to be managed by strongDM.

CA-Based - Secret Stores
CA-Based - Secret Stores

Public Key Authentication

In the setup for a Public Key SSH resource, you can use a username that is kept in a Secret Store. The private key and the public key generated by it will continue to be managed by strongDM.

Public Key - Secret Stores
Public Key - Secret Stores

Customer-Managed Key Authentication

Customer-Managed - Secret Stores
Customer-Managed - Secret Stores

In the setup for a Customer-Managed Key SSH resource, you can use both a username and private key that are kept in a Secret Store. No keys will be stored or managed by strongDM. To set up an SSH Server with a Customer-Managed Key using Secret Stores, follow these steps:

  1. Retrieve the key from whatever tool you used to create it.

  2. Encode the secret key in Base64 before adding it to your secret storage tool. You can do this on Linux or macOS by running cat <your-private-key-file> | base64.

  3. Store this Base64-encoded string as a plaintext secret (or a string value in a JSON key-value pair) in your secrets storage tool. Then, add your new Server resource in strongDM. Choose "Customer-Managed Key" as the type, select your Secret Store type, and supply the path to the credential that is stored in your secret storage tool. Specify that it is already Base64-encoded by appending &encoding=base64 to the credential's path. For example, if you define a secret in your secret storage tool as "sdm/server", and set a key named "myKey" with the Base64-encoded value, you can enter this string into the Admin UI field when setting up your server: sdm/server?key=myKey&encoding=base64.

Add Kubernetes Clusters with Secret Stores

To set up a Kubernetes Cluster using Secret Stores, follow these steps:

For non-certificate secrets (such as username and password with the Kubernetes HTTP Basic Auth cluster type) that you would like to store in Secret Stores, Base64-encoding is not necessary. The instructions below about encoding secrets apply specifically to certificates.

  1. Retrieve the CA and client certificate data from your provider. Typically, this is already written into your local KUBECONFIG file when configuring direct access. The KUBECONFIG file may point to a filename. If so, use the content of this file in the following steps.

  2. This data is usually already Base64-encoded. If not Base64-encoded, the string will start with text like "-----BEGIN CERTIFICATE-----". In this case, you must Base64-encode it before storing it in your secret storage tool. You can do this on Linux or macOS by running echo "your-certificate-string-here" | base64.

  3. Store this Base64-encoded string as a plaintext secret (or a string value in a JSON key-value pair) in your secrets storage tool. Then, add your new Kubernetes resource in strongDM. Choose the cluster type, select your Secret Store type, and supply the path to the credential that is stored in your secret storage tool. Specify that it is already Base64-encoded by appending &encoding=base64 to the credential's path. For example, if you define a secret in your secret storage tool as "sdm/server", and set a credential named "CA" with the Base64-encoded value, you can enter this string into the Admin UI field when setting up your Kubernetes cluster: sdm/server?key=CA&encoding=base64.