This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Secret store component specs

The supported secret stores that interface with Dapr

The following table lists secret stores supported by the Dapr secrets building block. Learn how to set up different secret stores for Dapr secrets management.

Table headers to note:

HeaderDescriptionExample
StatusComponent certification statusAlpha
Beta
Stable
Component versionThe version of the componentv1
Since runtime versionThe version of the Dapr runtime when the component status was set or updated1.11

Alibaba Cloud

ComponentMultiple Key-Values Per SecretStatusComponent versionSince runtime version
AlibabaCloud OOS Parameter StoreMultiple Key-Values Per Secret: Not supportedAlphav11.6

Amazon Web Services (AWS)

ComponentMultiple Key-Values Per SecretStatusComponent versionSince runtime version
AWS Secrets ManagerMultiple Key-Values Per Secret: Not supportedBetav11.15
AWS SSM Parameter StoreMultiple Key-Values Per Secret: Not supportedAlphav11.1

Generic

ComponentMultiple Key-Values Per SecretStatusComponent versionSince runtime version
HashiCorp Vault✅Stablev11.10
Kubernetes secrets✅Stablev11.0
Local environment variablesMultiple Key-Values Per Secret: Not supportedStablev11.9
Local file✅Stablev11.9

Google Cloud Platform (GCP)

ComponentMultiple Key-Values Per SecretStatusComponent versionSince runtime version
GCP Secret ManagerMultiple Key-Values Per Secret: Not supportedAlphav11.0

HuaweiCloud Cloud

ComponentMultiple Key-Values Per SecretStatusComponent versionSince runtime version
HuaweiCloud Cloud Secret Management Service (CSMS)Multiple Key-Values Per Secret: Not supportedAlphav11.8

Microsoft Azure

ComponentMultiple Key-Values Per SecretStatusComponent versionSince runtime version
Azure Key VaultMultiple Key-Values Per Secret: Not supportedStablev11.0

Tencent Cloud

ComponentMultiple Key-Values Per SecretStatusComponent versionSince runtime version
Tencent Cloud Secrets Manager (SSM)Multiple Key-Values Per Secret: Not supportedAlphav11.9

1 - AlibabaCloud OOS Parameter Store

Detailed information on the AlibabaCloud OOS Parameter Store - secret store component

Component format

To setup AlibabaCloud OOS Parameter Store secret store create a component of type secretstores.alicloud.parameterstore. See this guide on how to create and apply a secretstore configuration. See this guide on referencing secrets to retrieve and use the secret with Dapr components.

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: alibabacloudparameterstore
spec:
  type: secretstores.alicloud.parameterstore
  version: v1
  metadata:
  - name: regionId
    value: "[alicloud_region_id]"
  - name: accessKeyId 
    value: "[alicloud_access_key_id]"
  - name: accessKeySecret
    value: "[alicloud_access_key_secret]"
  - name: securityToken
    value: "[alicloud_security_token]"

Spec metadata fields

FieldRequiredDetailsExample
regionIdYThe specific region the AlibabaCloud OOS Parameter Store instance is deployed in"cn-hangzhou"
accessKeyIdYThe AlibabaCloud Access Key ID to access this resource"accessKeyId"
accessKeySecretYThe AlibabaCloud Access Key Secret to access this resource"accessKeySecret"
securityTokenNThe AlibabaCloud Security Token to use"securityToken"

Optional per-request metadata properties

The following optional query parameters can be provided when retrieving secrets from this secret store:

Query ParameterDescription
metadata.version_idVersion for the given secret key
metadata.path(For bulk requests only) The path from the metadata. If not set, defaults to root path (all secrets).

Create an AlibabaCloud OOS Parameter Store instance

Setup AlibabaCloud OOS Parameter Store using the AlibabaCloud documentation: https://www.alibabacloud.com/help/en/doc-detail/186828.html.

2 - AWS Secrets Manager

Detailed information on the secret store component

Component format

To setup AWS Secrets Manager secret store create a component of type secretstores.aws.secretmanager. See this guide on how to create and apply a secretstore configuration. See this guide on referencing secrets to retrieve and use the secret with Dapr components.

