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

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

云計(jì)算

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

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

譯者 | 李睿

審校 | 梁策 孫淑娟

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

假設(shè)在一家公司中，來(lái)自不同業(yè)務(wù)部門(mén)的多個(gè)團(tuán)隊(duì)正在Azure云平臺(tái)中構(gòu)建和部署API。在構(gòu)建這些API時(shí)，不同的團(tuán)隊(duì)使用不同的技術(shù)(例如Azure Functions、Node.js)。同時(shí)該公司可能會(huì)托管在同一網(wǎng)絡(luò)上使用API的應(yīng)用程序，例如該公司的AWS賬戶或外部SaaS應(yīng)用程序。

接著，我們來(lái)看看API提供者在部署和運(yùn)行這些API時(shí)會(huì)面臨什么挑戰(zhàn)。

部署時(shí)間

如上所述，在多云環(huán)境中構(gòu)建和部署API時(shí)，多個(gè)團(tuán)隊(duì)使用的技術(shù)不盡相同。因此需要一種驗(yàn)證API的方法來(lái)確保它們遵循優(yōu)秀實(shí)踐慣例。一些企業(yè)選擇讓其各個(gè)團(tuán)隊(duì)負(fù)責(zé)，希望由他們提出一些優(yōu)秀實(shí)踐，但這種方式通常會(huì)導(dǎo)致混亂。要么各個(gè)團(tuán)隊(duì)遵循的標(biāo)準(zhǔn)和優(yōu)秀實(shí)踐無(wú)法統(tǒng)一，要么這一過(guò)程就因?yàn)橐涌旖桓抖缓鲆?。另一種方式則是通過(guò)卓越中心(COE)來(lái)審查所有API并確保它們遵循優(yōu)秀實(shí)踐。但這種方法不可擴(kuò)展，交付幾個(gè)API可能適用，但在處理數(shù)千個(gè)API時(shí)，因?yàn)樾枰荛L(zhǎng)時(shí)間，審查就會(huì)遭遇阻礙。

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

運(yùn)行時(shí)間

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

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

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

解決方案：聲明式API授權(quán)

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

(1)API Ops

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

(2)開(kāi)放策略代理(OPA)

開(kāi)放策略代理(OPA)是一個(gè)開(kāi)源策略引擎，允許用戶將策略定義為代碼。OPA使用Rego語(yǔ)言來(lái)定義這些策略。

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

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

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

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

可以將OPA與Kong Gateway集成。下面來(lái)看看API使用者、Kong Gateway、OPA服務(wù)器和后端API之間的交互過(guò)程：

①API消費(fèi)者向Kong Gateway發(fā)送請(qǐng)求。

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

③根據(jù)OPA服務(wù)器的響應(yīng)，KongGateway判斷將請(qǐng)求轉(zhuǎn)發(fā)到后端API或返回錯(cuò)誤。

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

• 輸入：輸入是指消費(fèi)者向Kong Gateway發(fā)送的請(qǐng)求。此外還可以配置OPA插件以將網(wǎng)關(guān)的服務(wù)、消費(fèi)者和路由對(duì)象也作為輸入的一部分發(fā)送。
• 數(shù)據(jù)：可以使用OPA的API將任意JSON數(shù)據(jù)推送到策略中?？赡苡腥藭?huì)問(wèn)為什么需要數(shù)據(jù)元素，這是因?yàn)檩斎胧顷P(guān)于當(dāng)前使用者的，而做判斷有時(shí)需要更多信息，不僅僅是當(dāng)前的用戶場(chǎng)景。例如，任意數(shù)據(jù)可與用戶角色和訪問(wèn)級(jí)別有關(guān)，而這在輸入請(qǐng)求中不存在。

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

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

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

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

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

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

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

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

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

實(shí)施此解決方案可按以下步驟：

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

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

③消費(fèi)者應(yīng)用程序?qū)⒄?qǐng)求發(fā)送到Kong Gateway。

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

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

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

如何設(shè)置GitHub操作和OPA

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

API開(kāi)發(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

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

package apiCDAuthz

default allow = false


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

}

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

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

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

下一步是將OAS規(guī)范發(fā)送到OPA策略并檢查結(jié)果。在這個(gè)例子中，OAS規(guī)范采用YAML編寫(xiě)，而OPA只能處理JSON。因此，第一步需要導(dǎo)出客戶規(guī)范并將其轉(zhuǎn)換為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策略并驗(yàn)證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

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

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

• 檢查開(kāi)發(fā)人員授權(quán)。
• 進(jìn)行高級(jí)代碼校驗(yàn)。
• 檢查API優(yōu)秀實(shí)踐和命名約定。

如何設(shè)置Kong Gateway和OPA

如上所述，API提供者希望將其API公開(kāi)給：

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

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

API開(kāi)發(fā)人員必須已在運(yùn)行時(shí)為這個(gè)API配置了OPA插件。否則，它在部署過(guò)程就會(huì)失敗。以下是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插件將請(qǐng)求、使用者、服務(wù)和路由信息發(fā)送到OPA服務(wù)器中的userAuthz策略。在當(dāng)前請(qǐng)求之上添加服務(wù)、使用者和路由信息有助于訪問(wèn)級(jí)別更精細(xì)。例如，該策略可以限制用戶僅使用某些路由。

現(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)從請(qǐng)求中讀取JWT令牌，對(duì)其進(jìn)行驗(yàn)證和解碼。

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

(3)驗(yàn)證消費(fèi)者應(yīng)用程序是否在批準(zhǔn)的應(yīng)用程序列表中。

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

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

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

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

{
  "jwt_signiture": "46546B41BD5F462719C6D6118E673A2389",
  "networkcidr": "178.10.0.0/24",
  "apps": ["insomnia"],
  "users": {
      "john.smith@myco.com": {
        "role": "admin"
      }
  },
  "role_service_access": {
    "admin": {
      "customer_api": {
        "access": ["GET"],
        "tier": "Gold"
      },
      "employee_api": {
        "access": ["GET","POST"],
        "tier": "Silver"
      }
    }
  }
}

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

• 由hs256和46546B41BD5F462719C6D6118E673A2389密鑰簽名的JWT令牌
• 178.10.0.0/24CIDR內(nèi)的IP地址
• 用戶ID john.smith@myco.com

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

結(jié)論

使用OPA和聲明式策略正變得普遍起來(lái)，尤其是在API Ops領(lǐng)域。因?yàn)樗鼈儯?/p>

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

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

原文標(biāo)題：Multi-Cloud API Authorization Challenges，作者：Nima Moghadam

網(wǎng)頁(yè)標(biāo)題：多云API授權(quán)面臨的兩大挑戰(zhàn)
網(wǎng)站路徑：http://m.5511xx.com/article/cccjocj.html