Configuration store component specs

• 1: Azure App Configuration
• 2: PostgreSQL
• 3: Redis

1 - Azure App Configuration

Component format

To set up an Azure App Configuration configuration store, create a component of type configuration.azure.appconfig.

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: <NAME>
spec:
  type: configuration.azure.appconfig
  version: v1
  metadata:
  - name: host # host should be used when Azure Authentication mechanism is used.
    value: <HOST>
  - name: connectionString # connectionString should not be used when Azure Authentication mechanism is used.
    value: <CONNECTIONSTRING>
  - name: maxRetries
    value: # Optional
  - name: retryDelay
    value: # Optional
  - name: maxRetryDelay
    value: # Optional
  - name: azureEnvironment # Optional, defaults to AZUREPUBLICCLOUD
    value: "AZUREPUBLICCLOUD"
  # See authentication section below for all options
  - name: azureTenantId # Optional
    value: "[your_service_principal_tenant_id]"
  - name: azureClientId # Optional
    value: "[your_service_principal_app_id]"
  - name: azureCertificateFile # Optional
    value : "[pfx_certificate_file_fully_qualified_local_path]"
  - name: subscribePollInterval # Optional
    value: #Optional [Expected format example - 24h]

Spec metadata fields

Note: either host or connectionString must be specified.

Authenticating with Connection String

Access an App Configuration instance using its connection string, which is available in the Azure portal. Since connection strings contain credential information, you should treat them as secrets and use a secret store.

Authenticating with Microsoft Entra ID

The Azure App Configuration configuration store component also supports authentication with Microsoft Entra ID. Before you enable this component:

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

Set up Azure App Configuration

You need an Azure subscription to set up Azure App Configuration.

1. Start the Azure App Configuration creation flow. Log in if necessary.

2. Click Create to kickoff deployment of your Azure App Configuration instance.

3. Once your instance is created, grab the Host (Endpoint) or your Connection string:

   • For the Host: navigate to the resource’s Overview and copy Endpoint.
   • For your connection string: navigate to Settings > Access Keys and copy your Connection string.

4. Add your host or your connection string to an azappconfig.yaml file that Dapr can apply.

   Set the host key to [Endpoint] or the connectionString key to the values you saved earlier.

   Note

   In a production-grade application, follow the secret management instructions to securely manage your secrets.

Azure App Configuration request metadata

In Azure App Configuration, you can use labels to define different values for the same key. For example, you can define a single key with different values for development and production. You can specify which label to load when connecting to App Configuration

The Azure App Configuration store component supports the following optional label metadata property:

label: The label of the configuration to retrieve. If not present, the configuration store returns the configuration for the specified key and a null label.

The label can be populated using query parameters in the request URL:

GET curl http://localhost:<daprPort>/v1.0/configuration/<store-name>?key=<key name>&metadata.label=<label value>

Related links

• Basic schema for a Dapr component
• Configuration building block

2 - PostgreSQL

Component format

To set up an PostgreSQL configuration store, create a component of type configuration.postgresql

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: <NAME>
spec:
  type: configuration.postgresql
  version: v1
  metadata:
    # Connection string
    - name: connectionString
      value: "host=localhost user=postgres password=example port=5432 connect_timeout=10 database=config"
    # Name of the table which holds configuration information
    - name: table
      value: "[your_configuration_table_name]" 
    # Individual connection parameters - can be used instead to override connectionString parameters
    #- name: host
    #  value: "localhost"
    #- name: hostaddr
    #  value: "127.0.0.1"
    #- name: port
    #  value: "5432"
    #- name: database
    #  value: "my_db"
    #- name: user
    #  value: "postgres"
    #- name: password
    #  value: "example"
    #- name: sslRootCert
    #  value: "/path/to/ca.crt"
    # Timeout for database operations, in seconds (optional)
    #- name: timeoutInSeconds
    #  value: 20
    # Name of the table where to store the state (optional)
    #- name: tableName
    #  value: "state"
    # Name of the table where to store metadata used by Dapr (optional)
    #- name: metadataTableName
    #  value: "dapr_metadata"
    # Cleanup interval in seconds, to remove expired rows (optional)
    #- name: cleanupIntervalInSeconds
    #  value: 3600
    # Maximum number of connections pooled by this component (optional)
    #- name: maxConns
    #  value: 0
    # Max idle time for connections before they're closed (optional)
    #- name: connectionMaxIdleTime
    #  value: 0
    # Controls the default mode for executing queries. (optional)
    #- name: queryExecMode
    #  value: ""
    # Uncomment this if you wish to use PostgreSQL as a state store for actors (optional)
    #- name: actorStateStore
    #  value: "true"

