Security

How Dapr is designed with security in mind

Security is fundamental to Dapr. This article describes the security features and capabilities when using Dapr in a distributed application. These can be divided into:

• Secure communication with service invocation and pub/sub APIs.
• Security policies on components and applied through configuration.
• Operational security practices.
• State security, focusing on data at rest.

An example application is used to illustrate many of the security features available in Dapr.

Secure communication

Dapr provides end-to-end security with the service invocation API, with the ability to authenticate an application with Dapr and set endpoint access policies. This is shown in the diagram below.

Service invocation scoping access policy

Dapr applications can be scoped to namespaces for deployment and security. You can call between services deployed to different namespaces. Read the Service invocation across namespaces article for more details.

Dapr applications can restrict which operations can be called, including which applications are allowed (or denied) to call it. Read How-To: Apply access control list configuration for service invocation for more details.

Pub/sub topic scoping access policy

For pub/sub components, you can limit which topic types and applications are allowed to publish and subscribe to specific topics. Read Scope Pub/Sub topic access for more details.

Encryption of data using mTLS

One of Dapr’s security mechanisms for encrypting data in transit is mutual authentication TLS or mTLS. mTLS offers a few key features for network traffic inside your application:

• Two way authentication, with the client proving its identity to the server, and vice-versa.
• An encrypted channel for all in-flight communication, after two-way authentication is established.

mTLS is useful in almost all scenarios, but especially for systems subject to regulations such as HIPAA and PCI.

Secure Dapr to Dapr communication

Dapr enables mTLS with no extra code or complex configuration inside your production systems. Equally, Dapr sidecars prevent all IP addresses by default other than localhost from calling it, unless explicitly listed.

Dapr includes an “on by default”, automatic mTLS that provides in-transit encryption for traffic between Dapr sidecars. To achieve this, Dapr leverages a system service named Sentry, which acts as a Certificate Authority (CA)/Identity Provider and signs workload (app) certificate requests originating from the Dapr sidecar.

By default, a workload certificate is valid for 24 hours and the clock skew is set to 15 minutes.

Unless you’ve provided existing root certificates, the Sentry service automatically creates and persists self-signed root certificates valid for one year. Dapr manages workload certificate rotation; if you bring your own certificates, Dapr does so with zero downtime to the application.

When root certificates are replaced (secret in Kubernetes mode and filesystem for self-hosted mode), Sentry picks them up and rebuilds the trust chain, without restart and with zero downtime to Sentry.

When a new Dapr sidecar initializes, it checks if mTLS is enabled. If so, an ECDSA private key and certificate signing request are generated and sent to Sentry via a gRPC interface. The communication between the Dapr sidecar and Sentry is authenticated using the trust chain certificate, which is injected into each Dapr instance by the Dapr Sidecar Injector system service.

Configuring mTLS

mTLS can be turned on/off by editing the default configuration deployed with Dapr via the spec.mtls.enabled field.

You can do this for both Kubernetes and self-hosted modes.

mTLS in self hosted mode

The diagram below shows how the Sentry system service issues certificates for applications based on the root/issuer certificate provided by an operator or generated by the Sentry service as stored in a file.

mTLS in Kubernetes mode

In a Kubernetes cluster, the secret that holds the root certificates is:

• Scoped to the namespace in which the Dapr components are deployed.
• Only accessible by the Dapr control plane system pods.

Dapr also supports strong identities when deployed on Kubernetes, relying on a pod’s Service Account token sent as part of the certificate signing request (CSR) to Sentry.

The diagram below shows how the Sentry system service issues certificates for applications based on the root/issuer certificate provided by an operator or generated by the Sentry service and stored as a Kubernetes secret

Preventing IP addresses on Dapr

To prevent Dapr sidecars from being called on any IP address (especially in production environments such as Kubernetes), Dapr restricts its listening IP addresses to localhost. Use the dapr-listen-addresses setting if you need to enable access from external addresses.

Secure Dapr to application communication

The Dapr sidecar runs close to the application through localhost, and is recommended to run under the same network boundary as the app. While many cloud-native systems today consider the pod level (on Kubernetes, for example) as a trusted security boundary, Dapr provides the app with API level authentication using tokens. This feature guarantees that, even on localhost:

