多云API授權面臨的兩大挑戰(zhàn)

譯文
作者： 李睿 2022-02-24 08:00:00

云計算

混合云 本文將介紹聲明式應用程序接口(Declarative API)授權如何幫助用戶，以及API提供者在部署和運行它們時面臨的挑戰(zhàn)。

成都創(chuàng)新互聯(lián)公司專注于郊區(qū)企業(yè)網(wǎng)站建設,成都響應式網(wǎng)站建設公司,成都商城網(wǎng)站開發(fā)。郊區(qū)網(wǎng)站建設公司,為郊區(qū)等地區(qū)提供建站服務。全流程按需設計網(wǎng)站，專業(yè)設計，全程項目跟蹤，成都創(chuàng)新互聯(lián)公司專業(yè)和態(tài)度為您提供的服務

譯者 | 李睿

審校 | 梁策 孫淑娟

隨著越來越多的企業(yè)采用多云戰(zhàn)略并增加對云原生基礎設施的使用，在多云環(huán)境中大規(guī)模交付API給API提供者帶來了巨大壓力。與此同時，無論企業(yè)采用何種云平臺，API都應遵循每個公司的不同安全要求和優(yōu)秀實踐慣例，而這也是許多API提供者的API授權要求如此復雜的原因。

假設在一家公司中，來自不同業(yè)務部門的多個團隊正在Azure云平臺中構建和部署API。在構建這些API時，不同的團隊使用不同的技術(例如Azure Functions、Node.js)。同時該公司可能會托管在同一網(wǎng)絡上使用API的應用程序，例如該公司的AWS賬戶或外部SaaS應用程序。

接著，我們來看看API提供者在部署和運行這些API時會面臨什么挑戰(zhàn)。

部署時間

如上所述，在多云環(huán)境中構建和部署API時，多個團隊使用的技術不盡相同。因此需要一種驗證API的方法來確保它們遵循優(yōu)秀實踐慣例。一些企業(yè)選擇讓其各個團隊負責，希望由他們提出一些優(yōu)秀實踐，但這種方式通常會導致混亂。要么各個團隊遵循的標準和優(yōu)秀實踐無法統(tǒng)一，要么這一過程就因為要加快交付而被忽視。另一種方式則是通過卓越中心(COE)來審查所有API并確保它們遵循優(yōu)秀實踐。但這種方法不可擴展，交付幾個API可能適用，但在處理數(shù)千個API時，因為需要很長時間，審查就會遭遇阻礙。

很多公司希望這種流程能夠自動化，作為持續(xù)集成/持續(xù)交付(CI/CD)流程的一部分自動驗證API。假設每個API都使用API密鑰身份驗證和授權保證安全，這意味著需要采取一種方式來確保部署API之前開發(fā)人員已在API之上采用了正確的安全策略。

運行時間

在多云環(huán)境中執(zhí)行授權可能會變得更加復雜，給API提供者帶來嚴峻挑戰(zhàn)。典型的用例情境是API提供者希望控制允許調(diào)用其API的應用程序、用戶和IP范圍。

存儲授權數(shù)據(jù)的常用方法之一是由身份提供商(IDP)存儲，并使用JWT令牌將其傳遞給后端API。由于這些環(huán)境的分布式特性，并可能使用不同授權技術，這種方法通常不適合多云環(huán)境。例如，AWS用戶與Azure和SaaS用戶使用的IDP可能不盡相同。

將用戶跨多個IDP的授權數(shù)據(jù)進行復制，并使它們保持同步是復雜且低效的。API提供者在每個IDP中存儲的數(shù)據(jù)也可能存在一些限制。比如，在本文的典型用例情境下，AWS的IDP管理員就會疑惑為什么他們需要存儲AzureAPI的授權數(shù)據(jù)。

解決方案：聲明式API授權

為了解決這個問題，可以使用帶有API Ops、Kong Gateway和OPA的聲明式配置。在深入探討它們?nèi)绾螀f(xié)同工作之前，先來了解一些基礎知識。

(1)API Ops

API Ops將DevOps和GitOps原則引入API和微服務生命周期，以盡可能將這些階段自動化。通過采取聲明性配置，這當中很大一部分的自動化都可實現(xiàn)。如果企業(yè)一直在使用Kubernetes或DevOps，那么或許已了解聲明式配置的概念。使用聲明性配置，API Ops可以把API生命周期的大部分自動化。

