Node Credential Storage With StrongDM

Node credential storage with StrongDM lets you provide credentials through the node secret store instead of environment variables.

Relays and workers use credentials (for example, a Delinea Secret Server password or a HashiCorp Vault token) to reach your secret stores. Node credential storage with StrongDM allows you to provide credentials through the StrongDM node secret store instead of environment variables, so they no longer need to appear in service configuration files.

You provide each value once (at a hidden prompt, from a pipe, or from a file), and afterward, only the key name appears in the CLI output.

This article describes which credentials may be provided to a node secret store, how credentials are provided, and how to manage them.

Which credentials can be provided this way

The following table shows which credentials can be provided through the node secret store, along with the acceptable key names.

Key names are the same names that environment variables use.

Secret Store Type	Key Names
Active Directory	SDM_ADCS_USER, SDM_ADCS_PW
Delinea Secret Server	DELINEA_USERNAME, DELINEA_PASSWORD
Environment-variable store	Variable named in the store's configuration
HashiCorp Vault (AppRole)	VAULT_ROLE_ID, VAULT_SECRET_ID
HashiCorp Vault (token)	VAULT_TOKEN
CyberArk Conjur	CONJUR_AUTHN_LOGIN, CONJUR_AUTHN_API_KEY
CyberArk PAM	PAM_USERNAME, PAM_PASSWORD
GCP Secret Manager / GCP CAS	GOOGLE_APPLICATION_CREDENTIALS_JSON

In addition to key names, credentials can be provided via the following ways:

• Environment variables: Environment variables named in the secret store's configuration
• Keyfactor: Enrollment username and code variables named in the secret store's configuration

Additional Information

The node's own credentials (the relay token and proxy cluster keys) are stored by sdm install automatically and need no manual provisioning.

AWS and Azure secret stores have nothing to provide here, as they authenticate with cloud identity (instance profile/managed identity).

Only credentials are read from the node. Non-secret settings such as server URLs, TLS options, or tuning variables (for example, DELINEA_SERVER_URL and DELINEA_API_TENANT) are read from the environment only; a value with one of those names in the node has no effect.

Provide Credentials on a Host Install

To get started with node credential storage, use the CLI to provide credentials on a host install. The CLI commands sdm install --relay and sdm install --worker store the node's own credentials automatically during installation.

Secret store credentials are managed afterward with sdm nodesecrets.

Manage Secret Store Credentials in the CLI

After installation, secret store credentials are managed in the CLI with sdm nodesecrets.

Add a Credential

Use sdm nodesecrets set <KEY_NAME> to add a credential. It prompts for the value and the input is hidden. For example:

sdm nodesecrets set DELINEA_PASSWORD

Each sdm nodesecrets set call takes exactly one key. You can provide the value at a hidden prompt on a terminal, as in the previous example, or you can pipe it in from a script, as in the following example:

printf '%s\n' "$PASSWORD" | sdm nodesecrets set DELINEA_PASSWORD

Multi-line values (such as service-account keys, or PEM certificates) use --from-file. For example:

sdm nodesecrets set GOOGLE_APPLICATION_CREDENTIALS_JSON --from-file key.json

Pass - to read from a pipe or redirect instead of a file:

sdm nodesecrets set GOOGLE_APPLICATION_CREDENTIALS_JSON --from-file -

Values never appear on the command line, in shell history, or in output.

List Credentials

Use sdm nodesecrets list to show credentials stored on the node secret store. Only names are shown, never values.

sdm nodesecrets list

Remove a Credential

Use sdm nodesecrets unset <KEY_NAME> to remove a value from the node secret store. For example:

sdm nodesecrets unset DELINEA_PASSWORD

View Help Text

You may view help text in the CLI by running the command with the --help or -h flag. For example:

$ sdm nodesecrets set --help
NAME:
   sdm nodesecrets set - add or update node secrets; values are entered at a hidden prompt, never on the command line

USAGE:
   sdm nodesecrets set [command options] KEY [KEY ...]

DESCRIPTION:
   Values are single-line. On a terminal each value is asked for twice
(hidden); with piped stdin, supply exactly one line per key. For a multi-line
value (a service-account key, PEM material), use --from-file with exactly one
KEY. Concurrent updates are last-writer-wins.

OPTIONS:
   --from-file value  read the value from FILE ('-' reads stdin whole); requires exactly one KEY

For a copy of the help text for each CLI command, see the CLI Reference docs for sdm nodesecrets.

Provide Credentials in Containers

The following steps show a general way to provide credentials in containers.

1. Mount a JSON file of key/value pairs (for example, from a Kubernetes Secret) containing the credentials you want to provide:

{"DELINEA_USERNAME": "svc-sdm", "DELINEA_PASSWORD": "..."}

1. Point SDM_SECRETS_FILE at the mounted path:

env:  - name: SDM_SECRETS_FILE    value: /var/run/secrets/sdm/credentials.json

Where this is not configured, containers keep using environment variables as before. Running sdm install inside a container falls back to the previous environment-file behavior and says so with a warning.

How Credentials Are Chosen

A credential provided through the node secret store always takes precedence over an environment variable of the same name.

When a credential is served from the environment, the node logs a one-time informational notice per credential naming the migration path. Use these notices to find remaining environment-delivered credentials across a fleet.

Migration From Environment Variables

If you want to migrate from using environment variables to storing credentials on the node secret store, follow these steps for each credential, in this order:

1. In the CLI, provide the value: sdm nodesecrets set <KEY_NAME>.
2. Remove the corresponding line from the service's environment file or the container spec.
3. Restart the service.

Removing the environment line is what stops environment delivery. Setting an empty value does not.

After Cloning or Re-imaging a Host

Credentials provided to a node cannot be used on a copy of that machine and cannot be recovered centrally.

On a cloned or re-imaged host, remove the node's credential store and provide the credentials again, using sdm install or sdm nodesecrets set. Error messages on such a host state the same remedy.

Note that sdm update refuses to run on a host whose credential store cannot be read, with an error explaining why.