Dapr 概念

• 1: 概述
• 2: 构建模块
• 3: 组件
• 4: 弹性
• 5: 应用和控制平面配置
• 6: 可观测性
• 7: 安全性
• 8: 隔离
• 9: Dapr 服务概述
• 9.1: Dapr sidecar (daprd) 概述
• 9.2: Dapr Operator 控制平面服务概述
• 9.3: Dapr Placement 控制平面服务概述
• 9.4: Dapr Scheduler 控制平面服务概述
• 9.5: Dapr Sentry 控制平面服务概述
• 9.6: Dapr Sidecar Injector 控制平面服务概述
• 10: Dapr术语和定义
• 11: 常见问题与解答
• 11.1: Dapr 常见问题解答
• 11.2: Dapr与服务网格

1 - 概述

Dapr 是一个便于移植的事件驱动运行时，帮助开发者轻松构建在云和边缘环境中运行的弹性应用，无论是无状态还是有状态的，并支持多种编程语言和开发框架。

支持任何语言、框架和环境

随着云技术的普及，传统的 Web + 数据库应用架构（如经典的三层设计）正逐渐向微服务架构转变，这些架构本质上是分布式的。开发微服务应用不应要求您成为分布式系统的专家。

这正是 Dapr 的优势所在。Dapr 将构建微服务应用的最佳实践转化为开放且独立的 API，称为构建块。Dapr 的构建块：

• 允许您使用任意语言和框架构建可移植的应用。
• 完全独立
• 在应用中使用的数量没有限制

通过 Dapr，您可以逐步将现有应用迁移到微服务架构，采用云原生模式，如扩展/缩减、弹性和独立部署。

Dapr 是平台无关的，这意味着您可以在以下环境中运行您的应用：

• 本地
• 任何 Kubernetes 集群
• 虚拟或物理机器
• Dapr 集成的其他托管环境

这使您能够构建可以在云和边缘运行的微服务应用。

云和边缘的微服务构建块

Dapr 提供分布式系统构建块，使您能够以标准方式构建微服务应用并部署到任何环境。

每个构建块 API 都是独立的，这意味着您可以在应用中使用任意数量的它们。

跨领域 API

除了其构建块，Dapr 还提供适用于您使用的所有构建块的跨领域 API。

Sidecar 架构

Dapr 以 sidecar 架构暴露其 HTTP 和 gRPC API，作为容器或进程，不需要应用代码包含任何 Dapr 运行时代码。这使得从其他运行时集成 Dapr 变得容易，同时提供应用逻辑的分离以提高支持性。

托管环境

Dapr 可以在多种环境中托管，包括：

• 在 Windows/Linux/macOS 机器上自托管用于本地开发和生产
• 在 Kubernetes 或物理或虚拟机集群上用于生产

自托管本地开发

在自托管模式中，Dapr 作为一个独立的 sidecar 进程运行，您的服务代码可以通过 HTTP 或 gRPC 调用。每个运行的服务都有一个 Dapr 运行时进程（或 sidecar），配置为使用状态存储、pub/sub、绑定组件和其他构建块。

您可以使用 Dapr CLI 在本地机器上运行启用 Dapr 的应用。在下图中，Dapr 的本地开发环境通过 CLI init 命令进行配置。通过入门示例尝试一下。

Kubernetes

Kubernetes 可以用于：

• 本地开发（例如，使用 minikube 和 k3S），或
• 在生产中。

在 Kubernetes 等容器托管环境中，Dapr 作为 sidecar 容器与应用容器在同一个 pod 中运行。

Dapr 的 dapr-sidecar-injector 和 dapr-operator 控制平面服务提供一流的集成：

• 在与服务容器相同的 pod 中启动 Dapr 作为 sidecar 容器
• 提供集群中 Dapr 组件更新的通知

dapr-sentry 服务是一个证书颁发机构，启用 Dapr sidecar 实例之间的相互 TLS 以实现安全数据加密，并通过 Spiffe 提供身份。有关 Sentry 服务的更多信息，请阅读安全概述

将启用 Dapr 的应用部署并运行到您的 Kubernetes 集群中，只需在部署方案中添加几个注释即可。访问 Dapr on Kubernetes 文档。

物理或虚拟机集群

Dapr 控制平面服务可以在生产中以高可用性（HA）模式部署到物理或虚拟机集群中。在下图中，actor Placement 和安全 Sentry 服务在三台不同的虚拟机上启动，以提供 HA 控制平面。为了为集群中运行的应用提供使用 DNS 的名称解析，Dapr 默认使用多播 DNS，但也可以选择支持 Hashicorp Consul 服务。

开发者语言 SDK 和框架

Dapr 提供多种 SDK 和框架，使您能够轻松地用您喜欢的语言开始使用 Dapr 进行开发。

Dapr SDK

为了使 Dapr 在不同语言中使用更自然，它还包括特定语言的 SDK：

• Go
• Java
• JavaScript
• .NET
• PHP
• Python

这些 SDK 通过类型化语言 API 暴露 Dapr 构建块的功能，而不是调用 http/gRPC API。这使您能够用您选择的语言编写无状态和有状态函数和 actor 的组合。由于这些 SDK 共享 Dapr 运行时，您可以获得跨语言的 actor 和函数支持。

开发者框架

Dapr 可以从任何开发者框架中使用。以下是一些已与 Dapr 集成的框架：

Web

集成和扩展

访问集成页面，了解 Dapr 对各种框架和外部产品的一流支持，包括：

• 公共云服务，如 Azure 和 AWS
• Visual Studio Code
• GitHub

为操作而设计

Dapr 是为操作和安全性而设计的。Dapr 的 sidecar、运行时、组件和配置都可以轻松且安全地管理和部署，以满足您组织的需求。

通过 Dapr CLI 安装的仪表板提供了一个基于 Web 的 UI，使您能够查看信息、查看日志等，以运行 Dapr 应用。

