作者 | 劉林

前言

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

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

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

OPA簡(jiǎn)介及原理

OPA 是什么

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

OPA 策略

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

OPA 原理

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

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

如何使用OPA

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

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

規(guī)則代碼

文件名: policy.rego

文件名: input.json 

測(cè)試代碼

文件名: policy_test.rego

使用命令行驗(yàn)證policy邏輯

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

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

使用OPA server驗(yàn)證policy邏輯

opa run 會(huì)啟動(dòng)一個(gè)交互式 shell （ REPL） 。我們可以使用 REPL 來(lái)試驗(yàn)策略和構(gòu)建策略。

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

我們也可以將策略直接加載進(jìn)去，或者將 OPA 作為一個(gè)服務(wù)運(yùn)行并通過(guò) HTTP 執(zhí)行查詢(xún)。默認(rèn)情況下，OPA 監(jiān)會(huì)監(jiān)聽(tīng)在 8181 端口。

打開(kāi)postman訪問(wèn) OPA server, postman信息如下

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

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

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

(1) 查看第一條allow策略 

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

(2) 查看第二條allow策略

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

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

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

Gatekeeper是一個(gè)開(kāi)源的使用OPA來(lái)定義和執(zhí)行策略的系統(tǒng)

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

部署Gatekeeper到Kubernetes

Kubernetes中的策略

(1) 策略文件準(zhǔn)備 

文件名：template.yaml

圖片

文件名：constraint.yaml

圖片

文件名nginx-app.yaml

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

驗(yàn)證策略

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

嘗試創(chuàng)建資源的時(shí)候，會(huì)出現(xiàn)如下報(bào)錯(cuò)，因?yàn)镺PA策略中已經(jīng)指定，不允許在default namespace中創(chuàng)建deployment資源。 

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

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

圖片

總結(jié)

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