大型项目中基本都包含有复杂的访问控制策略，特别是在一些多租户场景中，例如Kubernetes中就支持RBAC，ABAC等多种授权类型。Dapr 的 中间件 Open Policy Agent 将Rego/OPA策略应用到传入的Dapr HTTP请求中。

Open Policy Agent

Open Policy Agent(简称OPA)是一个开源的策略引擎，托管于CNCF，通常用来做在微服务、API网关、Kubernetes、CI/CD等系统中做策略管理。

OPA将策略从代码中分离出来，按照官网的说法OPA实现了策略即代码，通过Rego声明式语言实现决策逻辑，当系统需要做出策略时，只需携带请求查询OPA即可，OPA会返回决策结果。

OPA 通过评估查询输入并对照策略和数据来生成决策。OPA 和 Rego 是不分领域的，所以你可以在策略中描述几乎任何事件。比如：

• 哪些用户可以访问哪些资源。

• 哪些子网允许出口流量进入。

• 工作负载必须部署到哪个集群。

• 哪些注册表可以下载二进制文件。

• 容器可以用哪些操作系统的能力来执行。

• 系统在一天中的哪些时间可以被访问。

• 政策决定不限于简单的是/否或允许/拒绝的答案。像查询输入一样，你的策略可以生成任意的结构化数据作为输出。

OPA 的策略可以用 Rego 编写，这是一种专门为 OPA 设计的语言。类似于 JavaScript，OPA 使其非常容易将规则转换为有效的 OPA 策略。

那么我们为什么需要OPA?

大型软件中各个组件都需要进行一些策略控制，比如用户权限校验、创建资源校验、某个时间段允许访问，如果每个组件都需要实现一套策略控制，那么彼此之间会不统一，维护困难。一个自然的想法是能否将这些策略逻辑抽离出来，形成一个单独的服务，同时这个服务可能需要提供各种不同sdk来屏蔽语言差异。

OPA正是解决这个问题，将散落在系统各处的策略进行统一，所有服务直接请求OPA即可。通过引入OPA可以降低系统耦合性，减少维护复杂度。

Http API中使用OPA授权

我们在Dapr 实现的Http服务中 引入OPA来实现Http API授权。示例代码见：https://github.com/geffzhang/dapr-opa-test， 这将导致 foo 服务在调用服务bar-service的方法，该方法被为bar-service配置的 OPA 策略阻止

首先需要实现策略，拒绝所有访问HTTP 请求，通过Rego实现如下：

apiVersion: dapr.io/v1alpha1

kind: Component

metadata:

name: poc-opa

spec:

type: middleware.http.opa

version: v1

metadata:

    - name: rego

value: |

        package http

        default allow = false