The documentation you are viewing is for Dapr v1.12 which is an older version of Dapr. For up-to-date documentation, see the latest version.
How-To: Selectively enable Dapr APIs on the Dapr sidecar
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.
Dapr allows developers to control which APIs are accessible to the application by setting an API allowlist or denylist using a Dapr Configuration.
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 neither is defined, all APIs are allowed.
For example, the following configuration enables all APIs for both HTTP and gRPC:
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: myappconfig
namespace: default
spec:
tracing:
samplingRate: "1"
Using an allowlist
Enabling specific HTTP APIs
The following example enables the state v1.0
HTTP API and blocks all other HTTP APIs:
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: myappconfig
namespace: default
spec:
api:
allowed:
- name: state
version: v1.0
protocol: http
Enabling specific gRPC APIs
The following example enables the state v1
gRPC API and blocks all other gRPC APIs:
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: myappconfig
namespace: default
spec:
api:
allowed:
- name: state
version: v1
protocol: grpc
Using a denylist
Disabling specific HTTP APIs
The following example disables the state v1.0
HTTP API, allowing all other HTTP APIs:
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: myappconfig
namespace: default
spec:
api:
denied:
- name: state
version: v1.0
protocol: http
Disabling specific gRPC APIs
The following example disables the state v1
gRPC API, allowing all other gRPC APIs:
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: myappconfig
namespace: default
spec:
api:
denied:
- name: state
version: v1
protocol: grpc
List of Dapr APIs
The name
field takes the name of the Dapr API you would like to enable.
See this list of values corresponding to the different Dapr APIs:
API group | HTTP API | gRPC API |
---|---|---|
Service Invocation | invoke (v1.0 ) |
invoke (v1 ) |
State | state (v1.0 and v1.0-alpha1 ) |
state (v1 and v1alpha1 ) |
Pub/Sub | publish (v1.0 and v1.0-alpha1 ) |
publish (v1 and v1alpha1 ) |
(Output) Bindings | bindings (v1.0 ) |
bindings (v1 ) |
Secrets | secrets (v1.0 ) |
secrets (v1 ) |
Actors | actors (v1.0 ) |
actors (v1 ) |
Metadata | metadata (v1.0 ) |
metadata (v1 ) |
Configuration | configuration (v1.0 and v1.0-alpha1 ) |
configuration (v1 and v1alpha1 ) |
Distributed Lock | lock (v1.0-alpha1 )unlock (v1.0-alpha1 ) |
lock (v1alpha1 )unlock (v1alpha1 ) |
Cryptography | crypto (v1.0-alpha1 ) |
crypto (v1alpha1 ) |
Workflow | workflows (v1.0-alpha1 ) |
workflows (v1alpha1 ) |
Health | healthz (v1.0 ) |
n/a |
Shutdown | shutdown (v1.0 ) |
shutdown (v1 ) |
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.