Local file (for Development)

Detailed information on the local file secret store component

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.

Component format

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

  1. apiVersion: dapr.io/v1alpha1
  2. kind: Component
  3. metadata:
  4. name: local-secret-store
  5. spec:
  6. type: secretstores.local.file
  7. version: v1
  8. metadata:
  9. - name: secretsFile
  10. value: [path to the JSON file]
  11. - name: nestedSeparator
  12. value: ":"
  13. - name: multiValued
  14. value: "false"

Spec metadata fields

FieldRequiredDetailsExample
secretsFileYThe path to the file where secrets are stored“path/to/file.json”
nestedSeparatorNUsed by the store when flattening the JSON hierarchy to a map. Defaults to “:”“:”
multiValuedN“true” sets the multipleKeyValuesPerSecret behavior. Allows one level of multi-valued key/value pairs before flattening JSON hierarchy. Defaults to “false”“true”

Setup JSON file to hold the secrets

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 name/value behavior or a multiple key-value per secret behavior.

Name/Value semantics

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

flattened keyvalue
“redisPassword”“your redis password”
“connectionStrings:sql”“your sql connection string”
“connectionStrings:mysql”“your mysql connection string”

If the multiValued setting set to true, invoking a GET request on the key connectionStrings results in a 500 HTTP response and an error message. For example:

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

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. $ curl http://localhost:3501/v1.0/secrets/local-secret-store/connectionStrings:sql
  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 same JSON file into this table:
keyvalue
“redisPassword”“your redis password”
“connectionStrings”{“mysql”:”your mysql connection string”,”sql”:”your sql connection string”}

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. "mysql": "your mysql connection string"
  4. }

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

  1. {
  2. "errorCode": "ERR_SECRET_GET",
  3. "message": "failed getting secret with key connectionStrings:sql from secret store local-secret-store: secret connectionStrings:sql not found"
  4. }

Handling deeper nesting levels

Notice that, as stated in the spec metadata fields table, multiValued only handles a single nesting level.

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

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

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:

keyvalue
“redisPassword”“your redis password”
“connectionStrings”{ “mysql:username”: “your mysql username”, “mysql:password”: “your mysql password” }

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.

Last modified June 19, 2023: Merge pull request #3565 from dapr/aacrawfi/skip-secrets-close (b1763bf)