Dapr 支持监控工具，以便更深入地了解 Dapr 系统服务和 sidecar，而 Dapr 的可观测性功能提供了对您的应用的洞察，如跟踪和指标。

2 - 构建模块

构建模块 是一个 HTTP 或 gRPC API，可以从您的代码中调用，并使用一个或多个 Dapr 组件。Dapr 由一组 API 构建模块组成，并且可以扩展以添加新的构建模块。Dapr 的构建模块：

• 解决构建弹性微服务应用程序中的常见挑战
• 编码最佳实践和模式

下图展示了构建模块如何通过公共 API 暴露，并从您的代码中调用，使用组件来实现其功能。

Dapr 提供以下构建模块：

3 - 组件

Dapr 采用模块化设计，功能以组件形式提供。每个组件都有一个接口定义。所有组件都是可互换的，因此您可以用具有相同接口的另一个组件替换掉一个组件。

您可以通过以下方式贡献实现并扩展 Dapr 的组件接口功能：

• components-contrib 仓库
• 可插拔组件。

一个构建块可以使用任意组合的组件。例如，actors 和 state management 构建块都使用 state 组件。

另一个例子是，pub/sub 构建块使用 pub/sub 组件。

您可以使用 dapr components CLI 命令获取当前在托管环境中可用的组件列表。

组件规范

每个组件都有一个规范（或称为 spec）。组件在设计时通过一个 YAML 文件进行配置，该文件存储在以下位置之一：

• 您解决方案中的 components/local 文件夹，或
• 在调用 dapr init 时创建的 .dapr 文件夹中全局存储。

这些 YAML 文件遵循通用的 Dapr 组件架构，但每个文件都特定于组件规范。

重要的是要理解组件规范值，特别是规范 metadata，在相同组件类型的不同组件之间可能会有所不同，例如在不同的 state 存储之间，并且某些设计时规范值可以在运行时通过向组件的 API 发出请求来覆盖。因此，强烈建议查看 组件的规范，特别注意用于设置与组件交互的元数据的请求示例负载。

下图显示了每种组件类型的一些组件示例

内置和可插拔组件

Dapr 具有作为运行时一部分包含的内置组件。这些是由社区开发和捐赠的公共组件，并在每个版本中可用。

Dapr 还允许用户创建自己的私有组件，称为可插拔组件。这些组件是自托管的（进程或容器），不需要用 Go 编写，存在于 Dapr 运行时之外，并能够“插入”到 Dapr 中以利用构建块 API。

在可能的情况下，鼓励将内置组件捐赠给 Dapr 项目和社区。

然而，可插拔组件在您希望创建不包含在 Dapr 项目中的私有组件的场景中是理想的。 例如：

• 您的组件可能特定于您的公司或存在知识产权问题，因此无法包含在 Dapr 组件仓库中。
• 您希望将组件更新与 Dapr 发布周期解耦。

有关更多信息，请阅读 可插拔组件概述

热重载

启用 HotReload 功能后，组件可以在运行时“热重载”。 这意味着您可以在不重启 Dapr 运行时的情况下更新组件配置。 当在 Kubernetes API 中创建、更新或删除组件资源时，或者在自托管模式下更改 resources 目录中的文件时，会发生组件重载。 当组件更新时，组件首先关闭，然后使用新配置重新初始化。 在重载和重新初始化期间，组件在短时间内不可用。

可用组件类型

以下是 Dapr 提供的组件类型：

名称解析

名称解析组件与 service-invocation 构建块一起使用，以与托管环境集成并提供服务到服务的发现。例如，Kubernetes 名称解析组件与 Kubernetes DNS 服务集成，自托管使用 mDNS，VM 集群可以使用 Consul 名称解析组件。

• 名称解析组件列表
• 名称解析实现

Pub/sub 代理

Pub/sub 代理组件是消息代理，可以作为 发布和订阅 构建块的一部分传递消息到/从服务。

• Pub/sub 代理列表
• Pub/sub 代理实现

工作流

工作流 是定义可靠业务流程或数据流的自定义应用程序逻辑。工作流组件是运行该工作流的业务逻辑并将其状态存储到 state 存储中的工作流运行时（或引擎）。

状态存储

状态存储组件是数据存储（数据库、文件、内存），作为 state management 构建块的一部分存储键值对。

• 状态存储列表
• 状态存储实现

绑定

外部资源可以连接到 Dapr，以便触发应用程序上的方法或作为 bindings 构建块的一部分从应用程序调用。

• 支持的绑定列表
• 绑定实现

秘密存储

秘密 是您希望防止未经授权访问的任何私密信息。秘密存储用于存储可以在应用程序中检索和使用的秘密。

• 支持的秘密存储列表
• 秘密存储实现

配置存储

配置存储用于保存应用程序数据，应用程序实例可以在启动时读取这些数据或在发生更改时收到通知。这允许动态配置。

• 支持的配置存储列表
• 配置存储实现

锁

锁组件用作分布式锁，以提供对资源（如队列或数据库）的互斥访问。

• 支持的锁列表
• 锁实现

加密

加密 组件用于执行加密操作，包括加密和解密消息，而不将密钥暴露给您的应用程序。

• 支持的加密组件列表
• 加密实现

对话

Dapr 为开发人员提供了一种抽象与大型语言模型（LLMs）交互的方法，具有内置的安全性和可靠性功能。使用 conversation 组件将提示发送到不同的 LLMs，以及对话上下文。

• 支持的对话组件列表
• 对话实现

中间件

Dapr 允许自定义 中间件 插入到 HTTP 请求处理管道中。中间件可以在 HTTP 请求被路由到用户代码之前或响应返回给客户端之前对其执行额外的操作（如身份验证、加密和消息转换）。中间件组件与 service-invocation 构建块一起使用。

• 支持的中间件组件列表
• 中间件实现

4 - 弹性

分布式应用程序通常由许多微服务组成，这些微服务在底层基础设施上可以扩展到数十个甚至数百个实例。随着这些分布式解决方案的规模和复杂性增加，系统故障的可能性也随之增加。服务实例可能由于硬件故障、意外的吞吐量或应用程序生命周期事件（如扩展和重启）等多种问题而失败或无响应。因此，设计和实施能够检测、缓解和响应故障的自愈解决方案至关重要。