See Authenticating to AWS for information about authentication-related attributes.

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: awssecretmanager
spec:
  type: secretstores.aws.secretmanager
  version: v1
  metadata:
  - name: region
    value: "[aws_region]"
  - name: accessKey
    value: "[aws_access_key]"
  - name: secretKey
    value: "[aws_secret_key]"
  - name: sessionToken
    value: "[aws_session_token]"

Spec metadata fields

FieldRequiredDetailsExample
regionYThe specific AWS region the AWS Secrets Manager instance is deployed in"us-east-1"
accessKeyYThe AWS Access Key to access this resource"key"
secretKeyYThe AWS Secret Access Key to access this resource"secretAccessKey"
sessionTokenNThe AWS session token to use"sessionToken"

Optional per-request metadata properties

The following optional query parameters can be provided when retrieving secrets from this secret store:

Query ParameterDescription
metadata.version_idVersion for the given secret key.
metadata.version_stageVersion stage for the given secret key.

Create an AWS Secrets Manager instance

Setup AWS Secrets Manager using the AWS documentation: https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials_basic.html.

3 - AWS SSM Parameter Store

Detailed information on the AWS SSM Parameter Store - secret store component

Component format

To setup AWS SSM Parameter Store secret store create a component of type secretstores.aws.parameterstore. See this guide on how to create and apply a secretstore configuration. See this guide on referencing secrets to retrieve and use the secret with Dapr components.

See Authenticating to AWS for information about authentication-related attributes.

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: awsparameterstore
spec:
  type: secretstores.aws.parameterstore
  version: v1
  metadata:
  - name: region
    value: "[aws_region]"
  - name: accessKey
    value: "[aws_access_key]"
  - name: secretKey
    value: "[aws_secret_key]"
  - name: sessionToken
    value: "[aws_session_token]"
  - name: prefix
    value: "[secret_name]"

Spec metadata fields

FieldRequiredDetailsExample
regionYThe specific AWS region the AWS SSM Parameter Store instance is deployed in"us-east-1"
accessKeyYThe AWS Access Key to access this resource"key"
secretKeyYThe AWS Secret Access Key to access this resource"secretAccessKey"
sessionTokenNThe AWS session token to use"sessionToken"
prefixNAllows you to specify more than one SSM parameter store secret store component."prefix"

Create an AWS SSM Parameter Store instance

Setup AWS SSM Parameter Store using the AWS documentation: https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html.

4 - Azure Key Vault secret store

Detailed information on the Azure Key Vault secret store component

Component format

To setup Azure Key Vault secret store, create a component of type secretstores.azure.keyvault.

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: azurekeyvault
spec:
  type: secretstores.azure.keyvault
  version: v1
  metadata:
  - name: vaultName # Required
    value: [your_keyvault_name]
  - name: azureEnvironment # Optional, defaults to AZUREPUBLICCLOUD
    value: "AZUREPUBLICCLOUD"
  # See authentication section below for all options
  - name: azureTenantId
    value: "[your_service_principal_tenant_id]"
  - name: azureClientId
    value: "[your_service_principal_app_id]"
  - name: azureCertificateFile
    value : "[pfx_certificate_file_fully_qualified_local_path]"

Authenticating with Microsoft Entra ID

The Azure Key Vault secret store component supports authentication with Microsoft Entra ID only. Before you enable this component:

  1. Read the Authenticating to Azure document.
  2. Create an Microsoft Entra ID application (also called Service Principal).
  3. Alternatively, create a managed identity for your application platform.

Spec metadata fields

FieldRequiredDetailsExample
vaultNameYThe name of the Azure Key Vault"mykeyvault"
azureEnvironmentNOptional name for the Azure environment if using a different Azure cloud"AZUREPUBLICCLOUD" (default value), "AZURECHINACLOUD", "AZUREUSGOVERNMENTCLOUD", "AZUREGERMANCLOUD"
Auth metadataSee Authenticating to Azure for more information

Additionally, you must provide the authentication fields as explained in the Authenticating to Azure document.

Optional per-request metadata properties

The following optional query parameters can be provided when retrieving secrets from this secret store:

Query ParameterDescription
metadata.version_idVersion for the given secret key.
metadata.maxresults(For bulk requests only) Number of secrets to return, after which the request will be truncated.

Example

