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

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:

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:

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:

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.

Related links

• Secrets building block
• How-To: Retrieve a secret
• How-To: Reference secrets in Dapr components
• Secrets API reference

Last modified March 21, 2024: Merge pull request #4082 from newbe36524/v1.13 (f4b0938)