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.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. For example:
$ 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:
connectionStringsis now a JSON object with two keys:mysqlandsql.- The 
connectionStrings:sqlandconnectionStrings:mysqlflattened 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.