Merge branch 'v1.14' into workflow-method-updates

.github/workflows/website-root.yml

@@ -97,7 +97,7 @@ jobs:
         with:
           submodules: false
       - name: Download Hugo artifacts
-        uses: actions/download-artifact@v3
+        uses: actions/download-artifact@v4.1.7
         with:
           name: hugo_build
           path: site/

daprdocs/content/en/concepts/configuration-concept.md

@@ -6,9 +6,13 @@ weight: 400
 description: "Change the behavior of Dapr application sidecars or globally on Dapr control plane system services"
 ---
 
-Dapr configurations are settings and policies that enable you to change both the behavior of individual Dapr applications, or the global behavior of the Dapr control plane system services. For example, you can set an ACL policy on the application sidecar configuration which indicates which methods can be called from another application, or on the Dapr control plane configuration you can change the certificate renewal period for all certificates that are deployed to application sidecar instances.
+With Dapr configurations, you use settings and policies to change:
+- The behavior of individual Dapr applications
+- The global behavior of the Dapr control plane system services
 
-Configurations are defined and deployed as a YAML file. An application configuration example is shown below, which demonstrates an example of setting a tracing endpoint for where to send the metrics information, capturing all the sample traces.
+For example, set a sampling rate policy on the application sidecar configuration to indicate which methods can be called from another application. If you set a policy on the Dapr control plane configuration, you can change the certificate renewal period for all certificates that are deployed to application sidecar instances.
+
+Configurations are defined and deployed as a YAML file. In the following application configuration example, a tracing endpoint is set for where to send the metrics information, capturing all the sample traces.
 
 ```yaml
 apiVersion: dapr.io/v1alpha1
@@ -23,9 +27,11 @@ spec:
       endpointAddress: "http://localhost:9411/api/v2/spans"
 ```
 
-This configuration configures tracing for metrics recording. It can be loaded in local self-hosted mode by editing the default configuration file called `config.yaml` file in your `.dapr` directory, or by applying it to your Kubernetes cluster with kubectl/helm.
+The above YAML configures tracing for metrics recording. You can load it in local self-hosted mode by either:
+- Editing the default configuration file called `config.yaml` file in your `.dapr` directory, or 
+- Applying it to your Kubernetes cluster with `kubectl/helm`.
 
-Here is an example of the Dapr control plane configuration called `daprsystem` in the `dapr-system` namespace.
+The following example shows the Dapr control plane configuration called `daprsystem` in the `dapr-system` namespace.
 
 ```yaml
 apiVersion: dapr.io/v1alpha1
@@ -40,8 +46,14 @@ spec:
     allowedClockSkew: "15m"
 ```
 
-Visit [overview of Dapr configuration options]({{<ref "configuration-overview.md">}}) for a list of the configuration options.
+By default, there is a single configuration file called `daprsystem` installed with the Dapr control plane system services. This configuration file applies global control plane settings and is set up when Dapr is deployed to Kubernetes.
+
+[Learn more about configuration options.]({{< ref "configuration-overview.md" >}})
 
-{{% alert title="Note" color="primary" %}}
-Dapr application and control plane configurations should not be confused with the configuration building block API that enables applications to retrieve key/value data from configuration store components. Read the [Configuration building block]({{< ref configuration-api-overview >}}) for more information.
+{{% alert title="Important" color="warning" %}}
+Dapr application and control plane configurations should not be confused with the [configuration building block API]({{< ref configuration-api-overview >}}), which enables applications to retrieve key/value data from configuration store components. 
 {{% /alert %}}
+
+## Next steps
+
+{{< button text="Learn more about configuration" page="configuration-overview" >}}

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" >}}