(2)開放策略代理(OPA)

開放策略代理(OPA)是一個開源策略引擎，允許用戶將策略定義為代碼。OPA使用Rego語言來定義這些策略。

可以使用OPA將策略創(chuàng)建為代碼，并在其組織中的不同應用程序中執(zhí)行它們，同時創(chuàng)建能夠回答以下問題的OPA策略：

• 應用程序能否調(diào)用客戶API?
• 用戶X可以調(diào)用客戶API嗎?
• 用戶A是否有權查看用戶B的數(shù)據(jù)?

OPA的聲明性使其非常適合API Ops。創(chuàng)建這些策略，將它們存儲在代碼存儲庫中，并在API生命周期的不同階段使用。

(3)Kong Gateway和開放策略代理

可以將OPA與Kong Gateway集成。下面來看看API使用者、Kong Gateway、OPA服務器和后端API之間的交互過程：

①API消費者向Kong Gateway發(fā)送請求。

②Kong Gateway使用OPA插件調(diào)用OPA服務器中的策略并接收響應。

③根據(jù)OPA服務器的響應，KongGateway判斷將請求轉發(fā)到后端API或返回錯誤。

OPA策略架構的一個重要部分是將數(shù)據(jù)與策略定義解耦。在這種情況下，策略可以通過兩種方式訪問它需要判斷的信息：

• 輸入：輸入是指消費者向Kong Gateway發(fā)送的請求。此外還可以配置OPA插件以將網(wǎng)關的服務、消費者和路由對象也作為輸入的一部分發(fā)送。
• 數(shù)據(jù)：可以使用OPA的API將任意JSON數(shù)據(jù)推送到策略中。可能有人會問為什么需要數(shù)據(jù)元素，這是因為輸入是關于當前使用者的，而做判斷有時需要更多信息，不僅僅是當前的用戶場景。例如，任意數(shù)據(jù)可與用戶角色和訪問級別有關，而這在輸入請求中不存在。

將外部數(shù)據(jù)注入OPA策略還有其他方法：

(4)持續(xù)集成/持續(xù)交付(CI/CD)工具和開放策略代理

OPA的一大優(yōu)點是它可以與大多數(shù)技術集成，只要這些技術生成和使用JSON。如今，大多數(shù)CI/CD工具都具備開箱即用的庫或第三方插件來支持JSON。在部署期間，可以使用OPA來驗證：

• 應用于API的強制Kong插件(例如，身份驗證插件)
• 強制測試用例已經(jīng)包含在項目中。
• 用戶有權將API部署到目標環(huán)境。

在持續(xù)部署中執(zhí)行聲明式授權：

①API開發(fā)人員使用Insomnia設計API，定義Kong插件并將API規(guī)范檢查到代碼庫中。

②作為持續(xù)部署的一部分，CI/CD工具對OPA 策略進行調(diào)用。OPA策略驗證API規(guī)范、Kong插件、測試用例和開發(fā)人員的授權。

③如果結果成功，CI/CD工具繼續(xù)該過程，反之停止。

(5)API Ops、Kong Gateway和OPA如何協(xié)同工作

實施此解決方案可按以下步驟：

①在將API部署到Kong Gateway之前，CI/CD工具會調(diào)用OPA，并驗證強制插件是否在API定義中。如果策略檢查通過，那么它會使用聲明性配置來部署API。

②消費者應用程序使用IDP或任何其他方法來創(chuàng)建JWT令牌。此令牌具有用戶的唯一ID。在此假設用戶ID在不同的云平中是唯一的。

③消費者應用程序?qū)⒄埱蟀l(fā)送到Kong Gateway。

④Kong Gateway將請求發(fā)送到OPA服務器。OPA服務器執(zhí)行策略并返回結果。

⑤如果Kong Gateway成功，請求將發(fā)送到后端API，反之返回錯誤。

以下將討論具體執(zhí)行和詳細內(nèi)容，這里將使用GitHub Actions實現(xiàn)API部署自動化，讀者可根據(jù)使用的CI/CD工具調(diào)整這些腳本。

如何設置GitHub操作和OPA

解決方案的第一部分是確保開發(fā)人員已在API之上納入正確的策略。這意味著API規(guī)范中應存在密鑰認證和OPA插件。

