Configurations docs refresh

daprdocs/content/en/operations/configuration/api-allowlist.md

@@ -6,17 +6,17 @@ weight: 4500
 description: "Choose which Dapr sidecar APIs are available to the app"
 ---
 
-In certain scenarios, such as zero trust networks or when exposing the Dapr sidecar to external traffic through a frontend, it's recommended to only enable the Dapr sidecar APIs that are being used by the app. Doing so reduces the attack surface and helps keep the Dapr APIs scoped to the actual needs of the application.
+In scenarios such as zero trust networks or when exposing the Dapr sidecar to external traffic through a frontend, it's recommended to only enable the Dapr sidecar APIs being used by the app. Doing so reduces the attack surface and helps keep the Dapr APIs scoped to the actual needs of the application.
 
-Dapr allows developers to control which APIs are accessible to the application by setting an API allowlist or denylist using a [Dapr Configuration]({{<ref "configuration-overview.md">}}).
+Dapr allows you to control which APIs are accessible to the application by setting an API allowlist or denylist using a [Dapr Configuration]({{< ref "configuration-schema.md" >}}).
 
 ### Default behavior
 
 If no API allowlist or denylist is specified, the default behavior is to allow access to all Dapr APIs.
 
-- If only a denylist is defined, all Dapr APIs are allowed except those defined in the denylist
-- If only an allowlist is defined, only the Dapr APIs listed in the allowlist are allowed
-- If both an allowlist and a denylist are defined, the allowed APIs are those defined in the allowlist, unless they are also included in the denylist. In other words, the denylist overrides the allowlist for APIs that are defined in both.
+- If you've only defined a denylist, all Dapr APIs are allowed except those defined in the denylist
+- If you've only defined an allowlist, only the Dapr APIs listed in the allowlist are allowed
+- If you've defined both an allowlist and a denylist, the denylist overrides the allowlist for APIs that are defined in both.
 - If neither is defined, all APIs are allowed.
 
 For example, the following configuration enables all APIs for both HTTP and gRPC:
@@ -119,14 +119,18 @@ See this list of values corresponding to the different Dapr APIs:
 | [Service Invocation]({{< ref service_invocation_api.md >}}) | `invoke` (`v1.0`) | `invoke` (`v1`) |
 | [State]({{< ref state_api.md>}})| `state` (`v1.0` and `v1.0-alpha1`) | `state` (`v1` and `v1alpha1`) |
 | [Pub/Sub]({{< ref pubsub.md >}}) | `publish` (`v1.0` and `v1.0-alpha1`) | `publish` (`v1` and `v1alpha1`) |
+| [Output Bindings]({{< ref bindings_api.md >}})  | `bindings` (`v1.0`) |`bindings` (`v1`) |
 | Subscribe | n/a | `subscribe` (`v1alpha1`) |
-| [(Output) Bindings]({{< ref bindings_api.md >}})  | `bindings` (`v1.0`) |`bindings` (`v1`) |
 | [Secrets]({{< ref secrets_api.md >}})| `secrets` (`v1.0`) | `secrets` (`v1`) |
 | [Actors]({{< ref actors_api.md >}}) | `actors`  (`v1.0`) |`actors` (`v1`) |
 | [Metadata]({{< ref metadata_api.md >}}) | `metadata` (`v1.0`) |`metadata` (`v1`) |
 | [Configuration]({{< ref configuration_api.md >}}) | `configuration` (`v1.0` and `v1.0-alpha1`) | `configuration` (`v1` and `v1alpha1`) |
 | [Distributed Lock]({{< ref distributed_lock_api.md >}}) | `lock` (`v1.0-alpha1`)<br/>`unlock` (`v1.0-alpha1`) | `lock` (`v1alpha1`)<br/>`unlock` (`v1alpha1`) |
