目前，為了確保合適的人員能夠訪問到合適的資源，我們需要對系統啟用適當的訪問控制方式。不過，面對各種廣為熟悉的實現模型，構建其後端服務的API授權體系，往往是一個不小的挑戰。在本文中，我們將討論如何使用開源的API網關--Apache APISIX（https://apisix.apache.org/）和開放策略代理（Open Policy Agent，OPA，https://www.openpolicyagent.org/docs/latest/ )為自己的API啟用基於角色的訪問控制（Role-based access control，RBAC）授權模型。

什麼是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）是兩種最常用的訪問控制模型，可用於管理計算機系統中的權限和對資源的訪問。通常，RBAC會根據用戶在組織中的角色職能與職責，向其分配權限。

也就是說，在RBAC中，角色是根據用戶的功能或職責定義的，並為這些角色分配相應的權限。當然，在實際運營中，我們時常會給用戶分配一到多個角色，以便他們繼承與這些角色相關聯的權限。例如，在API的上下文中，開發人員角色可能有權創建和更新API資源，而最終用戶角色只有讀取或執行API資源的權限。而且，在RBAC中，策略是由用戶所分配的角色、他們有權執行的操作、以及他們執行操作時所需的資源等組合因素來定義的。如果說RBAC是根據用戶角色來分配權限的話，那麼ABAC則是根據與用戶和資源所關聯的屬性來分配權限的。

什麼是OPA？

作為一個策略引擎和一組工具，OPA提供了一種統一的方法，來橫跨整個分佈式系統去執行策略。它允許開發者從一個端點集中定義、管理和實施策略。通過將策略定義為代碼，OPA可以輕鬆地審查、編輯和回滾策略，從而促進高效的策略管理。

如上圖所示，OPA提供了一種被稱為Rego（https://www.openpolicyagent.org/docs/latest/policy-language/）的聲明性語言。它允許您在整個技術棧中創建和實施各種策略。當您向OPA請求某個政策決策時，它會使用您在文件中提供的規則和數據，來評估查詢並生成響應，然後再將查詢的結果作為策略決策，發回給您。由於OPA將其所需的所有策略和數據都存儲在其內部緩存之中，因此它可以快速地返回結果。下面是一個簡單的OPA Rego文件示例：

package example

default allow = false
allow {
   
input.method == "GET"
   
input.path =="/api/resource"
    input.user.role == "admin"
}
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

如上面的代碼段所示，我們有一個名為“example”的包，它定義了一個名為“allow”的規則。該規則指定：如果輸入方法是“GET”，請求的路徑是/api/resource，並且用戶角色是“admin”，則允許該請求。也就是說，如果同時滿足這些條件，則“allow”規則將其評估為“真”，從而允許該請求繼續進行。

為什麼可針對RBAC使用OPA和API網關？

API網關提供了一個集中位置，來配置和管理API及其使用者。作為集中式身份驗證網關，它有效地避免了讓每個單獨的服務，在其內部實現身份驗證的邏輯。另一方面，OPA通過為授權創建一個單獨的授權層，來將策略與代碼分離。而通過這種組合，您可以將API資源的權限添加到角色上，進而為每個用戶角色都定義一組對於RBAC資源（由URI路徑來定義）的權限（GET、PUT、DELETE）。在下一節中，我們將學習如何使用兩者來實現RBAC。

如何使用OPA和Apache APISIX實現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/），通過將請求轉發給OPA進行決策，來執行RBAC的相關策略。也就是說，OPA會根據用戶的角色和權限，實時做出授權決策。

假設我們有一個Conference API（https://conferenceapi.azurewebsites.net/），您可以在其中檢索/編輯活動會話、主題、以及演講者信息。在授權方面，演講者只能閱讀自己的會話和主題，而管理員則可以添加/編輯更多會話和主題。而且，與會者可以通過POST請求，向/speaker/speakerId/session/feedback路徑留下他們針對演講者會議的反饋，而演講者只能通過請求相同URI的GET方法才能看到。下圖展示了整個場景：

1. API使用者會在API網關上使用其憑據（如：授權標頭中的JWT令牌，https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization）來請求路由。

2. API網關將帶有JWT標頭的使用者數據發送到OPA引擎。

3. OPA使用我們在.rego文件中指定的策略（如：角色和權限），來評估使用者是否有權訪問資源。

4. 如果OPA決定為“允許”，則該請求將被轉發到上游的Conference服務。

接著，我們來安裝和配置APISIX，並在OPA中定義各項策略。

先決條件

• Docker（https://docs.docker.com/get-docker/），用於安裝容器化的etcd和APISIX。
• Curl（https://curl.se/），用於向APISIX Admin API發送請求。當然，您也可以使用Postman（https://www.postman.com/）等工具與API進行交互。

第1 步：安裝Apache APISIX

APISIX可以使用以下腳本被輕鬆地安裝和快速啟動：

curl -sL https://run.api7.ai/apisix/quickstart | sh
1.

第2 步：配置後端服務（上游）

為了將請求路由到Conference API的後端服務，您需要通過Admin API（https://apisix.apache.org/docs/apisix/admin-api/）在Apache APISIX中添加上游服務器來進行配置。請參見如下代碼：

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
   }
}'
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.

第3 步：創建API使用者

接下來，我們使用用戶名Jack在Apache APISIX中創建一個使用者（即，一個新的發言人），並使用指定的密鑰為使用者設置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"
        }
    }
}'
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.