• Only an authenticated application may call into Dapr
• An application can check that Dapr is calling it back

For more details on configuring API token security, read:

• Using an API token to authentication requests from an application to Dapr.
• Using an API token to authentication requests from Dapr to the application

Secure Dapr to control plane communication

In addition to automatic mTLS between Dapr sidecars, Dapr offers mandatory mTLS between:

• The Dapr sidecar
• The Dapr control plane system services, namely:
  • The Sentry service (a Certificate Authority)
  • The Placement service (actor placement)
  • The Kubernetes Operator service

When mTLS is enabled, Sentry writes the root and issuer certificates to a Kubernetes secret scoped to the namespace where the control plane is installed. In self-hosted mode, Sentry writes the certificates to a configurable file system path.

In Kubernetes, when Dapr system services start, they automatically mount and use the secret containing the root and issuer certs to secure the gRPC server used by the Dapr sidecar. In self-hosted mode, each system service can be mounted to a filesystem path to get the credentials.

When the Dapr sidecar initializes, it authenticates with the system pods using the mounted leaf certificates and issuer private key. These are mounted as environment variables on the sidecar container.

mTLS to system services in Kubernetes

The diagram below shows secure communication between the Dapr sidecar and the Dapr Sentry (Certificate Authority), Placement (actor placement), and the Kubernetes Operator system services.

Operational Security

Dapr is designed for operators to manage mTLS certificates and enforce OAuth policies.

mTLS Certificate deployment and rotation

While operators and developers can bring their own certificates into Dapr, Dapr automatically creates and persists self-signed root and issuer certificates. Read Setup & configure mTLS certificates for more details.

Middleware endpoint authorization with OAuth

With Dapr OAuth 2.0 middleware, you can enable OAuth authorization on Dapr endpoints for your APIs. Read Configure endpoint authorization with OAuth for details. Dapr has other middleware components that you can use for OpenID Connect and OPA Policies. For more details, read about supported middleware.

Network security

You can adopt common network security technologies, such as network security groups (NSGs), demilitarized zones (DMZs), and firewalls, to provide layers of protection over your networked resources. For example, unless configured to talk to an external binding target, Dapr sidecars don’t open connections to the internet and most binding implementations only use outbound connections. You can design your firewall rules to allow outbound connections only through designated ports.

Security policies

Dapr has an extensive set of security policies you can apply to your applications. You can scope what they are able to do, either through a policy setting in the sidecar configuration, or with the component specification.

API access policy

In certain scenarios, such as with 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 currently used by the app. This reduces the attack surface and keeps the Dapr APIs scoped to the actual needs of the application. You can control which APIs are accessible to the application by setting an API allow list in configuration, as shown in the diagram below.

Read How-To: Selectively enable Dapr APIs on the Dapr sidecar for more details.

Secret scoping access policy

To limit the Dapr application’s access to secrets, you can define secret scopes. Add a secret scope policy to the application configuration with restrictive permissions. Read How To: Use secret scoping for more details.

Component application scoping access policy and secret usage

Dapr components can be namespaced. That means a Dapr sidecar instance can only access the components that have been deployed to the same namespace. Read How-To: Scope components to one or more applications using namespaces for more details.

Dapr provides application-level scoping for components by allowing you to specify which applications can consume specific components and deny others. Read restricting application access to components with scopes for more details.

Dapr components can use Dapr’s built-in secret management capability to manage secrets. Read the secret store overview and How-To: Reference secrets in components for more details.

Bindings security

Authentication with a binding target is configured by the binding’s configuration file. Generally, you should configure the minimum required access rights. For example, if you only read from a binding target, you should configure the binding to use an account with read-only access rights.

State security

State store encryption at rest

By default Dapr doesn’t transform the state data from applications. This means:

• Dapr doesn’t attempt to encrypt/decrypt state data
• Your application can adopt encryption/decryption methods of your choice, where the state data remains opaque to Dapr.

Dapr components can use a configured authentication method to authenticate with the underlying state store. Many state store implementations use official client libraries that generally use secured communication channels with the servers.

However, application state often needs to get encrypted at rest to provide stronger security in enterprise workloads or regulated environments. Dapr provides automatic client-side state encryption based on AES256. Read How-To: Encrypt application state for more details.