弹性策略

Dapr允许您为应用程序定义和应用容错的弹性策略。您可以为以下弹性模式设定策略：

• 超时
• 重试/退避
• 断路器

这些策略可以在调用具有弹性规范的组件时应用于任何Dapr API调用。

应用健康检查

应用程序可能由于多种原因变得无响应，例如过于繁忙无法接受新任务、崩溃或死锁。有时这些问题可能是暂时的，也可能是持久的。

Dapr提供了一种通过探测来检查应用程序健康状况并对状态变化做出反应的机制。当检测到应用不健康时，Dapr会停止为该应用分配新任务。

阅读更多关于如何将应用健康检查应用于您的应用程序。

Sidecar健康检查

Dapr提供了一种通过HTTP /healthz 端点来确定其健康状况的方法。通过此端点，daprd进程或sidecar可以：

• 检查其健康状况
• 确定其准备就绪状态和存活状态

阅读更多关于如何将dapr健康检查应用于您的应用程序。

下一步

• 了解更多关于弹性
• 尝试其中一个弹性快速入门：
  • 弹性：服务到服务
  • 弹性：状态管理

5 - 应用和控制平面配置

通过 Dapr 配置，您可以通过设置和策略来更改：

• 单个 Dapr 应用程序的行为
• Dapr 控制平面系统服务的全局行为

例如，您可以在应用程序的 sidecar 配置中设置采样率策略，以指定哪些方法可以被其他应用程序调用。如果您在 Dapr 控制平面配置中设置策略，您可以调整部署到应用程序 sidecar 实例的所有证书的更新周期。

配置以 YAML 文件的形式定义并部署。以下是一个应用程序配置示例，其中设置了一个跟踪端点，用于发送指标信息，并捕获所有的跟踪样本。

apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
  name: daprConfig
  namespace: default
spec:
  tracing:
    samplingRate: "1"
    zipkin:
      endpointAddress: "http://localhost:9411/api/v2/spans"

上述 YAML 配置用于记录指标的跟踪。您可以通过以下方式在本地自托管模式中加载它：

• 编辑 .dapr 目录中的默认配置文件 config.yaml，或
• 使用 kubectl/helm 将其应用到您的 Kubernetes 集群。

以下示例展示了在 dapr-system 命名空间中名为 daprsystem 的 Dapr 控制平面配置。

apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
  name: daprsystem
  namespace: dapr-system
spec:
  mtls:
    enabled: true
    workloadCertTTL: "24h"
    allowedClockSkew: "15m"

默认情况下，安装 Dapr 控制平面系统服务时会有一个名为 daprsystem 的单一配置文件。此配置文件应用全局控制平面设置，并在 Dapr 部署到 Kubernetes 时设置。

了解更多关于配置选项的信息。

下一步

6 - 可观测性

在构建应用程序时，理解系统行为是操作应用程序的重要且具有挑战性的部分，例如：

• 观察应用程序的内部调用
• 评估其性能
• 在问题发生时立即意识到

对于由多个微服务组成的分布式系统来说，这尤其具有挑战性，因为一个由多个调用组成的流程可能在一个微服务中开始并在另一个微服务中继续。

在生产环境中，应用程序的可观测性至关重要，并且在开发过程中也很有用，以便：

• 理解瓶颈
• 提高性能
• 在微服务范围内进行基本调试

虽然可以从底层基础设施（如内存消耗、CPU使用率）中收集一些关于应用程序的数据点，但其他有意义的信息必须从“应用程序感知层”收集——这个层可以显示重要调用系列如何在微服务之间执行。通常，您需要添加一些代码来对应用程序进行检测，这些代码将收集的数据（如追踪和指标）发送到可观测性工具或服务，这些工具或服务可以帮助存储、可视化和分析所有这些信息。

维护这些检测代码（它们不是应用程序核心逻辑的一部分）需要理解可观测性工具的API，使用额外的SDK等。这种检测也可能为您的应用程序带来可移植性挑战，要求根据应用程序的部署位置进行不同的检测。例如：

• 不同的云提供商提供不同的可观测性工具
• 本地部署可能需要自托管解决方案

使用Dapr实现应用程序的可观测性

当您利用Dapr API构建块进行服务间调用、发布/订阅消息传递和其他API时，Dapr在分布式追踪方面提供了优势。由于这种服务间通信通过Dapr运行时（或“sidecar”）流动，Dapr处于一个独特的位置，可以减轻应用程序级别检测的负担。

分布式追踪

Dapr可以使用广泛采用的Open Telemetry (OTEL)和Zipkin协议配置以发出追踪数据。这使得它可以轻松集成到多个可观测性工具中。

自动追踪上下文生成

Dapr使用W3C追踪规范作为追踪上下文的一部分，包含在Open Telemetry (OTEL)中，用于生成和传播应用程序的上下文头或传播用户提供的上下文头。这意味着您可以默认获得Dapr的追踪功能。

Dapr sidecar和控制平面的可观测性

您还可以通过以下方式观察Dapr本身：

• 生成由Dapr sidecar和Dapr控制平面服务发出的日志
• 收集性能、吞吐量和延迟的指标
• 使用健康端点探测来指示Dapr sidecar的健康状态

日志记录

Dapr生成日志以：

• 提供对sidecar操作的可见性
• 帮助用户识别问题并进行调试

日志事件包含由Dapr系统服务生成的警告、错误、信息和调试消息。您还可以配置Dapr将日志发送到收集器，如Open Telemetry Collector、Fluentd、New Relic、Azure Monitor和其他可观测性工具，以便可以搜索和分析日志以提供见解。

指标

指标是一系列测量值和计数，随着时间的推移被收集和存储。Dapr指标提供监控能力，以理解Dapr sidecar和控制平面的行为。例如，Dapr sidecar和用户应用程序之间的指标显示调用延迟、流量失败、请求错误率等。

