How Dapr Secures Service Calls and Pub/Sub with mTLS and Access Policies

Security is the foundation of Dapr. This article explains Dapr's security features and capabilities for distributed applications, covering service invocation, component policies, operational practices, and state security.

Secure communication for service invocation and pub/sub APIs.

Component‑level security policies applied via configuration.

Operational security best practices.

State security focusing on static data.

Service Invocation Access Policy

Dapr provides end‑to‑end security for service calls. Applications can be restricted to a specific namespace, and calls can be made across namespaces using a fully qualified domain name (FQDN) that includes the target namespace.

Example of invoking a service in the same namespace:

localhost:3500/v1.0/invoke/nodeapp/method/neworder

Cross‑namespace invocation uses the FQDN format:

localhost:3500/v1.0/invoke/nodeapp.production/method/neworder

Access control policies are defined in a Dapr configuration file and applied to the sidecar of the called application. Policies consist of a defaultAction and optional per‑application rules based on TrustDomain, namespace, and app ID extracted from the SPIFFE identity.

Key concepts: TrustDomain – logical group that defines trust relationships. If omitted, the default public domain is used. App Identity – each app receives a SPIFFE ID (e.g., spiffe://<trustdomain>/ns/<namespace>/<appid>) which is used for policy matching.

Access control rules follow these principles:

If no policy is defined, all apps can call all methods.

If a global default action is not set but specific app policies exist, the default is to deny.

If a policy cannot verify the caller’s credentials, the global default action applies.

Mismatched trust domain or namespace causes the policy to be ignored and the global default to take effect.

Example scenario – deny all calls unless the caller matches trustDomain=public, namespace=default, and appId=app1:

apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
  name: appconfig
spec:
  accessControl:
    defaultAction: deny
    trustDomain: "public"
    policies:
    - appId: app1
      defaultAction: allow
      trustDomain: "public"
      namespace: "default"

Other scenarios illustrate fine‑grained control based on operations, HTTP verbs, and GRPC methods.

Pub/Sub Topic Scope Access Policy

For Pub/Sub components, Dapr allows you to restrict which applications can publish or subscribe to specific topics. Scopes can be defined at the component level and further refined with publishingScopes and subscriptionScopes metadata.

Example component configuration limiting publishing and subscribing:

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: pubsub
spec:
  type: pubsub.redis
  version: v1
  metadata:
  - name: redisHost
    value: "localhost:6379"
  - name: publishingScopes
    value: "app1=topic1;app2=topic2,topic3;app3="
  - name: subscriptionScopes
    value: "app2=;app3=topic1"

The above configuration permits app1 to publish only to topic1, app2 to publish to topic2 and topic3, while app3 cannot publish to any topic. Subscription scopes work similarly.

When allowedTopics is set, only the listed topics are allowed for any application unless overridden by specific scopes.

Local mTLS setup example (macOS M1):

# Download Sentry binary
wget https://github.com/dapr/dapr/releases/download/v1.8.4/sentry_darwin_arm64.tar.gz
 tar -xvf sentry_darwin_arm64.tar.gz

# Create cert directory
mkdir -p $HOME/.dapr/certs

# Run Sentry
./sentry --issuer-credentials $HOME/.dapr/certs --trust-domain cluster.local

Set environment variables to point to the generated certificates:

export DAPR_TRUST_ANCHORS=$(cat $HOME/.dapr/certs/ca.crt)
export DAPR_CERT_CHAIN=$(cat $HOME/.dapr/certs/issuer.crt)
export DAPR_CERT_KEY=$(cat $HOME/.dapr/certs/issuer.key)
export NAMESPACE=default

Start the Dapr sidecar for a Node.js app with mTLS enabled and the custom configuration:

daprd --app-id nodeapp --dapr-grpc-port 50002 --dapr-http-port 3501 \
  --metrics-port 9091 --log-level debug --app-port 3000 \
  --enable-mtls --sentry-address localhost:50001 \
  --config nodeappconfig.yaml

Start the Python app sidecar similarly, using its own configuration file.

In Kubernetes, the same configurations can be applied via ConfigMaps and referenced with the annotation dapr.io/config: "pythonappconfig" on the pod.