Dapr Runtime state

The Dapr runtime does not store any data at rest, meaning that Dapr runtime has no dependency on any state stores for its operation and can be considered stateless.

Using security capabilities in an example application

The diagram below shows a number of security capabilities placed in an example application hosted on Kubernetes. In the example, the Dapr control plane, the Redis state store, and each of the services have been deployed to their own namespaces. When deploying on Kubernetes, you can use regular Kubernetes RBAC to control access to management activities.

In the application, requests are received by the ingress reverse-proxy which has a Dapr sidecar running next to it. From the reverse proxy, Dapr uses service invocation to call onto Service A, which then publishes a message to Service B. Service B retrieves a secret in order to read and save state to a Redis state store.

Let’s go over each of the security capabilities and describe how they are protecting this application.

1. API Token authentication ensures the reverse-proxy knows it is communicating with the correct Dapr sidecar instance. This prevents forwarding messages to anything except this Dapr sidecar.
2. Service invocation mTLS is used for authentication between the reverse proxy and Service A. A service access policy configured on Service A restricts it to only receive calls on a specific endpoint from the reverse proxy and no other services.
3. Service B uses a pub/sub topic security policy to indicate it can only receive messages published from Service A.
4. The Redis component definition uses a component scoping security policy to say only Service B is allowed to call it.
5. Service B restricts the Dapr sidecar to only use the pub/sub, state management, and secrets APIs. All other API calls (for example, service invocation) would fail.
6. A secrets security policy set in configuration restricts which secrets Service B can access. In this case, Service B can only read the secret needed to connect to the Redis state store component, and no others.
7. Service B is deployed to namespace “B”, which further isolates it from other services. Even if the service invocation API was enabled on it, it could not be called accidentally by being in the same namespace as Service A. Service B must explicitly set the Redis Host namespace in its component YAML file to call onto the “Redis” namespace, otherwise this call also fails.
8. The data in the Redis state store is encrypted at rest and can only be read using the correctly configured Dapr Redis state store component.

Threat model

Threat modeling is a process by which:

• Potential threats, like structural vulnerabilities or the absence of appropriate safeguards, can be identified and enumerated.
• Mitigation can be prioritized.

The Dapr threat model is below.

Security audit

September 2023

In September 2023, Dapr completed a security audit done by Ada Logics.

The audit was a holistic security audit with the following goals:

• Formalize a threat model of Dapr
• Perform manual code review
• Evaluate Daprs fuzzing suite against the formalized threat model
• Carry out a SLSA review of Dapr.

You can find the full report here.

The audit found 7 issues none of which were of high or critical severity. One CVE was assigned from an issue in a 3rd-party dependency to Dapr Components Contrib

June 2023

In June 2023, Dapr completed a fuzzing audit done by Ada Logics.

The audit achieved the following:

• OSS-Fuzz integration
• 39 new fuzzers for Dapr
• Fuzz test coverage for Dapr Runtime, Kit and Components-contrib
• All fuzzers running continuously after the audit has completed

You can find the full report here.

3 issues were found during the audit.

February 2021

In February 2021, Dapr went through a 2nd security audit targeting its 1.0 release by Cure53.

The test focused on the following:

• Dapr runtime codebase evaluation since last audit
• Access control lists
• Secrets management
• Penetration testing
• Validating fixes for previous high/medium issues

You can find the full report here.

One high issue was detected and fixed during the test.

As of February 16, 2021, Dapr has 0 criticals, 0 highs, 0 mediums, 2 lows, 2 infos.

June 2020

In June 2020, Dapr underwent a security audit from Cure53, a CNCF-approved cybersecurity firm.

The test focused on the following:

• Dapr runtime codebase evaluation
• Dapr components codebase evaluation
• Dapr CLI codebase evaluation
• Privilege escalation
• Traffic spoofing
• Secrets management
• RBAC
• Validating base assumptions: mTLS, scopes, API authentication
• Orchestration hardening (Kubernetes)
• DoS attacks
• Penetration testing

The full report can be found here.

Reporting a security issue

Visit this page to report a security issue to the Dapr maintainers.

Related links

Operational Security

Last modified October 11, 2024: Fixed typo (#4389) (fe17926)