Dapr 控制平面指标显示sidecar注入失败和控制平面服务的健康状况，包括CPU使用率、actor放置的数量等。

健康检查

Dapr sidecar公开了一个HTTP端点用于健康检查。通过这个API，用户代码或托管环境可以探测Dapr sidecar以确定其状态并识别sidecar准备就绪的问题。

相反，Dapr可以配置为探测您的应用程序的健康状况，并对应用程序健康状况的变化做出反应，包括停止pub/sub订阅和短路服务调用。

下一步

• 了解更多关于使用Dapr进行开发的可观测性
• 了解更多关于使用Dapr进行操作的可观测性

7 - 安全性

安全性是Dapr的核心。本文介绍了在分布式应用中使用Dapr时的安全特性和功能。这些可以分为以下几类：

• 使用service-invocation和pubsub API进行安全通信。
• 通过配置应用于组件的安全策略。
• 操作安全实践。
• 状态安全，专注于静态数据。

一个示例应用程序用于说明Dapr中可用的多种安全特性。

安全通信

Dapr通过service-invocation API提供端到端的安全性，支持应用程序身份验证并设置访问策略。下图展示了这一点。

service-invocation范围访问策略

Dapr应用程序可以被限定在命名空间中进行部署和安全管理。您可以在不同命名空间的服务之间进行调用。阅读跨命名空间的service-invocation以获取更多信息。

Dapr应用程序可以限制哪些操作可以被调用，包括哪些应用程序被允许（或拒绝）调用它。阅读如何：为service-invocation应用访问控制列表配置以获取更多信息。

pubsub主题范围访问策略

对于pubsub组件，您可以限制哪些主题类型和应用程序被允许发布和订阅特定主题。阅读范围pubsub主题访问以获取更多信息。

使用mTLS加密数据

Dapr使用的一种加密传输中数据的安全机制是双向认证TLS或mTLS。mTLS为应用程序内部的网络流量提供了一些关键特性：

• 双向认证，客户端和服务器相互验证身份。
• 加密通道，用于所有在途通信，在建立双向认证后。

mTLS在几乎所有场景中都很有用，尤其是对于需要遵循法规的系统，如HIPAA和PCI。

Dapr之间的安全通信

在生产系统中，Dapr无需额外代码或复杂配置即可启用mTLS。此外，Dapr sidecar默认只允许localhost访问，阻止其他IP地址，除非明确配置。

Dapr包含一个“默认开启”的自动mTLS，为Dapr sidecar之间的流量提供在途加密。为实现这一点，Dapr利用一个名为Sentry的系统服务，该服务充当证书颁发机构（CA）/身份提供者，并签署来自Dapr sidecar的工作负载（应用程序）证书请求。

默认情况下，工作负载证书有效期为24小时，时钟偏差设置为15分钟。

除非您提供了现有的根证书，否则Sentry服务会自动创建并持久化有效期为一年的自签名根证书。Dapr管理工作负载证书的轮换；如果您自带证书，Dapr会在不影响应用程序正常运行的情况下进行。

当根证书被替换时（Kubernetes模式下为secret，自托管模式下为文件系统），Sentry会获取它们并重建信任链，无需重启且对Sentry无停机时间。

当一个新的Dapr sidecar初始化时，它会检查是否启用了mTLS。如果是，则生成一个ECDSA私钥和证书签名请求，并通过gRPC接口发送给Sentry。Dapr sidecar和Sentry之间的通信使用信任链证书进行认证，该证书由Dapr Sidecar Injector系统服务注入到每个Dapr实例中。

配置mTLS

可以通过编辑Dapr部署的默认配置中的spec.mtls.enabled字段来开启/关闭mTLS。

您可以在Kubernetes和自托管模式下进行此操作。

自托管模式下的mTLS

下图显示了Sentry系统服务如何根据操作员提供的或由Sentry服务生成并存储在文件中的根/颁发者证书为应用程序颁发证书。

Kubernetes模式下的mTLS

在Kubernetes集群中，保存根证书的secret是：

• 限定在部署Dapr组件的命名空间中。
• 仅由Dapr控制平面系统pod访问。

Dapr在Kubernetes上部署时还支持强身份验证，依赖于作为证书签名请求（CSR）一部分发送给Sentry的pod的服务账户令牌。

下图显示了Sentry系统服务如何根据操作员提供的或由Sentry服务生成并存储为Kubernetes secret的根/颁发者证书为应用程序颁发证书。

防止Dapr被IP地址访问

为了防止Dapr sidecar在任何IP地址上被调用（尤其是在Kubernetes等生产环境中），Dapr将其监听IP地址限制为localhost。如果您需要启用外部地址的访问，请使用dapr-listen-addresses设置。

安全的Dapr到应用程序通信

Dapr sidecar通过localhost运行在应用程序附近，建议在与应用程序相同的网络边界内运行。虽然许多现代云原生系统将pod级别（例如在Kubernetes上）视为可信的安全边界，但Dapr通过令牌为应用程序提供API级别的身份验证。此功能保证，即使在localhost上：

• 只有经过身份验证的应用程序可以调用Dapr
• 应用程序可以检查Dapr是否在回调它

有关配置API令牌安全性的更多详细信息，请阅读：

• 使用API令牌对来自应用程序到Dapr的请求进行身份验证。
• 使用API令牌对来自Dapr到应用程序的请求进行身份验证

安全的Dapr到控制平面通信

除了Dapr sidecar之间的自动mTLS，Dapr还提供以下之间的强制mTLS：

• Dapr sidecar
• Dapr控制平面系统服务，即：
  • Sentry服务（证书颁发机构）
  • Placement服务（actor放置）
  • Kubernetes Operator服务

当启用mTLS时，Sentry将根和颁发者证书写入限定在安装控制平面的命名空间的Kubernetes secret中。在自托管模式下，Sentry将证书写入可配置的文件系统路径。