Prerequisites

  • Azure Subscription
  • Azure CLI
  • jq
  • You are using bash or zsh shell
  • You’ve created an Microsoft Entra ID application (Service Principal) per the instructions in Authenticating to Azure. You will need the following values:
    ValueDescription
    SERVICE_PRINCIPAL_IDThe ID of the Service Principal that you created for a given application

Create an Azure Key Vault and authorize a Service Principal

  1. Set a variable with the Service Principal that you created:
SERVICE_PRINCIPAL_ID="[your_service_principal_object_id]"
  1. Set a variable with the location in which to create all resources:
LOCATION="[your_location]"

(You can get the full list of options with: az account list-locations --output tsv)

  1. Create a Resource Group, giving it any name you’d like:
RG_NAME="[resource_group_name]"
RG_ID=$(az group create \
  --name "${RG_NAME}" \
  --location "${LOCATION}" \
  | jq -r .id)
  1. Create an Azure Key Vault that uses Azure RBAC for authorization:
KEYVAULT_NAME="[key_vault_name]"
az keyvault create \
  --name "${KEYVAULT_NAME}" \
  --enable-rbac-authorization true \
  --resource-group "${RG_NAME}" \
  --location "${LOCATION}"
  1. Using RBAC, assign a role to the Microsoft Entra ID application so it can access the Key Vault.
    In this case, assign the “Key Vault Secrets User” role, which has the “Get secrets” permission over Azure Key Vault.
az role assignment create \
  --assignee "${SERVICE_PRINCIPAL_ID}" \
  --role "Key Vault Secrets User" \
  --scope "${RG_ID}/providers/Microsoft.KeyVault/vaults/${KEYVAULT_NAME}"

Other less restrictive roles, like “Key Vault Secrets Officer” and “Key Vault Administrator”, can be used, depending on your application. See Microsoft Docs for more information about Azure built-in roles for Key Vault.

Configure the component

Using a client secret

To use a client secret, create a file called azurekeyvault.yaml in the components directory. Use the following template, filling in the Microsoft Entra ID application you created:

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: azurekeyvault
spec:
  type: secretstores.azure.keyvault
  version: v1
  metadata:
  - name: vaultName
    value: "[your_keyvault_name]"
  - name: azureTenantId
    value: "[your_tenant_id]"
  - name: azureClientId
    value: "[your_client_id]"
  - name: azureClientSecret
    value : "[your_client_secret]"

Using a certificate

If you want to use a certificate saved on the local disk instead, use the following template. Fill in the details of the Microsoft Entra ID application you created:

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: azurekeyvault
spec:
  type: secretstores.azure.keyvault
  version: v1
  metadata:
  - name: vaultName
    value: "[your_keyvault_name]"
  - name: azureTenantId
    value: "[your_tenant_id]"
  - name: azureClientId
    value: "[your_client_id]"
  - name: azureCertificateFile
    value : "[pfx_certificate_file_fully_qualified_local_path]"

In Kubernetes, you store the client secret or the certificate into the Kubernetes Secret Store and then refer to those in the YAML file. Before you start, you need the details of the Microsoft Entra ID application you created.

Using a client secret

  1. Create a Kubernetes secret using the following command:

    kubectl create secret generic [your_k8s_secret_name] --from-literal=[your_k8s_secret_key]=[your_client_secret]
    
    • [your_client_secret] is the application’s client secret as generated above
    • [your_k8s_secret_name] is secret name in the Kubernetes secret store
    • [your_k8s_secret_key] is secret key in the Kubernetes secret store
  2. Create an azurekeyvault.yaml component file.

    The component yaml refers to the Kubernetes secretstore using auth property and secretKeyRef refers to the client secret stored in the Kubernetes secret store.

    apiVersion: dapr.io/v1alpha1
    kind: Component
    metadata:
      name: azurekeyvault
    spec:
      type: secretstores.azure.keyvault
      version: v1
      metadata:
      - name: vaultName
        value: "[your_keyvault_name]"
      - name: azureTenantId
        value: "[your_tenant_id]"
      - name: azureClientId
        value: "[your_client_id]"
      - name: azureClientSecret
        secretKeyRef:
          name: "[your_k8s_secret_name]"
          key: "[your_k8s_secret_key]"
    auth:
      secretStore: kubernetes
    
  3. Apply the azurekeyvault.yaml component:

    kubectl apply -f azurekeyvault.yaml
    

