大型项目中基本都包含有复杂的访问控制策略，特别是在一些多租户场景中，例如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
