"minItems": 1,

```[[ example.language or 'yaml' ]]

[% for item in page.choosing_a_resolver %]

- [[ item ]]

[% endfor %]

[[ page.store.file_directory ]]

[[ page.store.multiple_stores ]]

[[ page.store.mixing ]]

[Resolver Quick Reference](#resolver-quick-reference) • [Choosing a Resolver](#choosing-a-resolver) • [Environment Variables](#environment-variables) • [Files](#files) • [Commands](#commands) • [Secretstores](#secretstores) • [Supported Secretstore Backends](#supported-secretstore-backends) • [How It Works](#how-it-works) • [Troubleshooting](#troubleshooting)

- Use `${env:...}` or `${file:...}` for simple setups where secrets are already available locally on the Netdata host.

- Use `${cmd:...}` when you need dynamic secret retrieval via a trusted local command, such as 1Password CLI or a custom script.

- Use `${store:...}` when your organization manages secrets centrally in a cloud provider or Vault and you want Netdata to pull from that source directly.

- You can use different resolver types across different collectors, different jobs within the same collector, or even within the same configuration value. See [Mixing resolver types](#mixing-resolver-types).

If the `/etc/netdata/go.d/ss/` directory does not exist, create it:

You can mix different resolver types in the same configuration value or the same config file. For example, you might read the username from an environment variable and the password from a secretstore:

- Secretstore configuration values (such as tokens and client secrets) also support `${env:...}`, `${file:...}`, and `${cmd:...}` resolvers. Use them to avoid storing backend credentials in plain text. Note that `${store:...}` references are not supported inside secretstore configurations.

Netdata can pull collector credentials directly from AWS Secrets Manager at runtime, so you never store passwords or tokens in plain-text configuration files.

This page covers AWS Secrets Manager specific setup. For the full resolver overview and syntax reference, including simpler alternatives like `${env:...}`, `${file:...}`, and `${cmd:...}`, see [Secrets Management](https://github.com/netdata/netdata/blob/master/src/collectors/SECRETS.md).

The AWS identity used by this secretstore must have the `secretsmanager:GetSecretValue` permission on the secrets you reference in collector configs. Scope the IAM policy to only the secret ARNs Netdata needs.

| region | AWS region used for Secrets Manager requests. There is no automatic region detection — you must always set this explicitly. | | yes |

Use the `${store:aws-sm:...}` syntax to reference AWS Secrets Manager secrets in any string field of a collector configuration file.

- Use `secret-name` to return the whole `SecretString`, for example: `${store:aws-sm:aws_prod:netdata/mysql/password}`.

- Use `secret-name#key` to read one top-level field from a JSON `SecretString`, for example: `${store:aws-sm:aws_prod:netdata/mysql#password}`.

This example configures a MySQL collector job in `/etc/netdata/go.d/mysql.conf`.

The password in the DSN connection string is not stored in plain text. Instead,

`${store:aws-sm:aws_prod:netdata/mysql#password}` tells Netdata to fetch the secret

named `netdata/mysql` from the `aws_prod` store, extract the `password` field from

its JSON value, and substitute it into the DSN at runtime.

jobs:

- name: mysql_prod

dsn: "netdata:${store:aws-sm:aws_prod:netdata/mysql#password}@tcp(127.0.0.1:3306)/"

This example configures an Elasticsearch collector job in `/etc/netdata/go.d/elasticsearch.conf`.

The `password` field uses a secret reference instead of a plain-text password. Netdata fetches

the secret named `netdata/elasticsearch/password` from the `aws_prod` store and substitutes

its full value into the `password` field at runtime.

- name: es_prod

url: https://elasticsearch.example.com:9200

username: netdata

password: "${store:aws-sm:aws_prod:netdata/elasticsearch/password}"