在Kubernetes中，当Dapr系统服务启动时，它们会自动挂载并使用包含根和颁发者证书的secret来保护Dapr sidecar使用的gRPC服务器。在自托管模式下，每个系统服务可以挂载到文件系统路径以获取凭据。

当Dapr sidecar初始化时，它使用挂载的叶证书和颁发者私钥对系统pod进行身份验证。这些作为环境变量挂载在sidecar容器上。

Kubernetes中到系统服务的mTLS

下图显示了Dapr sidecar与Dapr Sentry（证书颁发机构）、Placement（actor放置）和Kubernetes Operator系统服务之间的安全通信。

操作安全

Dapr设计用于让操作员管理mTLS证书并强制执行OAuth策略。

mTLS证书部署和轮换

虽然操作员和开发人员可以将自己的证书引入Dapr，但Dapr会自动创建并持久化自签名的根和颁发者证书。阅读设置和配置mTLS证书以获取更多信息。

使用OAuth进行中间件端点授权

使用Dapr OAuth 2.0中间件，您可以在Dapr端点上为您的API启用OAuth授权。阅读使用OAuth配置端点授权以获取详细信息。Dapr还有其他中间件组件，您可以用于OpenID Connect和OPA策略。有关更多详细信息，请阅读支持的中间件。

网络安全

您可以采用常见的网络安全技术，如网络安全组（NSG）、非军事区（DMZ）和防火墙，为您的网络资源提供多层保护。例如，除非配置为与外部绑定目标通信，否则Dapr sidecar不会打开到互联网的连接，并且大多数绑定实现仅使用出站连接。您可以设计防火墙规则，仅通过指定端口允许出站连接。

安全策略

Dapr有一套广泛的安全策略，您可以应用于您的应用程序。您可以通过sidecar配置中的策略设置或组件规范来限定它们能够做什么。

API访问策略

在某些场景中，例如在零信任网络中或通过前端将Dapr sidecar暴露给外部流量时，建议仅启用应用程序当前使用的Dapr sidecar API。这减少了攻击面，并将Dapr API限定在应用程序的实际需求范围内。您可以通过在配置中设置API允许列表来控制哪些API对应用程序可访问，如下图所示。

阅读如何：选择性启用Dapr sidecar上的Dapr API以获取更多信息。

secret范围访问策略

为了限制Dapr应用程序对secret的访问，您可以定义secret范围。在应用程序配置中添加一个secret范围策略，具有限制性权限。阅读如何：使用secret范围以获取更多信息。

组件应用程序范围访问策略和secret使用

Dapr组件可以被命名空间化。这意味着一个Dapr sidecar实例只能访问部署到相同命名空间的组件。阅读如何：使用命名空间将组件限定到一个或多个应用程序以获取更多信息。

Dapr通过允许您指定哪些应用程序可以使用特定组件并拒绝其他应用程序来提供组件的应用程序级别范围。阅读使用范围限制应用程序对组件的访问以获取更多信息。

Dapr组件可以使用Dapr的内置secret管理功能来管理secret。阅读secret存储概述和如何：在组件中引用secret以获取更多信息。

绑定安全性

与绑定目标的身份验证由绑定的配置文件配置。通常，您应该配置最低所需的访问权限。例如，如果您只从绑定目标读取，您应该将绑定配置为使用具有只读访问权限的帐户。

状态安全

状态存储静态加密

默认情况下，Dapr不会转换来自应用程序的状态数据。这意味着：

• Dapr不会尝试加密/解密状态数据
• 您的应用程序可以采用您选择的加密/解密方法，其中状态数据对Dapr保持不透明。

Dapr组件可以使用配置的身份验证方法与底层状态存储进行身份验证。许多状态存储实现使用官方客户端库，这些库通常使用与服务器的安全通信通道。

然而，应用程序状态通常需要在静态时加密，以在企业工作负载或受监管环境中提供更强的安全性。Dapr提供基于AES256的自动客户端状态加密。阅读如何：加密应用程序状态以获取更多信息。

Dapr运行时状态

Dapr运行时不存储任何静态数据，这意味着Dapr运行时对其操作没有任何状态存储的依赖，可以被视为无状态。

在示例应用程序中使用安全功能

下图显示了在Kubernetes上托管的示例应用程序中放置的许多安全功能。在示例中，Dapr控制平面、Redis状态存储和每个服务都被部署到它们自己的命名空间中。在Kubernetes上部署时，您可以使用常规的Kubernetes RBAC来控制管理活动的访问。

在应用程序中，请求由运行在其旁边的Dapr sidecar的入口反向代理接收。从反向代理开始，Dapr使用service-invocation调用服务A，然后将消息发布到服务B。服务B检索一个secret以读取和保存到Redis状态存储。

让我们逐一介绍每个安全功能，并描述它们如何保护此应用程序。

1. API令牌身份验证确保反向代理知道它正在与正确的Dapr sidecar实例通信。这可以防止将消息转发到除此Dapr sidecar之外的任何地方。
2. service-invocation mTLS用于反向代理和服务A之间的身份验证。服务A上配置的服务访问策略限制其仅接收来自反向代理的特定端点的调用，而不是其他服务。
3. 服务B使用pubsub主题安全策略来指示它只能接收从服务A发布的消息。
4. Redis组件定义使用组件范围安全策略来表示只有服务B被允许调用它。
5. 服务B限制Dapr sidecar仅使用pubsub、状态管理和secret API。所有其他API调用（例如，service-invocation）将失败。
6. 在配置中设置的secret安全策略限制了服务B可以访问的secret。在这种情况下，服务B只能读取连接到Redis状态存储组件所需的secret，而不能读取其他secret。
7. 服务B被部署到命名空间“B”，这进一步将其与其他服务隔离。即使在其上启用了service-invocation API，也不能因为与服务A在同一命名空间中而被意外调用。服务B必须在其组件YAML文件中显式设置Redis主机命名空间以调用“Redis”命名空间，否则此调用也会失败。
8. Redis状态存储中的数据在静态时被加密，并且只能使用正确配置的Dapr Redis状态存储组件读取。

