目前，為了確保合適的人員能夠訪問到合適的資源，我們需要對系統啟用適當的訪問控制方式。不過，面對各種廣為熟悉的實現模型，構建其后端服務的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，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 exampledefault allow = falseallow { input.method == "GET" input.path =="/api/resource" input.user.role == "admin"}
如上面的代碼段所示，我們有一個名為“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 APISIXAPISIX可以使用以下腳本被輕松地安裝和快速啟動：
curl -sL https://run.api7.ai/apisix/quickstart | sh第 2 步：配置后端服務（上游）
為了將請求路由到ConferenceAPI的后端服務，您需要通過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 }}"第 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" } }}"第 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": {} }}"第 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" } }}"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 ConferencesAPI 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”字段指定了將處理該路由傳入請求的、上游服務的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}"第 9 步：運行OPA服務
接著，我們使用Docker來運行OPA服務，并使用其API來上傳我們的策略定義。該API可用于評估各個傳入請求的授權策略。
docker run -d --network=apisix-quickstart-net--name opa -p 8181:8181 openpolicyagent/opa:latest run -s
上述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 assignmentsrole_permissions := { "speaker": [{"permission": "read"}], "admin": [{"permission": "read"}, {"permission":"write"}]}# Helper JWT Functionsbearer_token := t { t :=input.request.headers.authorization}# Decode the authorization token to get a role andpermissiontoken = {"payload": payload} { [_, payload,_] := io.jwt.decode(bearer_token)}# Logic that implements RBACdefault allow = falseallow { # Lookupthe list of roles for the user roles :=user_roles[input.consumer.username] #For each role in that list r :=roles[_] # Lookup the permissions listfor role r permissions := role_permissions[r] # For each permission p :=permissions[_] # Check if thepermission granted to r matches the users request p =={"permission": token.payload.permission}}"步驟 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 } }}"第 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}"小結
在本文中，我們通過自定義一個簡單的策略邏輯，展示了如何根據API使用者的角色和權限，來允許或禁止API資源的訪問。同時，我們也演示了如何從APISIX發送的JWT令牌負載、或使用者的對象中，提取策略文件里與API使用者相關的信息，以最終實現OPA和Apache APISIX的RBAC效果。
譯者介紹陳峻（Julian Chen），51CTO社區編輯，具有十多年的IT項目實施經驗，善于對內外部資源與風險實施管控，專注傳播網絡與信息安全知識與經驗。
原文標題：RBAC With API Gateway and Open Policy Agent (OPA) ，作者：Bobur Umurzokov
鏈接：https://dzone.com/articles/rbac-with-api-gateway-and-open-policy-agentopa
關鍵詞：
