The documentation you are viewing is for Dapr v1.13 which is an older version of Dapr. For up-to-date documentation, see the latest version.

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.

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:

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: local-secret-store
spec:
  type: secretstores.local.file
  version: v1
  metadata:
  - name: secretsFile
    value: [path to the JSON file]
  - name: nestedSeparator
    value: ":"
  - name: multiValued
    value: "false"

Spec metadata fields

Field Required Details Example
secretsFile Y The path to the file where secrets are stored "path/to/file.json"
nestedSeparator N Used by the store when flattening the JSON hierarchy to a map. Defaults to ":" ":"
multiValued N "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:

{
    "redisPassword": "your redis password",
    "connectionStrings": {
        "sql": "your sql connection string",
        "mysql": "your mysql connection string"
    }
}

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 key value
“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. 例如：

$ curl http://localhost:3501/v1.0/secrets/local-secret-store/connectionStrings

{
  "errorCode": "ERR_SECRET_GET",
  "message": "failed getting secret with key connectionStrings from secret store local-secret-store: secret connectionStrings not found"
}

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:

$ curl http://localhost:3501/v1.0/secrets/local-secret-store/connectionStrings:sql

{
  "connectionStrings:sql": "your sql connection string"
}

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:
key value
“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:

$ curl http://localhost:3501/v1.0/secrets/local-secret-store/connectionStrings

{
  "sql": "your sql connection string",
  "mysql": "your mysql connection string"
}

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

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

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:

{
    "redisPassword": "your redis password",
    "connectionStrings": {
        "mysql": {
          "username": "your mysql username",
          "password": "your mysql password"
        }
    }
}

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:

key value
“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:

$ curl http://localhost:3501/v1.0/secrets/local-secret-store/connectionStrings

{
  "mysql:username": "your mysql username",
  "mysql:password": "your mysql password"
}

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