威胁模型

威胁建模是一个过程，通过该过程：

• 可以识别和列举潜在威胁，如结构性漏洞或缺乏适当的保护措施。
• 可以优先考虑缓解措施。

Dapr的威胁模型如下。

安全审计

2023年9月

2023年9月，Dapr完成了由Ada Logics进行的安全审计。

审计是一次全面的安全审计，目标如下：

• 形式化Dapr的威胁模型
• 执行手动代码审查
• 根据形式化的威胁模型评估Dapr的模糊测试套件
• 进行Dapr的SLSA审查。

您可以在这里找到完整报告。

审计发现了7个问题，其中没有一个是高或关键严重性。一个CVE是由于Dapr组件贡献中的第三方依赖问题而分配的。

2023年6月

2023年6月，Dapr完成了由Ada Logics进行的模糊测试审计。

审计实现了以下目标：

• OSS-Fuzz集成
• 为Dapr创建了39个新的模糊测试器
• Dapr运行时、Kit和组件贡献的模糊测试覆盖
• 所有模糊测试器在审计完成后持续运行

您可以在这里找到完整报告。

审计期间发现了3个问题。

2021年2月

2021年2月，Dapr进行了由Cure53针对其1.0版本的第二次安全审计。

测试重点如下：

• 自上次审计以来的Dapr运行时代码库评估
• 访问控制列表
• secret管理
• 渗透测试
• 验证先前高/中问题的修复

您可以在这里找到完整报告。

在测试期间检测到并修复了一个高问题。

截至2021年2月16日，Dapr有0个关键问题，0个高问题，0个中问题，2个低问题，2个信息问题。

2020年6月

2020年6月，Dapr接受了来自Cure53的安全审计，这是一家CNCF批准的网络安全公司。

测试重点如下：

• Dapr运行时代码库评估
• Dapr组件代码库评估
• Dapr CLI代码库评估
• 权限提升
• 流量欺骗
• secret管理
• RBAC
• 验证基本假设：mTLS、范围、API身份验证
• 编排加固（Kubernetes）
• DoS攻击
• 渗透测试

完整报告可以在这里找到。

报告安全问题

访问此页面向Dapr维护者报告安全问题。

相关链接

操作安全

8 - 隔离

Dapr 的命名空间功能提供了隔离和多租户支持，增强了安全性。通常，应用程序和组件会被部署到命名空间中，以便在特定环境中实现隔离，例如在 Kubernetes 中。

Dapr 支持在以下场景中使用命名空间：应用程序之间的服务调用、访问组件、在消费者组中发送 pubsub 消息以及 actor 类型的部署。无论是在自托管模式还是 Kubernetes 模式下，命名空间隔离都受到支持。

要开始使用，请先创建并配置您的命名空间。

• 自托管
• Kubernetes

kubectl create namespace namespaceA
kubectl config set-context --current --namespace=namespaceA

了解如何在 Dapr 中全面使用命名空间：

• 服务调用命名空间
• 如何设置 pubsub 命名空间消费者组
• 组件：
  • 如何配置具有多个命名空间的 pubsub 组件
  • 将组件限定到一个或多个应用程序
• 命名空间的 actor

9 - Dapr 服务概述

Dapr 是一个开源项目，旨在简化微服务应用程序的构建过程。它提供了一系列构建模块，这些模块通过标准化的 API 进行访问，使开发人员能够轻松实现常见的分布式系统模式。

Dapr 的核心服务包括：

• Actor：Dapr 支持 actor 模型，方便开发人员实现有状态的 actor。
• Secret：Dapr 提供与机密信息存储的集成，帮助开发人员安全管理应用程序的敏感信息。
• Configuration：Dapr 提供配置管理功能，允许应用程序动态获取和更新配置。
• Service Invocation：Dapr 支持服务调用，使服务之间可以通过 HTTP 或 gRPC 进行通信。
• Pub/Sub：Dapr 支持发布/订阅模式，简化事件驱动的应用程序开发。
• Workflow：Dapr 提供工作流支持，帮助开发人员编排复杂的业务流程。
• Cryptography：Dapr 提供加密功能，帮助开发人员实现数据加密和解密。
• Bindings：Dapr 提供与外部系统的绑定集成，简化与外部服务的交互。
• Timer 和 Reminder：Dapr 提供定时器和提醒功能，帮助开发人员实现定时任务和提醒。
• Job：Dapr 支持任务调度，帮助开发人员管理和执行后台任务。
• Conversation：Dapr 提供对话支持，帮助开发人员实现对话式应用程序。
• State：Dapr 提供状态管理功能，帮助开发人员管理应用程序的状态。

通过这些服务，Dapr 使开发人员能够专注于业务逻辑，而不必担心底层基础设施的细节。

9.1 - Dapr sidecar (daprd) 概述

Dapr 采用 sidecar 模式，这意味着 Dapr API 运行在一个独立的进程中，即 Dapr sidecar，并与您的应用程序一起运行。Dapr sidecar 进程命名为 daprd，并根据托管环境以不同的方式启动。

Dapr sidecar 提供以下功能：

• 应用程序业务逻辑使用的 构建块 API
• 用于发现功能和设置属性的 元数据 API
• 用于检查健康状态和 sidecar 准备及存活状态的 健康 API

当应用程序在其配置的端口上可访问时，Dapr sidecar 即达到准备状态。在应用程序启动或初始化期间，应用程序暂时无法访问 Dapr 组件。

应用程序通过本地 http 或 gRPC 端点调用 sidecar API。

使用 dapr run 的自托管

在 自托管模式 下安装 Dapr 时，daprd 二进制文件会被下载并放置在用户主目录下（Linux/macOS 为 $HOME/.dapr/bin，Windows 为 %USERPROFILE%\.dapr\bin\）。

在自托管模式下，使用 Dapr CLI 的 run 命令 会启动 daprd 可执行文件，并运行您提供的应用程序可执行文件。这是在本地进行开发和测试等场景中运行 Dapr sidecar 的推荐方式。

