簡化微服務驗證的新方法：開放式策略代理（OPA）
譯文【51CTO.com快譯】從概念上說，身份驗證是指識別出用戶是誰，而授權是指確定某個已被認證用戶具有的何種訪問級別。不知您是否注意到：由于分布式應用往往難以實現強大、且集中式管理所需的身份驗證和授權(Authentication and Authorization，A&A)策略，因此在微服務的實際應用中，您可能時常會遇到驗證和授權的實施問題。下面，我將和您探討開放式策略代理(Open Policy Agent，OPA)是如何協助簡化授權問題的。
為簡單起見，我創建了一個帶有多個微服務應用示例。通過其基本的用戶界面，我們可以在其中執行各項操作，并查看產生的結果。該應用將向您展示開放式策略代理是如何處理各種授權方案的。
應用示例
在此，我們以銷售團隊常用的、為客戶制定報價的CPQ(配置、定價和報價)應用(https://en.wikipedia.org/wiki/Configure,_price_and_quote)為例，定義并創建了如下角色：
- 銷售–作為銷售人員，他們可以為客戶創建并更新報價。但是不能刪除報價。
- 銷售支持–作為支持人員，他們可以查看所有報價，但不能編輯任何報價。
- 銷售管理員–作為管理員，他們可以查看所有報價，但不能編輯或創建任何報價。不過，他們可以根據清理需求去刪除報價。
鑒于本文僅專注于授權環節，在此，我們假設用戶已經通過了身份驗證，并且持有有效的JSON Web令牌(JWT)。而且每個API請求，都會在請求的頭部包含該JWT。
該示例應用在GitHub的下載鏈接為--https://github.com/gchaware/opa-ms-sample/tree/master。請根據README的說明，逐步進行安裝，并通過URL--http://
執行授權
根據上述角色分配，我們授權
- 銷售團隊能夠創建新的報價，查看報價，以及更新現有報價。
- 銷售支持團隊只能查看報價，不能編輯或創建它們。
- 銷售管理團隊既能夠查看報價，又能夠刪除它們。
如上圖所示的UI顯示了多個按鈕，每個按鈕都代表用戶的一項操作。根據用戶選擇使用的角色，UI將會及時反饋創建、編輯或刪除商品操作成功與否的結果。
上圖展示了該應用程序帶有兩個微服務：Offer(報價)和Customer(客戶)。通過將API向外界公布，NGINX反向代理能夠截獲每個API請求，并通過請求授權服務，來驗證是否允許用戶執行該請求的相關操作。
在此，我們使用NGINX的auth_request指令，來截獲傳入的API調用。其中，每個API調用都有一個包含了JWT頭部的授權。而所有用戶的基本信息，包括其角色都被包含在JWT中。在此，該授權服務帶有兩個容器：
- Authorization(授權)–作為已定制的授權服務，可用于接收請求，并為下面的Open Policy Agent創建經過格式化的輸入請求。
- Open Policy Agent (OPA，開放策略代理)–作為輔助工具，它通過對外公布HTTP端點，以實現與授權容器的通信。
首先，NGINX會將/authorize的請求發送給授權容器，以授權某個API調用。接著，授權服務會向開放策略代理詢問是否有授權請求(true/false)。然后，它向NGINX返回成功(200 OK)或者是失敗(403 Forbidden)的響應。據此，NGINX或是允許API的調用，或是向客戶端返回403 Forbidden的響應。
什么是開放策略代理?
開放策略代理(OPA)是一個開源的通用策略引擎，它統一了整個棧中的策略執行。OPA提供了一種高級聲明性的語言，可方便您將策略轉換為代碼和簡單的API，進而減輕了軟件在決策時的負擔。您可以在微服務、Kubernetes、CI/CD管道、以及API網關中，使用OPA來實施策略。
由于OPA能夠接受JSON之類結構化的數據作為輸入，并且可以返回true/false的決策，或將任意結構化的數據作為輸出，因此它能夠有效地將決策與執行予以脫鉤。
值得一提的是，OPA使用rego作為策略語言。您可以通過鏈接--https://www.openpolicyagent.org/docs/latest/，了解更多有關rego和開放策略代理的信息。
詳述授權服務
下面讓我們來詳細討論授權服務的具體工作方式。
如上圖所示，我們在服務器模式下運行開放策略代理，并利用其REST API的更新策略來獲取決策。如下命令展示了開放策略代理通過對外公布REST API，來創建或更新策略。
- PUT /v1/policies/ Content-Type: text/plain
在本例中，我們需要端點接收如下的請求，來更新OPA中的策略(具體可參照它在GitHub里的README)。
- curl -X PUT --data-binary @policies/httpapi.authz.rego http:///authorize/v1/policies/httpapi/authz
同時，我們需要另一個API來根據政策做出決策：
- POST /v1/data/
- Content-Type: application/json
此處的
- {
- "input" : {
- "method": "DELETE",
- "api": "/offer/1000",
- "jwt": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJPbmxpbmUgSldUIEJ1aWxkZXIiLCJpYXQiOjE1NzQ2NjM3MDAsImV4cCI6NDA5OTE4NTMwMCwiYXVkIjoib3BhLWV4YW1wbGUuY29tIiwic3ViIjoianjvy2tldeblegftcgxllmnvbsisikdpdmvutmftzsi6ikpvag5uesisiln1cm5hbwuioijsb2nrzxqilcjfbwfpbci6impyb2nrzxrazxhhbxbszs5jb20iLCJSb2xlIjoiU2FsZXMgQWRtaW4ifQ._UtjZtowF3NNN3IF1t0LBHuzQhdfIfsO8jC-46GvbRM"
- }
- }
由代碼可知，授權應用程序將收到從NGINX發來的請求，并根據上面的邏輯圖為OPA產生輸入請求。針對該示例，我們在前端代碼中對JWT進行了硬編碼。而且每個API請求都會在Authorization頭部包含JWT。據此，授權應用程序在獲取JWT后，會將其添加到OPA的輸入請求中。其具體Java代碼如下：
- Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJMb2NhbEpXVElzc3VlciIsImlhdCI6MTU3MzcyNzM5MSwiZXhwIjo0MDk4MjQ1Mzc4LCJhdWQiOiJvcGEtZXhhbXBsZS5jb20iLCJzdWIiOiJzYWxlc0BleGFtcGxlLmNvbSIsIkdpdmVuTmFtdyI6IkpvaG5ueSIsIlN1cm5hbWUiOiJTYWxlcyIsIkVtYWlsIjoianNhbGVzQGV4YW1wbGUuY29tIiwiUm9sZSI6IlNhbGVzIn0.UbHWQpCMwupzsFp8f0CQ4o_bJSVaBugKijhcURZ_Mko
值得注意的是，授權服務只會從輸入的請求中檢索JWT，而不會對其進行解碼。因此，OPA會通過內置的io.jwt.decode功能函數，去支持JWT的解析。
您可以通過鏈接--https://play.openpolicyagent.org/p/4LOvGaEXEU，進一步了解rego策略的相關程序代碼與邏輯。通過嘗試不同的輸入請求，您將能夠查看到OPA為每一個請求所生成的不同輸出。
小結
綜上所述，開放策略代理提供了一種將授權決策與微服務中的業務邏輯相分離的方法。在實際應用中，系統管理員可以通過對開放策略代理進行設置，將生成授權策略(rego策略)的責任，委托給各個微服務的所有者。而微服務所有者和系統管理員都不會越界進行任何處理。
原文標題：Open Policy Agent: Microservices Authorization Simplified，作者：Gaurav Chaware
【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】