Using a certificate

  1. Create a Kubernetes secret using the following command:

    kubectl create secret generic [your_k8s_secret_name] --from-file=[your_k8s_secret_key]=[pfx_certificate_file_fully_qualified_local_path]
    
    • [pfx_certificate_file_fully_qualified_local_path] is the path of PFX file you obtained earlier
    • [your_k8s_secret_name] is secret name in the Kubernetes secret store
    • [your_k8s_secret_key] is secret key in the Kubernetes secret store
  2. Create an azurekeyvault.yaml component file.

    The component yaml refers to the Kubernetes secretstore using auth property and secretKeyRef refers to the certificate stored in the Kubernetes secret store.

    apiVersion: dapr.io/v1alpha1
    kind: Component
    metadata:
      name: azurekeyvault
    spec:
      type: secretstores.azure.keyvault
      version: v1
      metadata:
      - name: vaultName
        value: "[your_keyvault_name]"
      - name: azureTenantId
        value: "[your_tenant_id]"
      - name: azureClientId
        value: "[your_client_id]"
      - name: azureCertificate
        secretKeyRef:
          name: "[your_k8s_secret_name]"
          key: "[your_k8s_secret_key]"
    auth:
      secretStore: kubernetes
    
  3. Apply the azurekeyvault.yaml component:

    kubectl apply -f azurekeyvault.yaml
    

Using Azure managed identity

  1. Ensure your AKS cluster has managed identity enabled and follow the guide for using managed identities.

  2. Create an azurekeyvault.yaml component file.

    The component yaml refers to a particular KeyVault name. The managed identity you will use in a later step must be given read access to this particular KeyVault instance.

    apiVersion: dapr.io/v1alpha1
    kind: Component
    metadata:
      name: azurekeyvault
    spec:
      type: secretstores.azure.keyvault
      version: v1
      metadata:
      - name: vaultName
        value: "[your_keyvault_name]"
    
  3. Apply the azurekeyvault.yaml component:

    kubectl apply -f azurekeyvault.yaml
    
  4. Create and assign a managed identity at the pod-level via Microsoft Entra ID workload identity

  5. After creating a workload identity, give it read permissions:

    • On your desired KeyVault instance
    • In your application deployment. Inject the pod identity both:
      • Via a label annotation
      • By specifying the Kubernetes service account associated with the desired workload identity
    apiVersion: v1
    kind: Pod
    metadata:
      name: mydaprdemoapp
      labels:
        aadpodidbinding: $POD_IDENTITY_NAME
    

Using Azure managed identity directly vs. via Microsoft Entra ID workload identity

When using managed identity directly, you can have multiple identities associated with an app, requiring azureClientId to specify which identity should be used.

However, when using managed identity via Microsoft Entra ID workload identity, azureClientId is not necessary and has no effect. The Azure identity to be used is inferred from the service account tied to an Azure identity via the Azure federated identity.

References

5 - GCP Secret Manager

Detailed information on the GCP Secret Manager secret store component

Component format

To setup GCP Secret Manager secret store create a component of type secretstores.gcp.secretmanager. See this guide on how to create and apply a secretstore configuration. See this guide on referencing secrets to retrieve and use the secret with Dapr components.

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: gcpsecretmanager
spec:
  type: secretstores.gcp.secretmanager
  version: v1
  metadata:
  - name: type
    value: <replace-with-account-type>
  - name: project_id
    value: <replace-with-project-id>
  - name: private_key_id
    value: <replace-with-private-key-id>
  - name: client_email
    value: <replace-with-email>
  - name: client_id
    value: <replace-with-client-id>
  - name: auth_uri
    value: <replace-with-auth-uri>
  - name: token_uri
    value: <replace-with-token-uri>
  - name: auth_provider_x509_cert_url
    value: <replace-with-auth-provider-cert-url>
  - name: client_x509_cert_url
    value: <replace-with-client-cert-url>
  - name: private_key
    value: <replace-with-private-key>

Spec metadata fields

