大型項目中基本都包含有復雜的訪問控制策略，特別是在一些多租戶場景中，例如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