Spec metadata fields

Authenticate using a connection string

The following metadata options are required to authenticate using a PostgreSQL connection string.

Authenticate using individual connection parameters

In addition to using a connection string, you can optionally specify individual connection parameters. These parameters are equivalent to the standard PostgreSQL connection parameters.

Authenticate using Microsoft Entra ID

Authenticating with Microsoft Entra ID is supported with Azure Database for PostgreSQL. All authentication methods supported by Dapr can be used, including client credentials (“service principal”) and Managed Identity.

Authenticate using AWS IAM

Authenticating with AWS IAM is supported with all versions of PostgreSQL type components. The user specified in the connection string must be an already existing user in the DB, and an AWS IAM enabled user granted the rds_iam database role. Authentication is based on the AWS authentication configuration file, or the AccessKey/SecretKey provided. The AWS authentication token will be dynamically rotated before it’s expiration time with AWS.

Other metadata options

Set up PostgreSQL as Configuration Store

1. Start the PostgreSQL Database

2. Connect to the PostgreSQL database and setup a configuration table with following schema:

   Field	Datatype	Nullable	Details
   KEY	VARCHAR	N	Holds "Key" of the configuration attribute
   VALUE	VARCHAR	N	Holds Value of the configuration attribute
   VERSION	VARCHAR	N	Holds version of the configuration attribute
   METADATA	JSON	Y	Holds Metadata as JSON

   CREATE TABLE IF NOT EXISTS table_name (
     KEY VARCHAR NOT NULL,
     VALUE VARCHAR NOT NULL,
     VERSION VARCHAR NOT NULL,
     METADATA JSON
   );
   

3. Create a TRIGGER on configuration table. An example function to create a TRIGGER is as follows:

   CREATE OR REPLACE FUNCTION notify_event() RETURNS TRIGGER AS $$
       DECLARE 
           data json;
           notification json;
   
       BEGIN
   
           IF (TG_OP = 'DELETE') THEN
               data = row_to_json(OLD);
           ELSE
               data = row_to_json(NEW);
           END IF;
   
           notification = json_build_object(
                             'table',TG_TABLE_NAME,
                             'action', TG_OP,
                             'data', data);
           PERFORM pg_notify('config',notification::text);
           RETURN NULL; 
       END;
   $$ LANGUAGE plpgsql;
   

4. Create the trigger with data encapsulated in the field labeled as data:

   notification = json_build_object(
     'table',TG_TABLE_NAME,
     'action', TG_OP,
     'data', data
   );
   

5. The channel mentioned as attribute to pg_notify should be used when subscribing for configuration notifications

6. Since this is a generic created trigger, map this trigger to configuration table

   CREATE TRIGGER config
   AFTER INSERT OR UPDATE OR DELETE ON configtable
       FOR EACH ROW EXECUTE PROCEDURE notify_event();
   

7. In the subscribe request add an additional metadata field with key as pgNotifyChannel and value should be set to same channel name mentioned in pg_notify. From the above example, it should be set to config

curl -l 'http://<host>:<dapr-http-port>/configuration/mypostgresql/subscribe?key=<keyname1>&key=<keyname2>&metadata.pgNotifyChannel=<channel name>'

Related links

• Basic schema for a Dapr component
• Configuration building block

3 - Redis

Component format

To setup Redis configuration store create a component of type configuration.redis. See this guide on how to create and apply a configuration store configuration.

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: <NAME>
spec:
  type: configuration.redis
  version: v1
  metadata:
  - name: redisHost
    value: <address>:6379
  - name: redisPassword
    value: **************
  - name: useEntraID
    value: "true"
  - name: enableTLS
    value: <bool>

Spec metadata fields

Setup Redis

Dapr can use any Redis instance: containerized, running on your local dev machine, or a managed cloud service.

• Self-Hosted
• Kubernetes
• AWS
• Azure
• GCP

Related links

• Basic schema for a Dapr component
• Read How-To: Manage configuration from a store for instructions on how to use Redis as a configuration store.
• Configuration building block