FieldRequiredDetailsExample
project_idYThe project ID associated with this component."project_id"
typeNThe type of the account."service_account"
private_key_idNIf using explicit credentials, this field should contain the private_key_id field from the service account json document"privateKeyId"
private_keyNIf using explicit credentials, this field should contain the private_key field from the service account json. Replace with x509 cert12345-12345
client_emailNIf using explicit credentials, this field should contain the client_email field from the service account json"client@email.com"
client_idNIf using explicit credentials, this field should contain the client_id field from the service account json0123456789-0123456789
auth_uriNIf using explicit credentials, this field should contain the auth_uri field from the service account jsonhttps://accounts.google.com/o/oauth2/auth
token_uriNIf using explicit credentials, this field should contain the token_uri field from the service account jsonhttps://oauth2.googleapis.com/token
auth_provider_x509_cert_urlNIf using explicit credentials, this field should contain the auth_provider_x509_cert_url field from the service account jsonhttps://www.googleapis.com/oauth2/v1/certs
client_x509_cert_urlNIf using explicit credentials, this field should contain the client_x509_cert_url field from the service account jsonhttps://www.googleapis.com/robot/v1/metadata/x509/<PROJECT_NAME>.iam.gserviceaccount.com

GCP Credentials

Since the GCP Secret Manager component uses the GCP Go Client Libraries, by default it authenticates using Application Default Credentials. This is explained further in the Authenticate to GCP Cloud services using client libraries guide. Also, see how to Set up Application Default Credentials.

Optional per-request metadata properties

The following optional query parameters can be provided to the GCP Secret Manager component:

Query ParameterDescription
metadata.version_idVersion for the given secret key.

Setup GCP Secret Manager instance

Setup GCP Secret Manager using the GCP documentation: https://cloud.google.com/secret-manager/docs/quickstart.

6 - HashiCorp Vault

Detailed information on the HashiCorp Vault secret store component

Create the Vault component

To setup HashiCorp Vault secret store create a component of type secretstores.hashicorp.vault. See this guide on how to create and apply a secretstore configuration. See this guide on referencing secrets to retrieve and use the secret with Dapr components.

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: vault
spec:
  type: secretstores.hashicorp.vault
  version: v1
  metadata:
  - name: vaultAddr
    value: [vault_address] # Optional. Default: "https://127.0.0.1:8200"
  - name: caCert # Optional. This or caPath or caPem
    value: "[ca_cert]"
  - name: caPath # Optional. This or CaCert or caPem
    value: "[path_to_ca_cert_file]"
  - name: caPem # Optional. This or CaCert or CaPath
    value : "[encoded_ca_cert_pem]"
  - name: skipVerify # Optional. Default: false
    value : "[skip_tls_verification]"
  - name: tlsServerName # Optional.
    value : "[tls_config_server_name]"
  - name: vaultTokenMountPath # Required if vaultToken not provided. Path to token file.
    value : "[path_to_file_containing_token]"
  - name: vaultToken # Required if vaultTokenMountPath not provided. Token value.
    value : "[path_to_file_containing_token]"
  - name: vaultKVPrefix # Optional. Default: "dapr"
    value : "[vault_prefix]"
  - name: vaultKVUsePrefix # Optional. default: "true"
    value: "[true/false]"
  - name: enginePath # Optional. default: "secret"
    value: "secret"
  - name: vaultValueType # Optional. default: "map"
    value: "map"

Spec metadata fields

FieldRequiredDetailsExample
vaultAddrNThe address of the Vault server. Defaults to "https://127.0.0.1:8200""https://127.0.0.1:8200"
caPemNThe inlined contents of the CA certificate to use, in PEM format. If defined, takes precedence over caPath and caCert.See below
caPathNThe path to a folder holding the CA certificate file to use, in PEM format. If the folder contains multiple files, only the first file found will be used. If defined, takes precedence over caCert."path/to/cacert/holding/folder"
caCertNThe path to the CA certificate to use, in PEM format.""path/to/cacert.pem"
skipVerifyNSkip TLS verification. Defaults to "false""true", "false"
tlsServerNameNThe name of the server requested during TLS handshake in order to support virtual hosting. This value is also used to verify the TLS certificate presented by Vault server."tls-server"
vaultTokenMountPathYPath to file containing token"path/to/file"
vaultTokenYToken for authentication within Vault."tokenValue"
vaultKVPrefixNThe prefix in vault. Defaults to "dapr""dapr", "myprefix"
vaultKVUsePrefixNIf false, vaultKVPrefix is forced to be empty. If the value is not given or set to true, vaultKVPrefix is used when accessing the vault. Setting it to false is needed to be able to use the BulkGetSecret method of the store."true", "false"
enginePathNThe engine path in vault. Defaults to "secret""kv", "any"
vaultValueTypeNVault value type. map means to parse the value into map[string]string, text means to use the value as a string. ‘map’ sets the multipleKeyValuesPerSecret behavior. text makes Vault behave as a secret store with name/value semantics. Defaults to "map""map", "text"