您可以在 Dapr run 命令参考 中找到 CLI 提供的用于配置 sidecar 的各种参数。

在 Kubernetes 中使用 dapr-sidecar-injector

在 Kubernetes 上，Dapr 控制平面包括 dapr-sidecar-injector 服务，它监视带有 dapr.io/enabled 注释的新 pod，并在 pod 内注入一个包含 daprd 进程的容器。在这种情况下，可以通过注释传递 sidecar 参数，如 此表 中的 Kubernetes 注释 列所述。

直接运行 sidecar

在大多数情况下，您不需要显式运行 daprd，因为 sidecar 要么由 CLI（自托管模式）启动，要么由 dapr-sidecar-injector 服务（Kubernetes）启动。对于高级用例（如调试、脚本化部署等），可以直接启动 daprd 进程。

要获取所有可用参数的详细列表，请运行 daprd --help 或查看 此表，该表概述了 daprd 参数与 CLI 参数和 Kubernetes 注释的关系。

示例

1. 通过指定其唯一 ID 启动与应用程序一起的 sidecar。

   注意： --app-id 是必填字段，且不能包含点。

   daprd --app-id myapp
   

2. 指定您的应用程序正在监听的端口

   daprd --app-id myapp --app-port 5000
   

3. 如果您使用了多个自定义资源并希望指定资源定义文件的位置，请使用 --resources-path 参数：

   daprd --app-id myapp --resources-path <PATH-TO-RESOURCES-FILES>
   

4. 如果您已将组件和其他资源（例如，弹性策略、订阅或配置）组织到单独的文件夹或共享文件夹中，您可以指定多个资源路径：

   daprd --app-id myapp --resources-path <PATH-1-TO-RESOURCES-FILES> --resources-path <PATH-2-TO-RESOURCES-FILES>
   

5. 在运行应用程序时启用 Prometheus 指标收集

   daprd --app-id myapp --enable-metrics
   

6. 仅监听 IPv4 和 IPv6 回环

   daprd --app-id myapp --dapr-listen-addresses '127.0.0.1,[::1]'
   

9.2 - Dapr Operator 控制平面服务概述

在 Kubernetes 模式下运行 Dapr 时，一个运行 Dapr Operator 服务的 pod 负责管理 Dapr 组件的更新，并为 Dapr 提供 Kubernetes 服务端点。

运行 Operator 服务

Operator 服务是 dapr init -k 部署过程的一部分，或者可以通过 Dapr Helm charts 部署。有关在 Kubernetes 上运行 Dapr 的更多信息，请访问 Kubernetes 托管页面。

其他配置选项

Operator 服务提供了一些额外的配置选项。

注入器监控功能

Operator 服务包含一个 注入器监控功能，它会定期检查 Kubernetes 集群中所有运行的 pod，确保那些标记了 dapr.io/enabled=true 的 pod 中正确注入了 Dapr sidecar。这个功能主要用于解决 注入器服务未能成功将 sidecar（daprd 容器）注入 pod 的问题。

注入器监控功能在以下情况下可能会很有帮助：

• 从完全停止的 Kubernetes 集群中恢复。当集群完全停止后再启动时（包括在集群完全故障的情况下），pod 会以随机顺序重启。如果您的应用程序在 Dapr 控制平面（特别是注入器服务）准备好之前重启，Dapr sidecar 可能不会注入到您的应用程序的 pod 中，导致应用程序行为异常。

• 解决 sidecar 注入器可能出现的随机故障，例如注入器服务中的瞬时故障。

如果监控功能发现某个 pod 缺少 sidecar，而它本应该有一个，它会删除该 pod。然后 Kubernetes 会重新创建该 pod，并再次调用 Dapr sidecar 注入器。

注入器监控功能默认是禁用的。

您可以通过向 operator 命令传递 --watch-interval 标志来启用它，该标志可以取以下值之一：

• --watch-interval=0：禁用注入器监控功能（如果省略该标志，则为默认值）。
• --watch-interval=<interval>：启用注入器监控功能，并在给定的间隔检查所有 pod；间隔的值是一个包含单位的字符串。例如：--watch-interval=10s（每 10 秒）或 --watch-interval=2m（每 2 分钟）。
• --watch-interval=once：注入器监控功能仅在 Operator 服务启动时运行一次。

如果您使用 Helm，可以使用 dapr_operator.watchInterval 选项配置注入器监控功能，该选项的值与命令行标志相同。

当 Operator 服务以 HA（高可用性）模式运行且有多个副本时，注入器监控功能是安全的。在这种情况下，Kubernetes 会自动选举一个“领导”实例，该实例是唯一运行注入器监控服务的实例。

然而，在 HA 模式下，如果您将注入器监控功能配置为“once”运行，则每次 Operator 服务的一个实例被选为领导时，监控功能都会启动。这意味着，如果 Operator 服务的领导崩溃并选出新的领导，这将再次触发注入器监控功能。

观看此视频以了解注入器监控功能的概述：

GET http://localhost:<healthzPort>/placement/state

 curl localhost:8080/placement/state

{
    "hostList": [{
            "name": "198.18.0.1:49347",
            "namespace": "ns1",
            "appId": "actor1",
            "actorTypes": ["testActorType1", "testActorType3"],
            "updatedAt": 1690274322325260000
        },
        {
            "name": "198.18.0.2:49347",
            "namespace": "ns2",
            "appId": "actor2",
            "actorTypes": ["testActorType2"],
            "updatedAt": 1690274322325260000
        },
        {
            "name": "198.18.0.3:49347",
            "namespace": "ns2",
            "appId": "actor2",
            "actorTypes": ["testActorType2"],
            "updatedAt": 1690274322325260000
        }
    ],
    "tableVersion": 1
}

9.4 - Dapr Scheduler 控制平面服务概述

Dapr Scheduler 服务概述

Dapr Scheduler 服务用于作业调度，可以在自托管模式或Kubernetes上运行。