API開發(fā)人員可以使用“x-kong-plugin-”前綴將所需的插件添加到他們的API中?？蛻鬋ustomer API的OpenAPI規(guī)范(OAS)如下所示：

openapi: "3.0.0"
info:
  version: 1.0.1
  title: customer api
  license:
    name: Kong

servers:
  - url: ${UPSTREAM_SERVER_URL}$
    description: Upstream server URL.

# Key Auth plugin enables authentication for this service
x-kong-plugin-key-auth:
  enabled: true
  config:
    key_names:
    - apikey

x-kong-plugin-opa:
      enabled: true
      config:
        opa_host: ${OPA_HOST}$
        opa_port: ${OPA_PORT}$
        opa_path: /v1/data/userAuthz/allowUser
        include_consumer_in_opa_input: true
        include_route_in_opa_input: true
        include_service_in_opa_input: true

可以簡單地創(chuàng)建一個OPA策略，并在API規(guī)范中查找這些插件。

package apiCDAuthz

default allow = false


allow {
  input["x-kong-plugin-key-auth"].enabled == true
  input["x-kong-plugin-opa"].enabled == true

}

如上可見，這一策略在OAS規(guī)范中查找這兩個插件(例如輸入)并檢查它們是否已啟用。如果兩個策略都存在并啟用，則返回true;否則，它返回false。

可以通過調(diào)用OPA的創(chuàng)建策略API創(chuàng)建此策略：

curl -XPUT http:///v1/policies/apiCDAuthz --data-binary @./opa/apiCDAuthz.rego

下一步是將OAS規(guī)范發(fā)送到OPA策略并檢查結果。在這個例子中，OAS規(guī)范采用YAML編寫，而OPA只能處理JSON。因此，第一步需要導出客戶規(guī)范并將其轉換為JSON，如下GitHub Action工作流程所示：

# Export customer yaml
      - name: Export customer yaml
        run: inso export spec customer-opa --output customer.yaml
      # Transform OAS to JSON
      - uses: fabasoad/yaml-json-xml-converter-action@main
        id: yaml2json
        with:
          path: 'customer.yaml'
          from: 'yaml'
          to: 'json'      
      - name: Prepare OPA input
        run: |
           cat < ./v1-data-input.json
           {
                "input": ${{ steps.yaml2json.outputs.data }}
           }
           EOF

然后，可以調(diào)用OPA策略并驗證JSON數(shù)據(jù)。

# Check deployment authorisation
      - name: Call OPA to Check Deployment Authorisation
        id: call-opa
        run: |          
            result=$(curl ${{ secrets.OPA_HOST }}/v1/data/apiCDAuthz -d @./v1-data-input.json \
            -H 'Content-Type: application/json' | jq '.result.allow')                      
            echo "::set-output name=result::$result"
            
      - name: Should I continue?       
        run: |
          if ${{ steps.call-opa.outputs.result }}; then
            echo "Call OPA Result: ${{ steps.call-opa.outputs.result }}"            
          else
              echo "Call OPA Result: ${{ steps.call-opa.outputs.result }}"
              exit 1
          fi

如果結果為false(即API規(guī)范不符合配置的優(yōu)秀實踐)，部署過程將自動失敗，系統(tǒng)將通知開發(fā)人員。

此示例簡單地演示了OPA在部署過程中可以發(fā)揮的作用?？梢詫⑵鋽U展為：

• 檢查開發(fā)人員授權。
• 進行高級代碼校驗。
• 檢查API優(yōu)秀實踐和命名約定。

如何設置Kong Gateway和OPA

如上所述，API提供者希望將其API公開給：

• Azure的內(nèi)部使用者。
• AWS的內(nèi)部得到者。
• 使用AWS IDP的外部使用者。
• 使用Azure IDP的外部使用者。

與此同時，API提供者希望控制調(diào)用其API的應用程序、用戶和網(wǎng)絡。例如，API提供者可能只允許用戶使用托管在公司AWS賬戶中的CRM應用程序調(diào)用GET客戶。

API開發(fā)人員必須已在運行時為這個API配置了OPA插件。否則，它在部署過程就會失敗。以下是OPA插件的配置：

x-kong-plugin-opa:
      enabled: true
      config:
        opa_host: ${OPA_HOST}$
        opa_port: ${OPA_PORT}$
        opa_path: /v1/data/userAuthz/allowUser
        include_consumer_in_opa_input: true
        include_route_in_opa_input: true
        include_service_in_opa_input: true

