Local file (for Development)
- Warning
Component format
Spec metadata fields
Setup JSON file to hold the secrets
- Name/Value semantics
- Multiple key-values behavior
  - Handling deeper nesting levels
Related links

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:

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.

Local file