下图展示了如何通过作业 API 从您的应用程序调用 Scheduler 服务。Scheduler 服务跟踪的所有作业都存储在嵌入式 Etcd 数据库中。

actor 提醒

在 Dapr v1.15 之前，actor 提醒是通过 Placement 服务运行的。现在，默认情况下，SchedulerReminders 功能标志被设置为 true，您创建的所有新 actor 提醒都通过 Scheduler 服务运行，以提高其可扩展性。

当您部署 Dapr v1.15 时，所有现有的 actor 提醒会从 Placement 服务迁移到 Scheduler 服务。这是针对每种 actor 类型的一次性迁移操作。您可以通过在 actor 类型的应用程序配置文件中将 SchedulerReminders 标志设置为 false 来阻止此迁移。

自托管模式

Scheduler 服务的 Docker 容器作为 dapr init 的一部分自动启动。如果您在精简初始化模式下运行，也可以手动作为进程运行。

Kubernetes 模式

Scheduler 服务作为 dapr init -k 的一部分或通过 Dapr Helm 图表部署。您可以在高可用性模式下运行 Scheduler。了解更多关于在 Kubernetes 服务中设置高可用性模式的信息。

有关在 Kubernetes 上运行 Dapr 的更多信息，请访问Kubernetes 托管页面。

相关链接

了解更多关于作业 API 的信息。

9.5 - Dapr Sentry 控制平面服务概述

Dapr Sentry 服务概述

Dapr Sentry 服务负责管理服务之间的 mTLS，并作为证书颁发机构。它生成 mTLS 证书并将其分发给所有正在运行的 sidecar。这样，sidecar 可以通过加密的 mTLS 流量进行通信。有关更多信息，请阅读 sidecar-to-sidecar 通信概述。

自托管模式

Sentry 服务的 Docker 容器不会作为 dapr init 的一部分自动启动。不过，您可以按照 mutual TLS 的设置说明手动启动。

如果您在 slim-init 模式 下运行，也可以手动以进程的方式启动。

Kubernetes 模式

Sentry 服务可以通过 dapr init -k 或使用 Dapr Helm Chart 部署。有关在 Kubernetes 上运行 Dapr 的更多信息，请访问 Kubernetes 托管页面。

进一步阅读

• 安全概述
• 自托管模式
• Kubernetes 模式

11.2 - Dapr与服务网格

Dapr与服务网格的比较及协作

Dapr 采用 sidecar 架构，作为独立进程与应用程序并行运行，提供服务调用、网络安全和分布式追踪等功能。这常常引发一个问题：Dapr 与 Linkerd、Istio 和 Open Service Mesh 等服务网格解决方案相比如何？

Dapr与服务网格的比较

虽然 Dapr 和服务网格确实有一些功能重叠，但Dapr 不是一个服务网格。服务网格主要关注网络层面的问题，而 Dapr 则专注于为开发者提供构建微服务的工具。Dapr 是以开发者为中心的，而服务网格则是以基础设施为中心的。

通常情况下，开发者无需关心应用程序是否部署在包含服务网格的环境中，因为服务网格会自动处理网络流量。服务网格主要由系统运维人员管理和部署，而 Dapr 的构建块 API 则是供开发者在代码中直接使用的。

Dapr 与服务网格共享的一些常见功能包括：

• 使用 mTLS 加密进行安全的服务间通信
• 服务间的指标收集
• 服务间的分布式追踪
• 通过重试实现的弹性

值得注意的是，Dapr 提供基于名称的服务发现和调用，这对开发者来说非常友好。通过 Dapr 的 service-invocation API，开发者可以直接调用服务名称，而服务网格则处理 IP 地址和 DNS 地址等网络细节。然而，Dapr 不提供流量路由或流量拆分等功能，这些通常由应用程序的入口代理来解决。此外，Dapr 还提供其他应用程序级别的构建块，如状态管理、发布订阅消息传递、actor 模型等。

Dapr 与服务网格在可观测性（追踪和指标）方面也有所不同。服务网格在网络层面操作，追踪服务之间的网络调用，而 Dapr 则通过 service-invocation 实现这一点。此外，Dapr 通过将追踪 ID 写入 Cloud Events 信封，提供对发布订阅调用的可观测性。这意味着对于同时使用服务间调用和发布订阅进行通信的应用程序，Dapr 的指标和追踪范围更广。

下图展示了 Dapr 和服务网格提供的重叠功能和独特能力：

将Dapr与服务网格一起使用

Dapr 可以与服务网格协同工作。在两者同时部署的情况下，Dapr 和服务网格的 sidecar 都在应用程序环境中运行。在这种情况下，建议仅配置 Dapr 或服务网格来执行 mTLS 加密和分布式追踪。

观看这些来自 Dapr 社区电话会议的录音，展示了 Dapr 与不同服务网格一起运行的演示：

• Dapr 和 Linkerd的概述和演示
• 运行 Dapr 和 Istio的演示

何时使用Dapr或服务网格或两者

您应该使用 Dapr、服务网格还是两者？这取决于您的具体需求。例如，如果您希望使用 Dapr 的一个或多个构建块，如状态管理或发布订阅，并且仅考虑使用服务网格来增强网络安全或可观测性，您可能会发现仅使用 Dapr 就足够了。

通常，您会在有公司政策要求所有应用程序的网络流量必须加密的情况下，将服务网格与 Dapr 一起使用。例如，您可能仅在应用程序的一部分中使用 Dapr，而其他未使用 Dapr 的服务和进程也需要加密流量。在这种情况下，服务网格是更好的选择，您可能需要在服务网格上启用 mTLS 和分布式追踪，并在 Dapr 上禁用这些功能。

如果您需要流量拆分以进行 A/B 测试，使用服务网格会更有利，因为 Dapr 不提供这些功能。

在某些情况下，当您需要两者的独特功能时，您会发现同时利用 Dapr 和服务网格是有益的；如上所述，使用它们在一起没有限制。