Optional per-request metadata properties

The following optional query parameters can be provided to Hashicorp Vault secret store component:

Query ParameterDescription
metadata.version_idVersion for the given secret key.

Setup Hashicorp Vault instance

Setup Hashicorp Vault using the Vault documentation: https://www.vaultproject.io/docs/install/index.html.

For Kubernetes, you can use the Helm Chart: https://github.com/hashicorp/vault-helm.

Multiple key-values per secret

HashiCorp Vault supports multiple key-values in a secret. While this behavior is ultimately dependent on the underlying secret engine configured by enginePath, it may change the way you store and retrieve keys from Vault. For instance, multiple key-values in a secret is the behavior exposed in the secret engine, the default engine configured by the enginePath field.

When retrieving secrets, a JSON payload is returned with the key names as fields and their respective values.

Suppose you add a secret to your Vault setup as follows:

vault kv put secret/dapr/mysecret firstKey=aValue secondKey=anotherValue thirdKey=yetAnotherDistinctValue

In the example above, the secret is named mysecret and it has 3 key-values under it. Observe that the secret is created under a dapr prefix, as this is the default value for the vaultKVPrefix flag. Retrieving it from Dapr would result in the following output:

$ curl http://localhost:3501/v1.0/secrets/my-hashicorp-vault/mysecret
{
  "firstKey": "aValue",
  "secondKey": "anotherValue",
  "thirdKey": "yetAnotherDistinctValue"
}

Notice that the name of the secret (mysecret) is not repeated in the result.

TLS Server verification

The fields skipVerify, tlsServerName, caCert, caPath, and caPem control if and how Dapr verifies the vault server’s certificate while connecting using TLS/HTTPS.

Inline CA PEM caPem

The caPem field value should be the contents of the PEM CA certificate you want to use. Given PEM certificates are made of multiple lines, defining that value might seem challenging at first. YAML allows for a few ways of defining a multiline values.

Below is one way to define a caPem field.

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: vault
spec:
  type: secretstores.hashicorp.vault
  version: v1
  metadata:
  - name: vaultAddr
    value: https://127.0.0.1:8200
  - name: caPem
    value: |-
          -----BEGIN CERTIFICATE-----
          << the rest of your PEM file content's here, indented appropriately. >>
          -----END CERTIFICATE-----

7 - HuaweiCloud Cloud Secret Management Service (CSMS)

Detailed information on the HuaweiCloud Cloud Secret Management Service (CSMS) - secret store component

Component format

To setup HuaweiCloud Cloud Secret Management Service (CSMS) secret store create a component of type secretstores.huaweicloud.csms. See this guide on how to create and apply a secretstore configuration. See this guide on referencing secrets to retrieve and use the secret with Dapr components.

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: huaweicloudcsms
spec:
  type: secretstores.huaweicloud.csms
  version: v1
  metadata:
  - name: region
    value: "[huaweicloud_region]"
  - name: accessKey
    value: "[huaweicloud_access_key]"
  - name: secretAccessKey
    value: "[huaweicloud_secret_access_key]"

Spec metadata fields

FieldRequiredDetailsExample
regionYThe specific region the HuaweiCloud CSMS instance is deployed in"cn-north-4"
accessKeyYThe HuaweiCloud Access Key to access this resource"accessKey"
secretAccessKeyYThe HuaweiCloud Secret Access Key to access this resource"secretAccessKey"

Optional per-request metadata properties

The following optional query parameters can be provided when retrieving secrets from this secret store:

Query ParameterDescription
metadata.version_idVersion for the given secret key.

Setup HuaweiCloud Cloud Secret Management Service (CSMS) instance

Setup HuaweiCloud Cloud Secret Management Service (CSMS) using the HuaweiCloud documentation: https://support.huaweicloud.com/intl/en-us/usermanual-dew/dew_01_9993.html.

8 - Kubernetes secrets

Detailed information on the Kubernetes secret store component

Default Kubernetes secret store component

