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.
To setup local file based secret store create a component of type . Create a file with the following content in your ./components
directory:
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 .
If multiValued
is false
, the store loads and create a map with the following key-value pairs:
$ 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:
{
"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 into this table:
Notice that in the above table:
connectionStrings
is now a JSON object with two keys:mysql
andsql
.- The
connectionStrings:sql
andconnectionStrings: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",
}
Meanwhile, requesting for the flattened key connectionStrings:sql
would now return a 500 HTTP error response with the following:
Handling deeper nesting levels
Let’s say you have a local file secret store with multiValued
enabled, pointing to a secretsFile
with the following JSON content:
{
"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.