目前，為了確保合適的人員能夠訪問到合適的資源，我們需要對(duì)系統(tǒng)啟用適當(dāng)?shù)脑L問控制方式。不過，面對(duì)各種廣為熟悉的實(shí)現(xiàn)模型，構(gòu)建其后端服務(wù)的API授權(quán)體系，往往是一個(gè)不小的挑戰(zhàn)。在本文中，我們將討論如何使用開源的API網(wǎng)關(guān)--Apache APISIX（https://apisix.apache.org/）和開放策略代理（Open Policy Agent，OPA，https://www.openpolicyagent.org/docs/latest/)為自己的API啟用基于角色的訪問控制（Role-based access control，RBAC）授權(quán)模型。
什么是RBAC？
基于角色的訪問控制（RBAC，https://en.wikipedia.org/wiki/Role-based_access_control）和基于屬性的訪問控制（attribute-based access control，ABAC，https://en.wikipedia.org/wiki/Attribute-based_access_control）是兩種最常用的訪問控制模型，可用于管理計(jì)算機(jī)系統(tǒng)中的權(quán)限和對(duì)資源的訪問。通常，RBAC會(huì)根據(jù)用戶在組織中的角色職能與職責(zé)，向其分配權(quán)限。
也就是說，在RBAC中，角色是根據(jù)用戶的功能或職責(zé)定義的，并為這些角色分配相應(yīng)的權(quán)限。當(dāng)然，在實(shí)際運(yùn)營(yíng)中，我們時(shí)常會(huì)給用戶分配一到多個(gè)角色，以便他們繼承與這些角色相關(guān)聯(lián)的權(quán)限。例如，在API的上下文中，開發(fā)人員角色可能有權(quán)創(chuàng)建和更新API資源，而最終用戶角色只有讀取或執(zhí)行API資源的權(quán)限。而且，在RBAC中，策略是由用戶所分配的角色、他們有權(quán)執(zhí)行的操作、以及他們執(zhí)行操作時(shí)所需的資源等組合因素來定義的。如果說RBAC是根據(jù)用戶角色來分配權(quán)限的話，那么ABAC則是根據(jù)與用戶和資源所關(guān)聯(lián)的屬性來分配權(quán)限的。
什么是OPA？
作為一個(gè)策略引擎和一組工具，OPA提供了一種統(tǒng)一的方法，來橫跨整個(gè)分布式系統(tǒng)去執(zhí)行策略。它允許開發(fā)者從一個(gè)端點(diǎn)集中定義、管理和實(shí)施策略。通過將策略定義為代碼，OPA可以輕松地審查、編輯和回滾策略，從而促進(jìn)高效的策略管理。
如上圖所示，OPA提供了一種被稱為Rego（https://www.openpolicyagent.org/docs/latest/policy-language/）的聲明性語(yǔ)言。它允許您在整個(gè)技術(shù)棧中創(chuàng)建和實(shí)施各種策略。當(dāng)您向OPA請(qǐng)求某個(gè)政策決策時(shí)，它會(huì)使用您在文件中提供的規(guī)則和數(shù)據(jù)，來評(píng)估查詢并生成響應(yīng)，然后再將查詢的結(jié)果作為策略決策，發(fā)回給您。由于OPA將其所需的所有策略和數(shù)據(jù)都存儲(chǔ)在其內(nèi)部緩存之中，因此它可以快速地返回結(jié)果。下面是一個(gè)簡(jiǎn)單的OPA Rego文件示例：
package example
default allow = false
allow {
input.method == "GET"
input.path =="/api/resource"
input.user.role == "admin"
}如上面的代碼段所示，我們有一個(gè)名為“example”的包，它定義了一個(gè)名為“allow”的規(guī)則。該規(guī)則指定：如果輸入方法是“GET”，請(qǐng)求的路徑是/api/resource，并且用戶角色是“admin”，則允許該請(qǐng)求。也就是說，如果同時(shí)滿足這些條件，則“allow”規(guī)則將其評(píng)估為“真”，從而允許該請(qǐng)求繼續(xù)進(jìn)行。
為什么可針對(duì)RBAC使用OPA和API網(wǎng)關(guān)？
API網(wǎng)關(guān)提供了一個(gè)集中位置，來配置和管理API及其使用者。作為集中式身份驗(yàn)證網(wǎng)關(guān)，它有效地避免了讓每個(gè)單獨(dú)的服務(wù)，在其內(nèi)部實(shí)現(xiàn)身份驗(yàn)證的邏輯。另一方面，OPA通過為授權(quán)創(chuàng)建一個(gè)單獨(dú)的授權(quán)層，來將策略與代碼分離。而通過這種組合，您可以將API資源的權(quán)限添加到角色上，進(jìn)而為每個(gè)用戶角色都定義一組對(duì)于RBAC資源（由URI路徑來定義）的權(quán)限（GET、PUT、DELETE）。在下一節(jié)中，我們將學(xué)習(xí)如何使用兩者來實(shí)現(xiàn)RBAC。
如何使用OPA和Apache APISIX實(shí)現(xiàn)RBAC
在Apache APISIX中，您可以通過配置路由（https://apisix.apache.org/docs/apisix/terminology/route/）和插件（https://apisix.apache.org/docs/apisix/terminology/plugin/），來定義API的行為。具體而言，您可以使用APISIX的OPA插件（https://apisix.apache.org/docs/apisix/plugins/opa/），通過將請(qǐng)求轉(zhuǎn)發(fā)給OPA進(jìn)行決策，來執(zhí)行RBAC的相關(guān)策略。也就是說，OPA會(huì)根據(jù)用戶的角色和權(quán)限，實(shí)時(shí)做出授權(quán)決策。
假設(shè)我們有一個(gè)Conference API（https://conferenceapi.azurewebsites.net/），您可以在其中檢索/編輯活動(dòng)會(huì)話、主題、以及演講者信息。在授權(quán)方面，演講者只能閱讀自己的會(huì)話和主題，而管理員則可以添加/編輯更多會(huì)話和主題。而且，與會(huì)者可以通過POST請(qǐng)求，向/speaker/speakerId/session/feedback路徑留下他們針對(duì)演講者會(huì)議的反饋，而演講者只能通過請(qǐng)求相同URI的GET方法才能看到。下圖展示了整個(gè)場(chǎng)景：
1. API使用者會(huì)在API網(wǎng)關(guān)上使用其憑據(jù)（如：授權(quán)標(biāo)頭中的JWT令牌，https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization）來請(qǐng)求路由。
2. API網(wǎng)關(guān)將帶有JWT標(biāo)頭的使用者數(shù)據(jù)發(fā)送到OPA引擎。
3. OPA使用我們?cè)?rego文件中指定的策略（如：角色和權(quán)限），來評(píng)估使用者是否有權(quán)訪問資源。
4. 如果OPA決定為“允許”，則該請(qǐng)求將被轉(zhuǎn)發(fā)到上游的Conference服務(wù)。
接著，我們來安裝和配置APISIX，并在OPA中定義各項(xiàng)策略。
先決條件
- Docker（https://docs.docker.com/get-docker/），用于安裝容器化的etcd和APISIX。
- Curl（https://curl.se/），用于向APISIX Admin API發(fā)送請(qǐng)求。當(dāng)然，您也可以使用Postman（https://www.postman.com/）等工具與API進(jìn)行交互。
第 1 步：安裝Apache APISIX
APISIX可以使用以下腳本被輕松地安裝和快速啟動(dòng)：
curl -sL https://run.api7.ai/apisix/quickstart | sh第 2 步：配置后端服務(wù)（上游）
為了將請(qǐng)求路由到Conference API的后端服務(wù)，您需要通過Admin API（https://apisix.apache.org/docs/apisix/admin-api/）在Apache APISIX中添加上游服務(wù)器來進(jìn)行配置。請(qǐng)參見如下代碼：
curl http://127.0.0.1:9180/apisix/admin/upstreams/1
-X PUT -d '
{
"name":"Conferences API upstream",
"desc":"Register Conferences API as the upstream",
"type":"roundrobin",
"scheme":"https",
"nodes":{
"conferenceapi.azurewebsites.net:443":1
}
}'第 3 步：創(chuàng)建API使用者
接下來，我們使用用戶名Jack在Apache APISIX中創(chuàng)建一個(gè)使用者（即，一個(gè)新的發(fā)言人），并使用指定的密鑰為使用者設(shè)置jwt-auth（https://apisix.apache.org/docs/apisix/plugins/jwt-auth/）插件，以便使用者使用JSON Web Token（JWT，https://jwt.io/）進(jìn)行身份驗(yàn)證。請(qǐng)參見如下代碼：
curl http://127.0.0.1:9180/apisix/admin/consumers
-X PUT -d '
{
"username": "jack",
"plugins": {
"jwt-auth": {
"key": "user-key",
"secret": "my-secret-key"
}
}
}'第 4 步：創(chuàng)建公共端點(diǎn)以生成JWT令牌
您還需要設(shè)置一個(gè)使用public-api（https://apisix.apache.org/docs/apisix/plugins/public-api/）插件來生成和簽發(fā)令牌的新路由。此時(shí)，API網(wǎng)關(guān)會(huì)充當(dāng)身份提供者服務(wù)器（identity provider server）的角色，去驗(yàn)證由使用者Jack的密鑰所創(chuàng)建和驗(yàn)證的令牌。當(dāng)然，身份提供者也可以是諸如Google（https://developers.google.com/identity）、Okta（https://www.okta.com/）、Keycloak（https://www.keycloak.org/）和Ory Hydra（https://www.ory.sh/hydra/）等任何第三方服務(wù)。請(qǐng)參見如下代碼：
curl http://127.0.0.1:9180/apisix/admin/routes/jas
-X PUT -d '
{
"uri": "/apisix/plugin/jwt/sign",
"plugins": {
"public-api": {}
}
}'第 5 步：為API使用者申請(qǐng)一個(gè)新的JWT令牌
現(xiàn)在，我們可以使用已創(chuàng)建的公共端點(diǎn)，從API網(wǎng)關(guān)處為Jack獲取一個(gè)新的令牌了。如下curl命令便是使用Jack的憑據(jù)生成一個(gè)新令牌，并在負(fù)載中分配了角色和權(quán)限。
curl -G --data-urlencode 'payload={"role":"speaker","permission":"read"}' http://127.0.0.1:9080/apisix/plugin/jwt/sign?key=user-key -i
在運(yùn)行了上述命令后，您將收到一個(gè)新的令牌作為響應(yīng)。我們暫且將該令牌保存在某處，以便稍后使用它去訪問新的API網(wǎng)關(guān)端點(diǎn)。
第 6 步：創(chuàng)建新的插件配置
此步驟會(huì)涉及到配置APISIX的3個(gè)插件，分布是：proxy-rewrite（https://apisix.apache.org/docs/apisix/plugins/proxy-rewrite/）、jwt-auth（https://apisix.apache.org/docs/apisix/plugins/jwt-auth/）和OPA（https://apisix.apache.org/docs/apisix/plugins/opa/）插件。請(qǐng)參見如下代碼：
curl
"http://127.0.0.1:9180/apisix/admin/plugin_configs/1" -X PUT -d '
{
"plugins":{
"jwt-auth":{
},
"proxy-rewrite":{
"host":"conferenceapi.azurewebsites.net"
}
}
}'- proxy-rewrite插件被配置為將請(qǐng)求全部代理到conferenceapi.azurewebsites.net主機(jī)處。
- OPA身份驗(yàn)證插件被配置為使用在http://localhost:8181/v1/data/rbacExample上運(yùn)行的OPA策略引擎。此外，APISIX將所有與使用者相關(guān)的信息，都發(fā)送給OPA。我們需要在OPA的配置部分里添加.rego文件。
第 7 步：為Conference會(huì)話創(chuàng)建路由
最后一步是為Conferences API的演講者會(huì)話創(chuàng)建新的路由：
curl
"http://127.0.0.1:9180/apisix/admin/routes/1" -X PUT -d '
{
"name":"Conferences API speaker sessions route",
"desc":"Create a new route in APISIX for the Conferences
API speaker sessions",
"methods": ["GET", "POST"],
"uris":
["/speaker/*/topics","/speaker/*/sessions"],
"upstream_id":"1",
"plugin_config_id":1
}'上述負(fù)載包含了諸如：名稱、描述、方法、URI、上游ID和插件配置ID等路由信息。在本例中，路由被配置為處理兩個(gè)不同URI（/speaker/topics和/speaker/sessions）的GET和POST請(qǐng)求。其中，“upstream_id”字段指定了將處理該路由傳入請(qǐng)求的、上游服務(wù)的ID，而“plugin_config_id”字段則指定了將用于此路由的、插件配置的ID。
第 8 步：在沒有OPA的情況下測(cè)試設(shè)置
到目前為止，我們已經(jīng)為APISIX設(shè)置了所有必要的配置，以將傳入的請(qǐng)求定向到Conference API的各個(gè)端點(diǎn)上，并且只允許那些已被授權(quán)的API使用者使用。據(jù)此，在每次API使用者需要訪問端點(diǎn)時(shí)，他們都必須提供JWT令牌，以從Conference后端服務(wù)中檢索到數(shù)據(jù)。您可以通過點(diǎn)擊端點(diǎn)來對(duì)此進(jìn)行驗(yàn)證。在此，我們所請(qǐng)求的域地址是自定義API網(wǎng)關(guān)，而不是實(shí)際的Conference服務(wù)：
curl -i http://127.0.0.1:9080/speaker/1/topics -H
'Authorization: {API_CONSUMER_TOKEN}'第 9 步：運(yùn)行OPA服務(wù)
接著，我們使用Docker來運(yùn)行OPA服務(wù)，并使用其API來上傳我們的策略定義。該API可用于評(píng)估各個(gè)傳入請(qǐng)求的授權(quán)策略。
docker run -d --network=apisix-quickstart-net
--name opa -p 8181:8181 openpolicyagent/opa:latest run -s上述Docker命令啟動(dòng)了一個(gè)具有最新版本的OPA鏡像容器。它在現(xiàn)有的APISIX網(wǎng)絡(luò)apisix-quickstart-net上，創(chuàng)建了一個(gè)名為OPA，并公開了端口8181的新容器。因此，APISIX可以直接使用地址--[http://opa:8181](http://opa:8181)，向OPA發(fā)送策略檢查請(qǐng)求。注意OPA和APISIX應(yīng)該運(yùn)行在同一個(gè)Docker網(wǎng)絡(luò)中。
第 10 步：定義和注冊(cè)策略
OPA端的下一步是需要定義將用于控制對(duì)API資源進(jìn)行訪問的策略。這些策略應(yīng)定義訪問所需的屬性（如：哪些用戶具有哪些角色）、以及基于這些屬性允許或拒絕的權(quán)限（如：哪些角色具有哪些權(quán)限）。舉例而言，在下面的配置中，我們要求OPA檢查表user_roles，以找到角色Jack。這些信息是由APISIX內(nèi)部的input.consumer.username發(fā)送的。我們據(jù)此通過讀取JWT的有效載荷，并從中提取token.payload.permission，來驗(yàn)證使用者的權(quán)限。如下注釋清楚地描述了這些步驟。
curl -X PUT
'127.0.0.1:8181/v1/policies/rbacExample' \
-H
'Content-Type: text/plain' \
-d
'package rbacExample
# Assigning user rolesuser_roles := {
"jack": ["speaker"],
"bobur":["admin"]
}
# Role permission assignments
role_permissions := {
"speaker": [{"permission": "read"}],
"admin":
[{"permission": "read"}, {"permission":
"write"}]
}
# Helper JWT Functions
bearer_token := t {
t :=
input.request.headers.authorization
}
# Decode the authorization token to get a role and
permission
token = {"payload": payload} {
[_, payload,
_] := io.jwt.decode(bearer_token)
}
# Logic that implements RBAC
default allow = falseallow {
# Lookup
the list of roles for the user
roles :=
user_roles[input.consumer.username] #
For each role in that list
r :=
roles[_] # Lookup the permissions list
for role r
permissions := role_permissions[r]
# For each permission
p :=
permissions[_] # Check if the
permission granted to r matches the users request
p ==
{"permission": token.payload.permission}
}'步驟 11：使用OPA插件更新現(xiàn)有插件配置
一旦在OPA服務(wù)上定義了各項(xiàng)策略，我們就需要更新現(xiàn)有的插件配置，以便路由去使用OPA插件。如下代碼段所示，我們需要在OPA插件的policy屬性中來指定。
curl
"http://127.0.0.1:9180/apisix/admin/plugin_configs/1" -X PATCH -d '
{
"plugins":{
"opa":{
"host":"http://opa:8181",
"policy":"rbacExample",
"with_consumer":true
}
}
}'第 12 步：使用OPA測(cè)試設(shè)置
至此，我們可以使用OPA策略對(duì)所有設(shè)置進(jìn)行測(cè)試了。一旦您運(yùn)行如下curl命令去訪問API網(wǎng)關(guān)端點(diǎn)，它會(huì)首先在身份驗(yàn)證過程中檢查JWT令牌，然后在授權(quán)過程中，將使用者和JWT令牌的數(shù)據(jù)發(fā)送到OPA處，以驗(yàn)證角色和權(quán)限。顯然，任何沒有JWT令牌，或不具備已允許角色的請(qǐng)求，都會(huì)被拒絕掉。
curl -i http://127.0.0.1:9080/speaker/1/topics -H
'Authorization: {API_CONSUMER_TOKEN}'小結(jié)
在本文中，我們通過自定義一個(gè)簡(jiǎn)單的策略邏輯，展示了如何根據(jù)API使用者的角色和權(quán)限，來允許或禁止API資源的訪問。同時(shí)，我們也演示了如何從APISIX發(fā)送的JWT令牌負(fù)載、或使用者的對(duì)象中，提取策略文件里與API使用者相關(guān)的信息，以最終實(shí)現(xiàn)OPA和Apache APISIX的RBAC效果。
譯者介紹
陳峻 （Julian Chen），51CTO社區(qū)編輯，具有十多年的IT項(xiàng)目實(shí)施經(jīng)驗(yàn)，善于對(duì)內(nèi)外部資源與風(fēng)險(xiǎn)實(shí)施管控，專注傳播網(wǎng)絡(luò)與信息安全知識(shí)與經(jīng)驗(yàn)。
原文標(biāo)題：RBAC With API Gateway and Open Policy Agent (OPA) ，作者：Bobur Umurzokov
鏈接：https://dzone.com/articles/rbac-with-api-gateway-and-open-policy-agentopa
