Overview of Dapr configuration options

    Self-hosted sidecar

    In self hosted mode the Dapr configuration is a configuration file, for example . By default the Dapr sidecar looks in the default Dapr folder for the runtime configuration eg: $HOME/.dapr/config.yaml in Linux/MacOS and %USERPROFILE%\.dapr\config.yaml in Windows.

    A Dapr sidecar can also apply a configuration by using a --config flag to the file path with dapr run CLI command.

    Kubernetes sidecar

    In Kubernetes mode the Dapr configuration is a Configuration CRD, that is applied to the cluster. For example:

    You can use the Dapr CLI to list the Configuration CRDs

    1. dapr configurations -k

    A Dapr sidecar can apply a specific configuration by using a dapr.io/config annotation. For example:

    1.   annotations:
    2.     dapr.io/enabled: "true"
    3.     dapr.io/app-id: "nodeapp"
    4.     dapr.io/app-port: "3000"
    5.     dapr.io/config: "myappconfig"

    Note: There are more Kubernetes annotations available to configure the Dapr sidecar on activation by sidecar Injector system service.

    Sidecar configuration settings

    The following configuration settings can be applied to Dapr application sidecars:

    Tracing

    Tracing configuration turns on tracing for an application.

    The tracing section under the Configuration spec contains the following properties:

    The following table lists the properties for tracing:

    samplingRate is used to enable or disable the tracing. To disable the sampling rate , set samplingRate : "0" in the configuration. The valid range of samplingRate is between 0 and 1 inclusive. The sampling rate determines whether a trace span should be sampled or not based on value. samplingRate : "1" samples all traces. By default, the sampling rate is (0.0001) or 1 in 10,000 traces.

    See Observability distributed tracing for more information.

    Metrics

    The metrics section under the Configuration spec contains the following properties:

    1. metrics:
    2.   enabled: true

    The following table lists the properties for metrics:

    To mitigate high memory usage and egress costs associated with high cardinality metrics, you can set regular expressions for every metric exposed by the Dapr sidecar. For example:

    1. metric:
    2.     enabled: true
    3.     rules:
    5.       labels:
    6.       - name: method
    7.         regex:
    8.           "orders/": "orders/.+"

    See for more information.

    Logging

    The logging section can be used to configure how logging works in the Dapr Runtime.

    The logging section under the Configuration spec contains the following properties:

    The following table lists the properties for logging:

    See for more information.

    Middleware

    Middleware configuration set named HTTP pipeline middleware handlers The httpPipeline and the appHttpPipeline section under the Configuration spec contains the following properties:

    1. httpPipeline: # for incoming http calls
    2.   handlers:
    3.     - name: oauth2
    4.       type: middleware.http.oauth2
    5.     - name: uppercase
    6.       type: middleware.http.uppercase
    7.   handlers:
    8.     - name: oauth2
    9.       type: middleware.http.oauth2
    10.     - name: uppercase
    11.       type: middleware.http.uppercase

    The following table lists the properties for HTTP handlers:

    See for more information

    Scope secret store access

    See the guide for information and examples on how to scope secrets to an application.

    Access Control allow lists for building block APIs

    Access Control allow lists for service invocation API

    See the Allow lists for service invocation guide for information and examples on how to set allow lists with ACLs which using service invocation API.

    Disallow usage of certain component types

    Using the components.deny property in the Configuration spec you can specify a denylist of component types that cannot be initialized.

    For example, the configuration below disallows the initialization of components of type bindings.smtp and secretstores.local.file:

    1. apiVersion: dapr.io/v1alpha1
    2. kind: Configuration
    3. metadata:
    4.   name: myappconfig
    5. spec: 
    6.   components:
    7.     deny:
    8.       - bindings.smtp
    9.       - secretstores.local.file

    You can optionally specify a version to disallow by adding it at the end of the component name. For example, state.in-memory/v1 disables initializing components of type state.in-memory and version v1, but does not disable a (hypothetical) v2 version of the component.

    Turning on preview features

    See the guide for information and examples on how to opt-in to preview features for a release. Preview feature enable new capabilities to be added that still need more time until they become generally available (GA) in the runtime.

    The following YAML shows an example configuration file that can be applied to an applications’ Dapr sidecar.

    Control-plane configuration

    There is a single configuration file called daprsystem installed with the Dapr control plane system services that applies global settings. This is only set up when Dapr is deployed to Kubernetes.

    Control-plane configuration settings

    A Dapr control plane configuration contains the following sections:

    • for mTLS (Mutual TLS)

    The mtls section contains properties for mTLS.

    See the and security concepts for more information.

    Example control plane configuration

    1. apiVersion: dapr.io/v1alpha1
    2. kind: Configuration
    3. metadata:
    4.   name: daprsystem
    5.   namespace: default
    6. spec:
    7.   mtls:
    8.     enabled: true
    10.     workloadCertTTL: 24h

    Last modified February 25, 2023: Update information for daprsystem configuration (afa50e22)