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