作者 | 劉林

前言

在實際生產(chǎn)環(huán)境中，許多場景需要進行策略控制，例如，不同團隊的API需要限制訪問權(quán)限，以避免未經(jīng)授權(quán)的網(wǎng)絡(luò)訪問。為實現(xiàn)這種控制，可以采用策略控制的方法。然而，實施策略控制需要修改代碼，而且策略通常很分散。為了解決這個問題，可以使用OPA（Open Policy Agent）進行策略控制。

OPA 可以通過定義的策略查詢輸入數(shù)據(jù)，并生成決策。例如：

• 控制哪些用戶可以訪問哪些資源
• 控制用戶是否有權(quán)訪問服務(wù)器或執(zhí)行某些操作
• 控制哪些項目/組件可以部署
• 控制如何訪問數(shù)據(jù)庫
• 控制哪些資源可以部署到 Kubernetes 中

OPA簡介及原理

OPA 是什么

OPA（Open Policy Agent）是一個開源的通用策略引擎，由 Styra 公司于2016年創(chuàng)建并開源，目前已是 CNCF 的畢業(yè)項目。其主要功能是將策略決策與應(yīng)用程序的業(yè)務(wù)邏輯分離，將策略看作一組規(guī)則。請求被發(fā)送到引擎后，引擎會根據(jù)規(guī)則來進行決策。OPA 并不負責(zé)具體任務(wù)的執(zhí)行，它僅負責(zé)決策。請求通過 JSON 方式傳遞給 OPA，決策結(jié)果也以 JSON 的形式返回。OPA將策略配置統(tǒng)一到一處，極大地降低維護成本，并將策略與對應(yīng)的軟件/服務(wù)解耦，方便進行移植和復(fù)用。

OPA 策略

OPA 中的策略是以 Rego 這種DSL(Domain Specific Language)來表示的。每個規(guī)則都是由頭部和主體組成。在 Rego 中，如果規(guī)則主體對于某些變量賦值為真，那么我們說規(guī)則頭為真?？梢酝ㄟ^絕對路徑引用任何加載到 OPA 中的規(guī)則來查詢它的值。規(guī)則的路徑總是：data.PACKAGE.RULE （規(guī)則生成的所有值都可以通過全局 data 變量進行查詢) 。如果有多個規(guī)則相同，則一旦匹配到一個為true的規(guī)則，就為true。下面的案例中有具體代碼，可在后面的章節(jié)詳細了解rego編寫。

OPA 原理

OPA 將策略執(zhí)行與決策解耦。當軟件需要做出決策時，它向OPA 查詢并提供結(jié)構(gòu)化數(shù)據(jù)（例如JSON）作為輸入。其工作原理如下圖所示：

• 請求達到OPA Server之后，OPA會將輸入的JSON數(shù)據(jù)作為數(shù)據(jù)源，并使用定義的規(guī)則進行查詢。
• OPA 將查詢的結(jié)果返回給Server端。
• Service端根據(jù)查詢的結(jié)果放行或拒絕request。

如何使用OPA

案例一：OPA 實現(xiàn)API權(quán)限控制

如果要實現(xiàn)放行角色為admin的用戶請求，并且所有人都能夠訪問路徑為/public的GET類型的API，我們可以探究一下OPA 如何實現(xiàn)這個需求：

規(guī)則代碼

文件名: policy.rego

文件名: input.json 

測試代碼

文件名: policy_test.rego

使用命令行驗證policy邏輯

如下命令使用input.json文件來驗證是否能滿足policy.rego文件中的data.policy.allow規(guī)則。

附：如只想查看最終結(jié)果，可加上--format raw參數(shù)，輸出如下

使用OPA server驗證policy邏輯

opa run 會啟動一個交互式 shell （ REPL） 。我們可以使用 REPL 來試驗策略和構(gòu)建策略。

“讀取-求值-輸出” 循環(huán)（Read-Eval-Print Loop，簡稱REPL）

我們也可以將策略直接加載進去，或者將 OPA 作為一個服務(wù)運行并通過 HTTP 執(zhí)行查詢。默認情況下，OPA 監(jiān)會監(jiān)聽在 8181 端口。

打開postman訪問 OPA server, postman信息如下

OPA策略執(zhí)行流程分析

下圖中的請求何滿足策略規(guī)則呢？

上圖請求表示，使用OPA Server中policy包中的allow規(guī)則校驗該請求。

(1) 查看第一條allow策略 

該策略中僅允許roles是admin的用戶執(zhí)行操作，查看我們postman中body數(shù)據(jù)，得知roles是developer，顧這條策略不滿足，OPA會繼續(xù)查看其他策略。

(2) 查看第二條allow策略

該策略中僅允許request path是/public開頭且請求方法是GET的請求, 滿足我們postman中的request內(nèi)容，顧該請求滿足策略要求。

案例二：OPA在Kubernetes中的使用案例

由于OPA應(yīng)用到Kubernetes中時，需要較多的Kubernetes基礎(chǔ)，這里想淡化對Kubernetes基礎(chǔ)的要求，所以使用Gatekeeper來集成Kubernetes。

Gatekeeper是一個開源的使用OPA來定義和執(zhí)行策略的系統(tǒng)

下文將實現(xiàn)不允許在default namespace中部署deployment資源的案例。

部署Gatekeeper到Kubernetes

Kubernetes中的策略

(1) 策略文件準備 

文件名：template.yaml

圖片

文件名：constraint.yaml

圖片

文件名nginx-app.yaml

(2) 創(chuàng)建策略 

驗證策略

(1) 嘗試在default namespace中創(chuàng)建deployment資源

嘗試創(chuàng)建資源的時候，會出現(xiàn)如下報錯，因為OPA策略中已經(jīng)指定，不允許在default namespace中創(chuàng)建deployment資源。 

(2) 嘗試在其他namespace中創(chuàng)建deployment資源

創(chuàng)建demo namespace，并嘗試在該namespace中創(chuàng)建deployment資源，可成功創(chuàng)建。

圖片

總結(jié)

• OPA是一個開放源代碼的通用策略引擎，將策略決策與應(yīng)用程序的業(yè)務(wù)邏輯分離。
• OPA將輸入的JSON數(shù)據(jù)作為數(shù)據(jù)源，使用定義的規(guī)則進行查詢，返回最終的結(jié)果（allow 或者 deny）。
• 目前基于OPA的產(chǎn)品有Gatekeeper， Styra。如果是項目使用的話，個人推薦使用Styra，因為Styra的策略和input數(shù)據(jù)是有可視化頁面的，使用和排錯成本較低。
• Rego是基于查詢進行斷言的語言，基于規(guī)則查詢結(jié)果，給出true或false的查詢語言。