-| Cryptography | `crypto` (`v1.0-alpha1`) | `crypto` (`v1alpha1`) |
+| [Cryptography]({{< ref cryptography_api.md >}}) | `crypto` (`v1.0-alpha1`) | `crypto` (`v1alpha1`) |
 | [Workflow]({{< ref workflow_api.md >}}) | `workflows` (`v1.0-alpha1`) |`workflows` (`v1alpha1`) |
 | [Health]({{< ref health_api.md >}}) | `healthz`  (`v1.0`) | n/a |
 | Shutdown | `shutdown` (`v1.0`) | `shutdown` (`v1`) |
+
+## Next steps
+
+{{< button text="Configure Dapr to use gRPC" page="grpc" >}}

daprdocs/content/en/operations/configuration/configuration-overview.md

@@ -1,30 +1,42 @@
 ---
 type: docs
-title: "Overview of Dapr configuration options"
+title: "Dapr configuration"
 linkTitle: "Overview"
 weight: 100
-description: "Information on Dapr configuration and how to set options for your application"
+description: "Overview of Dapr configuration"
 ---
 
+With Dapr configuration, you can set options for the sidecar or control plane. 
+
 ## Sidecar configuration
 
-### Setup sidecar configuration
+### Set up sidecar configuration
+
+You can set up sidecar configuration either in self-hosted or Kubernetes mode.
 
-#### Self-hosted sidecar
+{{< tabs "Self-hosted" Kubernetes >}}
 
-In self hosted mode the Dapr configuration is a configuration file, for example `config.yaml`. 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.
+ <!-- Self hosted -->
+{{% codetab %}}
+
+In self hosted mode, the Dapr configuration is a [configuration file]({{< ref configuration-schema.md >}}) - for example, `config.yaml`. By default, the Dapr sidecar looks in the default Dapr folder for the runtime configuration:
+- Linux/MacOs: `$HOME/.dapr/config.yaml`
+- Windows: `%USERPROFILE%\.dapr\config.yaml`
 
 A Dapr sidecar can also apply a configuration by using a `--config` flag to the file path with `dapr run` CLI command.
 
-#### Kubernetes sidecar
+{{% /codetab %}}
+
+ <!-- Kubernetes -->
+{{% codetab %}}
 
-In Kubernetes mode the Dapr configuration is a Configuration resource, that is applied to the cluster. For example:
+In Kubernetes mode, the Dapr configuration is a Configuration resource, that is applied to the cluster. For example:
 
 ```bash
 kubectl apply -f myappconfig.yaml
 ```
 
-You can use the Dapr CLI to list the Configuration resources
+You can use the Dapr CLI to list the Configuration resources.
 
 ```bash
 dapr configurations -k
@@ -40,11 +52,15 @@ A Dapr sidecar can apply a specific configuration by using a `dapr.io/config` an
     dapr.io/config: "myappconfig"
 ```
 
-Note: There are more [Kubernetes annotations]({{< ref "arguments-annotations-overview.md" >}}) available to configure the Dapr sidecar on activation by sidecar Injector system service.
+> **Note:** [See all Kubernetes annotations]({{< ref "arguments-annotations-overview.md" >}}) available to configure the Dapr sidecar on activation by sidecar Injector system service.
+
+{{% /codetab %}}
+
+{{< /tabs >}}
 
 ### Sidecar configuration settings
 
