Local file (for Development)

This Dapr secret store component reads plain text JSON from a given file and does not use authentication.

Warning

This approach to secret management is not recommended for production environments.

To setup local file based secret store create a component of type . Create a file with the following content in your ./components directory:

Given the following JSON loaded from secretsFile:

  1. {
  2. "redisPassword": "your redis password",
  3. "connectionStrings": {
  4. "sql": "your sql connection string",
  5. "mysql": "your mysql connection string"
  6. }
  7. }

The flag multiValued determines whether the secret store presents a .

If multiValued is false, the store loads and create a map with the following key-value pairs:

  1. $ curl http://localhost:3501/v1.0/secrets/local-secret-store/connectionStrings
  1. "errorCode": "ERR_SECRET_GET",
  2. "message": "failed getting secret with key connectionStrings from secret store local-secret-store: secret connectionStrings not found"
  3. }

This error is expected, since the connectionStrings key is not present, per the table above.

However, requesting for flattened key connectionStrings:sql would result in a successful response, with the following:

  1. {
  2. "connectionStrings:sql": "your sql connection string"
  3. }

Multiple key-values behavior

If multiValued is true, the secret store enables multiple key-value per secret behavior:

  • Nested structures after the top level will be flattened.
  • It parses the into this table:

Notice that in the above table:

  • connectionStrings is now a JSON object with two keys: mysql and sql.
  • The connectionStrings:sql and connectionStrings:mysql flattened keys from the table mapped for name/value semantics are missing.

Invoking a GET request on the key connectionStrings now results in a successful HTTP response similar to the following:

  1. $ curl http://localhost:3501/v1.0/secrets/local-secret-store/connectionStrings
  1. {
  2. "sql": "your sql connection string",
  3. }

Meanwhile, requesting for the flattened key connectionStrings:sql would now return a 500 HTTP error response with the following:

Handling deeper nesting levels

Let’s say you have a local file secret store with multiValued enabled, pointing to a secretsFile with the following JSON content:

  1. {
  2. "connectionStrings": {
  3. "mysql": {
  4. "username": "your mysql username",
  5. "password": "your mysql password"
  6. }
  7. }
  8. }

The contents of key mysql under connectionStrings has a nesting level greater than 1 and would be flattened.

Here is how it would look in memory:

Once again, requesting for key connectionStrings results in a successful HTTP response but its contents, as shown in the table above, would be flattened:

  1. $ curl http://localhost:3501/v1.0/secrets/local-secret-store/connectionStrings
  1. {
  2. "mysql:username": "your mysql username",
  3. "mysql:password": "your mysql password"
  4. }

This is useful in order to mimic secret stores like Vault or Kubernetes that return multiple key/value pairs per secret key.