> 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/node-credential-storage-with-strongdm.md).

# 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](/admin/deployment/environment-variables.md) use.

<table data-search="false"><thead><tr><th width="289.78759765625">Secret Store Type</th><th>Key Names</th></tr></thead><tbody><tr><td>Active Directory</td><td><code>SDM_ADCS_USER</code>, <code>SDM_ADCS_PW</code></td></tr><tr><td>Delinea Secret Server</td><td><code>DELINEA_USERNAME</code>, <code>DELINEA_PASSWORD</code></td></tr><tr><td>Environment-variable store</td><td>Variable named in the store's configuration</td></tr><tr><td>HashiCorp Vault (AppRole)</td><td><code>VAULT_ROLE_ID</code>, <code>VAULT_SECRET_ID</code></td></tr><tr><td>HashiCorp Vault (token)</td><td><code>VAULT_TOKEN</code></td></tr><tr><td>CyberArk Conjur</td><td><code>CONJUR_AUTHN_LOGIN</code>, <code>CONJUR_AUTHN_API_KEY</code></td></tr><tr><td>CyberArk PAM</td><td><code>PAM_USERNAME</code>, <code>PAM_PASSWORD</code></td></tr><tr><td>GCP Secret Manager / GCP CAS</td><td><code>GOOGLE_APPLICATION_CREDENTIALS_JSON</code></td></tr></tbody></table>

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:

{% code overflow="wrap" %}

```sh
sdm nodesecrets set DELINEA_PASSWORD
```

{% endcode %}

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:

{% code overflow="wrap" %}

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

{% endcode %}

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

{% code overflow="wrap" %}

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

{% endcode %}

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

{% code overflow="wrap" %}

```sh
sdm nodesecrets set GOOGLE_APPLICATION_CREDENTIALS_JSON --from-file -
```

{% endcode %}

{% hint style="info" %}
Values never appear on the command line, in shell history, or in output.
{% endhint %}

### List Credentials

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

{% code overflow="wrap" %}

```sh
sdm nodesecrets list
```

{% endcode %}

### Remove a Credential

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

{% code overflow="wrap" %}

```sh
sdm nodesecrets unset DELINEA_PASSWORD
```

{% endcode %}

### View Help Text

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

{% code overflow="wrap" %}

```shell
$ 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
```

{% endcode %}

For a copy of the help text for each CLI command, see the [CLI Reference docs for sdm nodesecrets](/references/cli/sdm.md).

## 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:

{% code overflow="wrap" %}

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

{% endcode %}

2. Point `SDM_SECRETS_FILE` at the mounted path:

{% code overflow="wrap" %}

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

{% endcode %}

{% hint style="info" %}
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.
{% endhint %}

## 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.

{% hint style="info" %}
Removing the environment line is what stops environment delivery. Setting an empty value does not.
{% endhint %}

## After Cloning or Re-imaging a Host

{% hint style="warning" %}
Credentials provided to a node cannot be used on a copy of that machine and cannot be recovered centrally.
{% endhint %}

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.


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.strongdm.com/admin/access/secret-stores/node-credential-storage-with-strongdm.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.