-The following configuration settings can be applied to Dapr application sidecars:
+The following menu includes all of the configuration settings you can set on the sidecar. 
 
 - [Tracing](#tracing)
 - [Metrics](#metrics)
@@ -84,10 +100,17 @@ The following table lists the properties for tracing:
 | `otel.protocol` | string | Set to `http` or `grpc` protocol
 | `zipkin.endpointAddress` | string | Set the Zipkin server address to send traces to
 
-`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.
+##### `samplingRate`
+
+`samplingRate` is used to enable or disable the tracing. 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.
 
-The OpenTelemetry (otel) endpoint can also be configured via an environment variables. The presence of the OTEL_EXPORTER_OTLP_ENDPOINT environment variable
+To disable the sampling rate, set `samplingRate : "0"` in the configuration.
+
+##### `otel`
+
+The OpenTelemetry (`otel`) endpoint can also be configured via an environment variable. The presence of the `OTEL_EXPORTER_OTLP_ENDPOINT` environment variable
 turns on tracing for the sidecar.
 
 | Environment Variable | Description |
@@ -100,9 +123,9 @@ See [Observability distributed tracing]({{< ref "tracing-overview.md" >}}) for m
 
 #### Metrics
 
-The metrics section can be used to enable or disable metrics for an application.
+The `metrics` section under the `Configuration` spec can be used to enable or disable metrics for an application.
 
-The `metrics` section under the `Configuration` spec contains the following properties:
+The `metrics` section contains the following properties:
 
 ```yml
 metrics:
@@ -122,7 +145,7 @@ metrics:
     excludeVerbs: false
 ```
 
-In the examples above this path filter `/orders/{orderID}/items/{itemID}` would return a single metric count matching all the orderIDs and all the itemIDs rather than multiple metrics for each itemID. For more information see [HTTP metrics path matching]({{< ref "metrics-overview.md#http-metrics-path-matching" >}})
+In the examples above, the path filter `/orders/{orderID}/items/{itemID}` would return _a single metric count_ matching all the `orderID`s and all the `itemID`s, rather than multiple metrics for each `itemID`. For more information, see [HTTP metrics path matching]({{< ref "metrics-overview.md#http-metrics-path-matching" >}})
 
 The following table lists the properties for metrics:
 
@@ -135,7 +158,7 @@ The following table lists the properties for metrics:
 | `http.pathMatching`          | array   | Array of paths for path matching, allowing users to define matching paths to manage cardinality.                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
 | `http.excludeVerbs`          | boolean | When set to true (default is false), the Dapr HTTP server ignores each request HTTP verb when building the method metric label.                                                                                                                                                                                                                                                                                                                                                                                                                  |
 
-To further help managing cardinality, path matching allows specified paths matched according to defined patterns, reducing the number of unique metrics paths and thus controlling metric cardinality. This feature is particularly useful for applications with dynamic URLs, ensuring that metrics remain meaningful and manageable without excessive memory consumption. 
+To further help manage cardinality, path matching allows you to match specified paths according to defined patterns, reducing the number of unique metrics paths and thus controlling metric cardinality. This feature is particularly useful for applications with dynamic URLs, ensuring that metrics remain meaningful and manageable without excessive memory consumption. 
 
 Using rules, you can set regular expressions for every metric exposed by the Dapr sidecar. For example:
 
@@ -154,9 +177,9 @@ See [metrics documentation]({{< ref "metrics-overview.md" >}}) for more informat
 
 #### Logging
 
-The logging section can be used to configure how logging works in the Dapr Runtime.
+The `logging` section under the `Configuration` spec is used to configure how logging works in the Dapr Runtime.
 
-The `logging` section under the `Configuration` spec contains the following properties:
+The `logging` section contains the following properties:
 
 ```yml
 logging:
@@ -178,8 +201,7 @@ See [logging documentation]({{< ref "logs.md" >}}) 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:
+Middleware configuration sets named HTTP pipeline middleware handlers. The `httpPipeline` and the `appHttpPipeline` section under the `Configuration` spec contain the following properties:
 
 ```yml
 httpPipeline: # for incoming http calls
@@ -203,13 +225,13 @@ The following table lists the properties for HTTP handlers:
 | `name`     | string | Name of the middleware component
 | `type`     | string | Type of middleware component
 
-See [Middleware pipelines]({{< ref "middleware.md" >}}) for more information
+See [Middleware pipelines]({{< ref "middleware.md" >}}) for more information.
 
 #### Name resolution component
 
-You can set name resolution component to use within the configuration YAML. For example, to set the `spec.nameResolution.component` property to `"sqlite"`, pass configuration options in the `spec.nameResolution.configuration` dictionary as shown below.
+You can set name resolution components to use within the configuration file. For example, to set the `spec.nameResolution.component` property to `"sqlite"`, pass configuration options in the `spec.nameResolution.configuration` dictionary as shown below.
 
-This is the basic example of a configuration resource:
+This is a basic example of a configuration resource:
 
 ```yaml
 apiVersion: dapr.io/v1alpha1
@@ -226,19 +248,19 @@ spec:
 
 For more information, see:
 - [The name resolution component documentation]({{< ref supported-name-resolution >}}) for more examples.
-- - [The Configuration YAML documentation]({{< ref configuration-schema.md >}}) to learn more about how to configure name resolution per component.
+- [The Configuration file documentation]({{< ref configuration-schema.md >}}) to learn more about how to configure name resolution per component.
 
 #### Scope secret store access
 
 See the [Scoping secrets]({{< ref "secret-scope.md" >}}) guide for information and examples on how to scope secrets to an application.
 
 #### Access Control allow lists for building block APIs
 
-See the [selectively enable Dapr APIs on the Dapr sidecar]({{< ref "api-allowlist.md" >}}) guide for information and examples on how to set ACLs on the building block APIs lists.
+See the guide for [selectively enabling Dapr APIs on the Dapr sidecar]({{< ref "api-allowlist.md" >}}) for information and examples on how to set access control allow lists (ACLs) on the building block APIs lists.
 
 #### Access Control allow lists for service invocation API
 
-See the [Allow lists for service invocation]({{< ref "invoke-allowlist.md" >}}) guide for information and examples on how to set allow lists with ACLs which using service invocation API.
+See the [Allow lists for service invocation]({{< ref "invoke-allowlist.md" >}}) guide for information and examples on how to set allow lists with ACLs which use the service invocation API.
 
 #### Disallow usage of certain component types
 
@@ -258,13 +280,23 @@ spec:
       - 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.
+Optionally, you can 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.
 
-> Note: One special note applies to the component type `secretstores.kubernetes`. When you add that component to the denylist, Dapr forbids the creation of _additional_ components of type `secretstores.kubernetes`. However, it does not disable the built-in Kubernetes secret store, which is created by Dapr automatically and is used to store secrets specified in Components specs. If you want to disable the built-in Kubernetes secret store, you need to use the `dapr.io/disable-builtin-k8s-secret-store` [annotation]({{< ref arguments-annotations-overview.md >}}).
+{{% alert title="Note" color="primary" %}}
+ When you add the component type `secretstores.kubernetes` to the denylist, Dapr forbids the creation of _additional_ components of type `secretstores.kubernetes`. 
+
+ However, it does not disable the built-in Kubernetes secret store, which is:
+ - Created by Dapr automatically
+ - Used to store secrets specified in Components specs
+
+ If you want to disable the built-in Kubernetes secret store, you need to use the `dapr.io/disable-builtin-k8s-secret-store` [annotation]({{< ref arguments-annotations-overview.md >}}).
+{{% /alert %}} 
 
 #### Turning on preview features
 
-See the [preview features]({{< ref "preview-features.md" >}}) 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.
+See the [preview features]({{< ref "preview-features.md" >}}) guide for information and examples on how to opt-in to preview features for a release. 
+
+Enabling preview features unlock new capabilities to be added for dev/test, since they still need more time before becoming generally available (GA) in the runtime.
 
 ### Example sidecar configuration
 
@@ -316,7 +348,9 @@ spec:
 
 ## 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.
+A single configuration file called `daprsystem` is 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
 
@@ -353,3 +387,7 @@ spec:
     allowedClockSkew: 15m
     workloadCertTTL: 24h
 ```
+
+## Next steps
+
+{{< button text="Learn about concurrency and rate limits" page="control-concurrency" >}}