When Dapr is deployed to a Kubernetes cluster, a secret store with the name kubernetes is automatically provisioned. This pre-provisioned secret store allows you to use the native Kubernetes secret store with no need to author, deploy or maintain a component configuration file for the secret store and is useful for developers looking to simply access secrets stored natively in a Kubernetes cluster.

A custom component definition file for a Kubernetes secret store can still be configured (See below for details). Using a custom definition decouples referencing the secret store in your code from the hosting platform as the store name is not fixed and can be customized, keeping your code more generic and portable. Additionally, by explicitly defining a Kubernetes secret store component you can connect to a Kubernetes secret store from a local Dapr self-hosted installation. This requires a valid kubeconfig file.

Create a custom Kubernetes secret store component

To setup a Kubernetes secret store create a component of type secretstores.kubernetes. See this guide on how to create and apply a secretstore configuration. See this guide on referencing secrets to retrieve and use the secret with Dapr components.

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: mycustomsecretstore
spec:
  type: secretstores.kubernetes
  version: v1
  metadata:[]

Spec metadata fields

FieldRequiredDetailsExample
defaultNamespaceNDefault namespace to retrieve secrets from. If unset, the namespace must be specified in each request metadata or via environment variable NAMESPACE"default-ns"
kubeconfigPathNThe path to the kubeconfig file. If not specified, the store uses the default in-cluster config value"/path/to/kubeconfig"

Optional per-request metadata properties

The following optional query parameters can be provided to Kubernetes secret store component:

Query ParameterDescription
metadata.namespaceThe namespace of the secret. If not specified, the namespace of the pod is used.

9 - Local environment variables (for Development)

Detailed information on the local environment secret store component

This Dapr secret store component uses locally defined environment variable and does not use authentication.

Component format

To setup local environment variables secret store create a component of type secretstores.local.env. Create a file with the following content in your ./components directory:

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: envvar-secret-store
spec:
  type: secretstores.local.env
  version: v1
  metadata:
    # - name: prefix
    #   value: "MYAPP_"

Spec metadata fields

FieldRequiredDetailsExample
prefixNIf set, limits operations to environment variables with the given prefix. The prefix is removed from the returned secrets’ names.
The matching is case-insensitive on Windows and case-sensitive on all other operating systems.
"MYAPP_"

Notes

For security reasons, this component cannot be used to access these environment variables:

  • APP_API_TOKEN
  • Any variable whose name begins with the DAPR_ prefix

10 - 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

FieldRequiredDetailsExample
secretsFileYThe path to the file where secrets are stored"path/to/file.json"
nestedSeparatorNUsed by the store when flattening the JSON hierarchy to a map. Defaults to ":"":"
multiValuedN"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 keyvalue
“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:
keyvalue
“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:

keyvalue
“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.

11 - Tencent Cloud Secrets Manager (SSM)

Detailed information on the Tencent Cloud Secrets Manager (SSM) - secret store component

Component format

To setup Tencent Cloud Secrets Manager (SSM) secret store create a component of type secretstores.tencentcloud.ssm. See this guide on how to create and apply a secretstore configuration. See this guide on referencing secrets to retrieve and use the secret with Dapr components.

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: tencentcloudssm
spec:
  type: secretstores.tencentcloud.ssm
  version: v1
  metadata:
  - name: region
    value: "[tencentcloud_region]"
  - name: secretId
    value: "[tencentcloud_secret_id]"
  - name: secretKey
    value: "[tencentcloud_secret_key]"
  - name: token
    value: "[tencentcloud_secret_token]"

Spec metadata fields

FieldRequiredDetailsExample
regionYThe specific region the Tencent SSM instance is deployed in"ap-beijing-3"
secretIdYThe SecretId of the Tencent Cloud account"xyz"
secretKeyYThe SecretKey of the Tencent Cloud account"xyz"
tokenNThe Token of the Tencent Cloud account. This is required only if using temporary credentials""

Optional per-request metadata properties

The following optional query parameters can be provided when retrieving secrets from this secret store:

Query ParameterDescription
metadata.version_idVersion for the given secret key.

Setup Tencent Cloud Secrets Manager (SSM)

Setup Tencent Cloud Secrets Manager (SSM) using the Tencent Cloud documentation: https://www.tencentcloud.com/products/ssm