mirror of https://github.com/dapr/docs.git
continue freshness
Signed-off-by: Hannah Hunter <hannahhunter@microsoft.com>
This commit is contained in:
Hannah Hunter
parent
bbdf25a1dd
commit
db964dc3d0
|
|
@ -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,13 +119,17 @@ 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`) |
|
||||
| [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" >}}
|
||||
|
|
@ -3,20 +3,21 @@ type: docs
|
|||
title: "How-To: Configure Dapr to use gRPC"
|
||||
linkTitle: "Use gRPC interface"
|
||||
weight: 5000
|
||||
description: "How to configure Dapr to use gRPC for low-latency, high performance scenarios"
|
||||
description: "Configure Dapr to use gRPC for low-latency, high performance scenarios"
|
||||
---
|
||||
|
||||
Dapr implements both an HTTP and a gRPC API for local calls. gRPC is useful for low-latency, high performance scenarios and has language integration using the proto clients.
|
||||
|
||||
You can find a list of auto-generated clients [here]({{< ref sdks >}}).
|
||||
Dapr implements both an HTTP and a gRPC API for local calls. gRPC is useful for low-latency, high performance scenarios and has language integration using the proto clients. [You can see the full list of auto-generated clients (Dapr SDKs)]({{< ref sdks >}}).
|
||||
|
||||
The Dapr runtime implements a [proto service](https://github.com/dapr/dapr/blob/master/dapr/proto/runtime/v1/dapr.proto) that apps can communicate with via gRPC.
|
||||
|
||||
In addition to calling Dapr via gRPC, Dapr can communicate with an application via gRPC. To do that, the app needs to host a gRPC server and implements the [Dapr appcallback service](https://github.com/dapr/dapr/blob/master/dapr/proto/runtime/v1/appcallback.proto)
|
||||
Not only can you call Dapr via gRPC, Dapr can communicate with an application via gRPC. To do that, the app needs to host a gRPC server and implement the [Dapr `appcallback` service](https://github.com/dapr/dapr/blob/master/dapr/proto/runtime/v1/appcallback.proto)
|
||||
|
||||
## Configuring Dapr to communicate with an app via gRPC
|
||||
|
||||
### Self hosted
|
||||
{{< tabs "Self-hosted" Kubernetes >}}
|
||||
|
||||
<!-- Self hosted -->
|
||||
{{% codetab %}}
|
||||
|
||||
When running in self hosted mode, use the `--app-protocol` flag to tell Dapr to use gRPC to talk to the app:
|
||||
|
||||
|
|
@ -25,8 +26,10 @@ dapr run --app-protocol grpc --app-port 5005 node app.js
|
|||
```
|
||||
This tells Dapr to communicate with your app via gRPC over port `5005`.
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
### Kubernetes
|
||||
<!-- Kubernetes -->
|
||||
{{% codetab %}}
|
||||
|
||||
On Kubernetes, set the following annotations in your deployment YAML:
|
||||
|
||||
|
|
@ -52,5 +55,13 @@ spec:
|
|||
dapr.io/app-id: "myapp"
|
||||
dapr.io/app-protocol: "grpc"
|
||||
dapr.io/app-port: "5005"
|
||||
...
|
||||
```
|
||||
#...
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
## Next steps
|
||||
|
||||
{{< button text="Handle large HTTP header sizes" page="increase-read-buffer-size" >}}
|
||||
|
|
@ -1,20 +1,23 @@
|
|||
---
|
||||
type: docs
|
||||
title: "How-To: Handle large http header size"
|
||||
title: "How-To: Handle large HTTP header size"
|
||||
linkTitle: "HTTP header size"
|
||||
weight: 6000
|
||||
description: "Configure a larger http read buffer size"
|
||||
description: "Configure a larger HTTP read buffer size"
|
||||
---
|
||||
|
||||
Dapr has a default limit of 4KB for the http header read buffer size. When sending http headers that are bigger than the default 4KB, you can increase this value. Otherwise, you may encounter a `Too big request header` service invocation error. You can change the http header size by using the `dapr.io/http-read-buffer-size` annotation or `--dapr-http-read-buffer-size` flag when using the CLI.
|
||||
|
||||
Dapr has a default limit of 4KB for the HTTP header read buffer size. If you're sending HTTP headers larger than the default 4KB, you may encounter a `Too big request header` service invocation error.
|
||||
|
||||
You can increase the HTTP header size by using:
|
||||
- The `dapr.io/http-read-buffer-size` annotation, or
|
||||
- The `--dapr-http-read-buffer-size` flag when using the CLI.
|
||||
|
||||
{{< tabs Self-hosted Kubernetes >}}
|
||||
|
||||
<!--Self-hosted-->
|
||||
{{% codetab %}}
|
||||
|
||||
When running in self hosted mode, use the `--dapr-http-read-buffer-size` flag to configure Dapr to use non-default http header size:
|
||||
When running in self-hosted mode, use the `--dapr-http-read-buffer-size` flag to configure Dapr to use non-default http header size:
|
||||
|
||||
```bash
|
||||
dapr run --dapr-http-read-buffer-size 16 node app.js
|
||||
|
|
@ -23,10 +26,11 @@ This tells Dapr to set maximum read buffer size to `16` KB.
|
|||
|
||||
{{% /codetab %}}
|
||||
|
||||
|
||||
<!--Kubernetes-->
|
||||
{{% codetab %}}
|
||||
|
||||
On Kubernetes, set the following annotations in your deployment YAML:
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
|
|
@ -49,7 +53,7 @@ spec:
|
|||
dapr.io/app-id: "myapp"
|
||||
dapr.io/app-port: "8000"
|
||||
dapr.io/http-read-buffer-size: "16"
|
||||
...
|
||||
#...
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
|
@ -57,4 +61,8 @@ spec:
|
|||
{{< /tabs >}}
|
||||
|
||||
## Related links
|
||||
- [Dapr Kubernetes pod annotations spec]({{< ref arguments-annotations-overview.md >}})
|
||||
[Dapr Kubernetes pod annotations spec]({{< ref arguments-annotations-overview.md >}})
|
||||
|
||||
## Next steps
|
||||
|
||||
{{< button text="Handle large HTTP body requests" page="increase-request-size" >}}
|
||||
|
|
|
|||
|
|
@ -6,15 +6,16 @@ weight: 6000
|
|||
description: "Configure http requests that are bigger than 4 MB"
|
||||
---
|
||||
|
||||
By default Dapr has a limit for the request body size which is set to 4 MB, however you can change this by defining `dapr.io/http-max-request-size` annotation or `--dapr-http-max-request-size` flag.
|
||||
|
||||
|
||||
By default, Dapr has a limit for the request body size, set to 4MB. You can change this by defining:
|
||||
- The `dapr.io/http-max-request-size` annotation, or
|
||||
- The `--dapr-http-max-request-size` flag.
|
||||
|
||||
{{< tabs Self-hosted Kubernetes >}}
|
||||
|
||||
<!--self hosted-->
|
||||
{{% codetab %}}
|
||||
|
||||
When running in self hosted mode, use the `--dapr-http-max-request-size` flag to configure Dapr to use non-default request body size:
|
||||
When running in self-hosted mode, use the `--dapr-http-max-request-size` flag to configure Dapr to use non-default request body size:
|
||||
|
||||
```bash
|
||||
dapr run --dapr-http-max-request-size 16 node app.js
|
||||
|
|
@ -23,10 +24,11 @@ This tells Dapr to set maximum request body size to `16` MB.
|
|||
|
||||
{{% /codetab %}}
|
||||
|
||||
|
||||
<!--kubernetes-->
|
||||
{{% codetab %}}
|
||||
|
||||
On Kubernetes, set the following annotations in your deployment YAML:
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
|
|
@ -49,7 +51,7 @@ spec:
|
|||
dapr.io/app-id: "myapp"
|
||||
dapr.io/app-port: "8000"
|
||||
dapr.io/http-max-request-size: "16"
|
||||
...
|
||||
#...
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
|
@ -57,4 +59,9 @@ spec:
|
|||
{{< /tabs >}}
|
||||
|
||||
## Related links
|
||||
- [Dapr Kubernetes pod annotations spec]({{< ref arguments-annotations-overview.md >}})
|
||||
|
||||
[Dapr Kubernetes pod annotations spec]({{< ref arguments-annotations-overview.md >}})
|
||||
|
||||
## Next steps
|
||||
|
||||
{{< button text="Install sidecar certificates" page="install-certificates" >}}
|
||||
Loading…
Reference in New Issue