How-To: Selectively enable Dapr APIs on the Dapr sidecar

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.

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:

  1. apiVersion: dapr.io/v1alpha1
  2. kind: Configuration
  3. metadata:
  4. name: myappconfig
  5. namespace: default
  6. spec:
  7. tracing:
  8. 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:

  1. apiVersion: dapr.io/v1alpha1
  2. kind: Configuration
  3. metadata:
  4. name: myappconfig
  5. namespace: default
  6. spec:
  7. api:
  8. allowed:
  9. - name: state
  10. version: v1.0
  11. protocol: http

Enabling specific gRPC APIs

The following example enables the state v1 gRPC API and blocks all other gRPC APIs:

  1. apiVersion: dapr.io/v1alpha1
  2. kind: Configuration
  3. metadata:
  4. name: myappconfig
  5. namespace: default
  6. spec:
  7. api:
  8. allowed:
  9. - name: state
  10. version: v1
  11. protocol: grpc

Using a denylist

Disabling specific HTTP APIs

The following example disables the state v1.0 HTTP API, allowing all other HTTP APIs:

  1. apiVersion: dapr.io/v1alpha1
  2. kind: Configuration
  3. metadata:
  4. name: myappconfig
  5. namespace: default
  6. spec:
  7. api:
  8. denied:
  9. - name: state
  10. version: v1.0
  11. protocol: http

Disabling specific gRPC APIs

The following example disables the state v1 gRPC API, allowing all other gRPC APIs:

  1. apiVersion: dapr.io/v1alpha1
  2. kind: Configuration
  3. metadata:
  4. name: myappconfig
  5. namespace: default
  6. spec:
  7. api:
  8. denied:
  9. - name: state
  10. version: v1
  11. 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 groupHTTP APIgRPC API
Service Invocationinvoke (v1.0)invoke (v1)
Statestate (v1.0 and v1.0-alpha1)state (v1 and v1alpha1)
Pub/Subpublish (v1.0 and v1.0-alpha1)publish (v1 and v1alpha1)
(Output) Bindingsbindings (v1.0)bindings (v1)
Secretssecrets (v1.0)secrets (v1)
Actorsactors (v1.0)actors (v1)
Metadatametadata (v1.0)metadata (v1)
Configurationconfiguration (v1.0 and v1.0-alpha1)configuration (v1 and v1alpha1)
Distributed Locklock (v1.0-alpha1)
unlock (v1.0-alpha1)
lock (v1alpha1)
unlock (v1alpha1)
Cryptographycrypto (v1.0-alpha1)crypto (v1alpha1)
Workflowworkflows (v1.0-alpha1)workflows (v1alpha1)
Healthhealthz (v1.0)n/a
Shutdownshutdown (v1.0)shutdown (v1)

Last modified June 19, 2023: Merge pull request #3565 from dapr/aacrawfi/skip-secrets-close (b1763bf)