第4 步：創建公共端點以生成JWT令牌

您還需要設置一個使用public-api （https://apisix.apache.org/docs/apisix/plugins/public-api/）插件來生成和簽發令牌的新路由。此時，API網關會充當身份提供者服務器（identity provider server ）的角色，去驗證由使用者Jack的密鑰所創建和驗證的令牌。當然，身份提供者也可以是諸如Google （https://developers.google.com/identity）、Okta（https://www.okta.com/）、Keycloak（https://www.keycloak.org/）和Ory Hydra （https://www.ory.sh/hydra/）等任何第三方服務。請參見如下代碼：

curl http://127.0.0.1:9180/apisix/admin/routes/jas
-X PUT -d '
{
   
"uri": "/apisix/plugin/jwt/sign",
   
"plugins": {
        "public-api": {}
    }
}'
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

第5 步：為API使用者申請一個新的JWT令牌

現在，我們可以使用已創建的公共端點，從API網關處為Jack獲取一個新的令牌了。如下curl命令便是使用Jack的憑據生成一個新令牌，並在負載中分配了角色和權限。

curl -G --data-urlencode 'payload={"role":"speaker","permission":"read"}' http://127.0.0.1:9080/apisix/plugin/jwt/sign?key=user-key -i

在運行了上述命令後，您將收到一個新的令牌作為響應。我們暫且將該令牌保存在某處，以便稍後使用它去訪問新的API網關端點。

第6 步：創建新的插件配置

此步驟會涉及到配置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"
      }
   }
}'
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.

• proxy-rewrite插件被配置為將請求全部代理到conferenceapi.azurewebsites.net主機處。
• OPA身份驗證插件被配置為使用在http://localhost:8181/v1/data/rbacExample上運行的OPA策略引擎。此外，APISIX將所有與使用者相關的信息，都發送給OPA。我們需要在OPA的配置部分裡添加.rego文件。

第7 步：為Conference會話創建路由

最後一步是為Conferences API的演講者會話創建新的路由：

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
}'
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.

上述負載包含了諸如：名稱、描述、方法、URI、上游ID和插件配置ID等路由信息。在本例中，路由被配置為處理兩個不同URI（/speaker/topics和/speaker/sessions）的GET和POST請求。其中，“upstream_id”字段指定了將處理該路由傳入請求的、上游服務的ID，而“plugin_config_id”字段則指定了將用於此路由的、插件配置的ID。

第8 步：在沒有OPA的情況下測試設置

到目前為止，我們已經為APISIX設置了所有必要的配置，以將傳入的請求定向到Conference API的各個端點上，並且只允許那些已被授權的API使用者使用。據此，在每次API使用者需要訪問端點時，他們都必須提供JWT令牌，以從Conference後端服務中檢索到數據。您可以通過點擊端點來對此進行驗證。在此，我們所請求的域地址是自定義API網關，而不是實際的Conference服務：

curl -i http://127.0.0.1:9080/speaker/1/topics -H
'Authorization: {API_CONSUMER_TOKEN}'
1.
2.

第9 步：運行OPA服務

接著，我們使用Docker來運行OPA服務，並使用其API來上傳我們的策略定義。該API可用於評估各個傳入請求的授權策略。

docker run -d --network=apisix-quickstart-net
--name opa -p 8181:8181 openpolicyagent/opa:latest run -s
1.
2.

上述Docker命令啟動了一個具有最新版本的OPA鏡像容器。它在現有的APISIX網絡apisix-quickstart-net上，創建了一個名為OPA，並公開了端口8181的新容器。因此，APISIX可以直接使用地址--[http://opa:8181]( http://opa:8181 ) ，向OPA發送策略檢查請求。注意OPA和APISIX應該運行在同一個Docker網絡中。

第10 步：定義和註冊策略

OPA端的下一步是需要定義將用於控制對API資源進行訪問的策略。這些策略應定義訪問所需的屬性（如：哪些用戶具有哪些角色）、以及基於這些屬性允許或拒絕的權限（如：哪些角色具有哪些權限）。舉例而言，在下面的配置中，我們要求OPA檢查表user_roles，以找到角色Jack。這些信息是由APISIX內部的input.consumer.username發送的。我們據此通過讀取JWT的有效載荷，並從中提取token.payload.permission，來驗證使用者的權限。如下註釋清楚地描述了這些步驟。

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}
}'
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.

步驟11：使用OPA插件更新現有插件配置

一旦在OPA服務上定義了各項策略，我們就需要更新現有的插件配置，以便路由去使用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
      }
   }
}'
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.

第12 步：使用OPA測試設置

至此，我們可以使用OPA策略對所有設置進行測試了。一旦您運行如下curl命令去訪問API網關端點，它會首先在身份驗證過程中檢查JWT令牌，然後在授權過程中，將使用者和JWT令牌的數據發送到OPA處，以驗證角色和權限。顯然，任何沒有JWT令牌，或不具備已允許角色的請求，都會被拒絕掉。

curl -i http://127.0.0.1:9080/speaker/1/topics -H
'Authorization: {API_CONSUMER_TOKEN}'
1.
2.

小結

在本文中，我們通過自定義一個簡單的策略邏輯，展示瞭如何根據API使用者的角色和權限，來允許或禁止API資源的訪問。同時，我們也演示瞭如何從APISIX發送的JWT令牌負載、或使用者的對像中，提取策略文件裡與API使用者相關的信息，以最終實現OPA和Apache APISIX的RBAC效果。