OPA插件將請求、使用者、服務和路由信息發(fā)送到OPA服務器中的userAuthz策略。在當前請求之上添加服務、使用者和路由信息有助于訪問級別更精細。例如，該策略可以限制用戶僅使用某些路由。

現(xiàn)在看一下userAuthz策略：

package userAuthz

default allowUser = false


allowUser = response {
  # Validate JWT token
  v := input.request.http.headers.authorization
  startswith(v, "Bearer ")
  t := substring(v, count("Bearer "), -1)
  io.jwt.verify_hs256(t, data.userAuthz.jwt_signiture)
  [_, payload, _] := io.jwt.decode(t)

  # Validate consumer app
  kong_consumer := input.consumer.username
  some j
  data.userAuthz.apps[j] == kong_consumer

  # Validate network
  net.cidr_contains(data.userAuthz.networkcidr, input.client_ip)


  # Validate user's access to api
  role := data.userAuthz.users[payload.username].role
  serviceName := input.service.name
  access := data.userAuthz.role_service_access[role][serviceName].access
  tier := data.userAuthz.role_service_access[role][serviceName].tier
  some i
  access[i] == input.request.http.method

  response := {
    "allow": true,
    "headers": {
      "x-user-tier": tier,
    },
  }
}

這一策略：

(1)從請求中讀取JWT令牌，對其進行驗證和解碼。

(2)驗證客戶端IP地址是否被授權調(diào)用該API。

(3)驗證消費者應用程序是否在批準的應用程序列表中。

(4)驗證用戶在授權用戶列表中并且可執(zhí)行HTTP方法。

如上所見，這策略使用了數(shù)據(jù)變量，這些數(shù)據(jù)通過OPA API注入此策略。

curl -XPUT http:///v1/data/userAuthz --data-binary @./opa/userAuthz.json

如果數(shù)據(jù)發(fā)生變化，可以簡單地更新JSON文件并再次調(diào)用OPA API。

{
  "jwt_signiture": "46546B41BD5F462719C6D6118E673A2389",
  "networkcidr": "178.10.0.0/24",
  "apps": ["insomnia"],
  "users": {
      "[email protected]": {
        "role": "admin"
      }
  },
  "role_service_access": {
    "admin": {
      "customer_api": {
        "access": ["GET"],
        "tier": "Gold"
      },
      "employee_api": {
        "access": ["GET","POST"],
        "tier": "Silver"
      }
    }
  }
}

通過使用這一策略和數(shù)據(jù)組合，API提供者只允許具有以下屬性的請求調(diào)用GET客戶API：

• 由hs256和46546B41BD5F462719C6D6118E673A2389密鑰簽名的JWT令牌
• 178.10.0.0/24CIDR內(nèi)的IP地址
• 用戶ID [email protected]

OPA策略的另一個優(yōu)點是能夠?qū)⒂杏玫男畔⒎祷氐終ong Gateway。這一案例里返回的是每個API的用戶訪問層級(此處是Gold)。利用這一信息，Kong Gateway可以設置一些訪問層級相關的操作，比如根據(jù)層級限制速率等等。

結論

使用OPA和聲明式策略正變得普遍起來，尤其是在API Ops領域。因為它們：

• 易于集成：將OPA與Kong Gateway、Kong Mesh和CI/CD工具集成起來非常簡單，將OPA與外部數(shù)據(jù)源集成也很容易。
• 聲明式：聲明式使得OPA策略天生適合API Ops和自動化。API提供者可以在API生命周期的不同階段使用OPA策略，且無需擔心它會影響自動化。
• 極其強大且靈活：OPA使用Rego語言來定義策略。Rego為引用嵌套文檔提供了強大的支持，并確保查詢正確明了。
• 不依賴平臺：OPA不依賴具體平臺。大多數(shù)技術和平臺它都適用，在不同的云計算供應商和應用程序中可以使用相同的策略。

在多云環(huán)境中構建和管理API不是一件容易事，尤其是在安全性和授權方面。將策略即代碼與API Ops結合使用，不失為構建自動化和可擴展解決方案的一種好方法。

原文標題：Multi-Cloud API Authorization Challenges，作者：Nima Moghadam

新聞名稱：多云API授權面臨的兩大挑戰(zhàn)
URL網(wǎng)址：http://uogjgqi.cn/article/cccjocj.html