使用 Amazon Verified Permissions 在容器化工作負載中管理授權

容器化技術為組織帶來了許多好處，例如可攜性、可擴展性和資源的高效利用。然而，管理跨不同環境（從本地到多雲設置）的容器化工作負載的訪問控制和授權可能會很具挑戰性。

這篇博客文章探討了四種使用 Amazon Verified Permissions 在 Kubernetes 環境中進行應用授權的架構模式。Verified Permissions 是一種可擴展的權限管理和細粒度授權服務，適用於你的應用。

在這篇文章中，我們將討論以下模式及其權衡：

從 Amazon API Gateway API 調用 Verified Permissions，將其作為 Kubernetes 中應用的前端

從 Kubernetes Ingress 控制器組件調用 Verified Permissions

從與應用容器在同一 pod 中運行的 sidecar 容器調用 Verified Permissions

從應用容器調用 Verified Permissions

了解這些模式及其影響可以幫助你在不影響容器化工作負載的可擴展性、可攜性和資源效率的情況下，實施安全且一致的授權機制。

通過集中式策略管理實現一致的授權

通過集中且一致的方法來保護應用資源的訪問權限，特別是在具有分佈式架構和共享資源的容器化環境中，傳統的訪問控制方法（如將授權邏輯嵌入到單個應用代碼中或依賴於本地訪問控制策略）可能會變得難以管理且容易出錯。當你擁有本地和雲端設置的組合時，這一點尤其具有挑戰性。

集中式授權解決方案使開發人員能夠高效地在應用的各個組件中實施一致的訪問控制。其優勢包括減少重複工作、提高安全性以及降低管理和執行訪問控制策略的複雜性。

容器化環境中的 Verified Permissions 優勢

Amazon Verified Permissions 作為外部授權服務提供了幾個關鍵優勢：

平台工程團隊的優勢——集中授權使平台工程團隊能夠在不需要更改單個應用的情況下，實施、維護和管理整個組織的授權策略。這與現代平台工程實踐相一致，平台工程團隊可以向應用團隊提供授權作為服務，促進一致的安全標準，同時減少開發團隊的運營負擔。

跨環境的一致授權——使用 Verified Permissions，你可以在集中位置定義和管理訪問控制策略。這使得在整個基礎設施中應用一致的授權規則變得更加容易，包括本地部署和不同的雲環境。

簡化應用開發——將授權邏輯從應用中外部化可以減少開發的複雜性。開發人員可以專注於核心應用功能，而不必在每個服務或組件中實施和維護授權機制。這種關注點分離促進了代碼的模塊化、可重用性和更快的迭代周期。

可擴展且高度可用——Verified Permissions 是一種託管服務，設計為開箱即用的可擴展和高度可用。隨著你的容器化工作負載的規模和複雜性增長，Verified Permissions 可以在保持性能和可用性的同時處理增加的授權請求量。

細粒度的訪問控制——Verified Permissions 支持基於屬性的訪問控制（ABAC）和基於角色的訪問控制（RBAC）。這使你可以根據用戶角色、資源屬性、環境因素等各種屬性在開源 Cedar 語言中定義細粒度的策略。

授權的整合模式

Kubernetes 提供了許多架構應用的選擇。因此，在典型架構中有多個位置可以強制執行授權決策，如圖 1 所示。

圖 1：容器化工作負載中授權的整合點

工作流程如下：

API Gateway。組織可以使用 Kubernetes 集群外部的應用入口點，例如 API gateway，來獲取授權決策。在 AWS 中，Amazon API Gateway 使客戶能夠使用 authorizer Lambda 函數將授權請求發送到 Verified Permissions。

Ingress 控制器。Kubernetes API 定義了 Ingress 對象，提供第 7 層的負載均衡和路由功能。常見的 Ingress 控制器如 Traefik 提供了整合外部授權服務的選項。

Sidecar 代理容器。你可以通過在與應用容器相同的 pod 中運行的 sidecar 容器攔截每個路由到應用的請求。這個 sidecar 容器調用 Verified Permissions 進行授權決策。

應用容器。開發人員可以使用 Amazon SDK 從應用內部與 Verified Permissions 通信，當需要授權決策時。

在接下來的部分中，我們將詳細探討這些模式，檢查它們的實施、使用案例和具體考量。在討論結束時，我們將提供一個綜合比較表，以幫助你根據可擴展性、性能、維護開銷和具體使用案例需求等因素選擇最合適的模式。這將幫助你做出明智的決策，選擇最適合你的應用需求的模式。

授權工作流程

無論你選擇上述四種授權選項中的哪一種，總體授權工作流程，如圖 2 所示，將保持不變。

圖 2：使用 Amazon Verified Permissions 的授權工作流程

工作流程如下：

身份驗證。用戶首先與身份提供者進行身份驗證以獲取 JSON Web Token (JWT)。你可以配置身份提供者將相關信息（如用戶角色、租戶 ID 或其他所需的用戶屬性）寫入 JWT。然後你可以稍後使用這些信息進行授權決策。

API 請求。用戶向你的應用發出包含 JWT 的請求。

授權信息。你的應用從請求中提取進行授權決策所需的相關信息。這可以包括來自 JWT 的主體信息、用戶請求的資源信息以及用戶想要執行的操作。

（可選）策略信息點查詢。根據你的策略，你可能需要額外的信息以便 Verified Permissions 做出授權決策。例如，你可以從數據庫中查詢文檔的所有權詳細信息。

授權決策。然後你將相關信息發送到 Verified Permissions，該服務返回一個決策，指出請求是被允許還是被禁止。

授權執行。然後你在應用中執行來自 Verified Permissions 的決策，允許或拒絕某個操作。對於 REST API，如果請求被拒絕，這將導致發回 HTTP 403 禁止狀態；如果請求被允許，則處理請求並發送 HTTP 200 OK 狀態。

使用 Amazon API Gateway 在集群外進行授權

在這種模式中，授權決策在 API gateway 層進行，然後請求才到達 Kubernetes 集群。當請求到達 API gateway 時，它會觸發與 Verified Permissions 的授權檢查，以根據定義的策略評估請求。根據 Verified Permissions 的響應，gateway 要麼將請求轉發到容器化應用，要麼拒絕訪問。

這種模式在需要粗粒度訪問控制的場景中表現出色，這些控制可以通過 API 級別（如 HTTP 標頭或 ID 或訪問令牌）訪問的信息來強制執行，並支持 RBAC 和 ABAC。考慮一個文檔管理應用，其中不同用戶基於組成員身份或身份屬性訪問不同的文檔。

這種授權方法無論你的應用運行在容器中、虛擬機中還是無服務器環境中都能一致地工作。API gateway 作為統一的控制點，用於在後端服務中強制執行訪問策略。

對於特別使用 Amazon API Gateway 的實施，你可以使用 Lambda authorizers 與 Verified Permissions 整合。對於每個傳入的 API 請求，API Gateway 調用 authorizer Lambda 函數，該函數調用 Verified Permissions 以根據定義的授權策略評估請求，如圖 3 所示。

圖 3：Amazon API Gateway 中 Amazon Verified Permissions 的整合

AWS 提供了一個快速入門解決方案，通過使用 Amazon API Gateway 和 Amazon Cognito 演示這種整合，從而更容易實施這種模式。設置過程詳見博客文章《使用 Amazon Verified Permissions 和 Amazon Cognito 授權 API Gateway API 或帶上你自己的身份提供者》。

在 Kubernetes Ingress 中授權

另一個實施粗粒度訪問控制的選擇是使用 Kubernetes Ingress 層，如上一節所述的使用案例。某些客戶更喜歡 Kubernetes 原生解決方案，特別是當他們需要在 AWS 內外運行 Kubernetes 集群時。

Kubernetes 提供了一個 API 來創建和維護 Ingress 對象，運行在第 7 層（應用層），這使得基於 HTTP 屬性進行路由決策成為可能。這種第 7 層的能力使 Ingress 控制器成為實施授權檢查的理想選擇。

一個支持外部授權的 Kubernetes Ingress 控制器是 Traefik Proxy。通過這個功能，你可以在將請求路由到應用容器之前，將授權決策委託給像 Verified Permissions 這樣的外部服務。

假設授權端點由同一 Kubernetes 集群中的服務支持，架構如圖 4 所示。

圖 4：Kubernetes Ingress 中 Amazon Verified Permissions 的整合

工作流程如下：

已驗證的用戶通過類型為 Network Load Balancer (NLB) 的彈性負載均衡器訪問服務。

NLB 在第 4 層運行，暴露集群內的 Kubernetes Ingress，提供第 7 層的能力。Ingress 對象由支持外部授權的 Ingress 控制器實現，如前所述。

Ingress 將需要授權的請求或其部分轉發到集群中的本地授權服務。在這個架構中，我們使用專用的授權服務，因為 Ingress 後端服務允許調用外部端點進行授權。

授權服務部署在其自己的 Kubernetes 命名空間中，具有專用的 Kubernetes 服務帳戶。EKS Pod Identity 提供了將此命名空間中的服務帳戶鏈接到 AWS Identity and Access Management (IAM) 角色的能力，通過在運行時將臨時 AWS 訪問憑證注入到 pod 中來授予 Verified Permissions 的訪問權限。

授權服務從請求中提取相關信息並將其發送到 Verified Permissions 進行授權決策。

後端服務的 Ingress 等待授權服務的響應，如果授權被授予，則將其轉發到後端服務。Ingress 期望授權服務對授權請求返回 HTTP 狀態碼 200。如果 Ingress 收到 HTTP 狀態碼 403，則請求者不被允許訪問請求的資源，Ingress 將在此階段阻止請求。

只有授權的請求才會被轉發到註冊的後端 pod。

由於與外部授權服務的整合不是 Kubernetes Ingress API 的一部分，你需要查閱你決定使用的 Ingress 控制器的文檔，以確定此功能的可用性及其實施細節。Traefik Kubernetes Ingress 的轉發身份驗證支持這種模式，可以通過 Traefik 文檔中描述的供應商特定註釋進行配置。

在 sidecar 容器中授權

並非所有 Ingress 控制器都支持與外部授權服務的整合。Amazon Elastic Kubernetes Service (Amazon EKS) 的客戶可能更喜歡使用 AWS Load Balancer Controller 來管理其服務的 NLB 和 ALB 的生命周期。即使當前的 Ingress 控制器不支持調用外部授權服務，客戶仍然可以繼續使用他們現有的 Ingress 控制器。你可以通過 sidecar 容器模式將請求的授權移到 Ingress 層後面。

Sidecar 容器是 Kubernetes 中擴展應用功能的一種常見模式。sidecar 是一個與其相關應用運行在同一 pod 中的容器。這意味著 sidecar 和應用遵循相同的生命周期並共享資源，例如網絡 ID。當授權邏輯是特定於服務時，這種模式非常適合。由於授權服務與應用一起部署，這種模式在應用的變更需要更改授權邏輯的情況下也提供了更好的支持。

考慮一個文檔管理系統，其中訪問控制依賴於文檔元數據和團隊結構。當用戶嘗試編輯文檔時，sidecar 查詢文檔的元數據，例如分類級別、標籤和部門所有權。sidecar 還可以檢查組織的團隊層級，以了解報告關係和訪問權限。這種上下文使得細粒度的授權決策成為可能，不僅考慮用戶是誰，還考慮他們的組織上下文或單個文檔的元數據。

儘管可以手動為單個 pod 配置 sidecar 代理（如 Envoy），但更方便的選擇是引入服務網格。服務網格提供了一個控制平面來管理代理，包括集中配置、自動注入 sidecar 和流量路由的 Ingress 層。Istio 是 Kubernetes 中服務網格的一個流行選擇。

圖 5 中的圖表顯示了在服務網格中使用 Verified Permissions 實施授權的部署架構。

圖 5：Kubernetes Ingress 中 Amazon Verified Permissions 的整合

工作流程如下：

已驗證的用戶通過 NLB 訪問應用。

請求通過 Kubernetes 集群中的 Ingress 路由。

Ingress 將請求直接轉發到後端服務。

後端服務的 pod 由多個容器組成。每個請求首先通過 Envoy 代理路由。

Envoy 代理將請求轉發到運行授權服務的同址容器。

Pod Identity 用於將 IAM 角色映射到綁定到 pod 的 Kubernetes 服務帳戶，這使得授權 sidecar 能夠調用 Verified Permissions 進行授權決策。請注意，該 pod 中的每個容器都可以訪問映射到服務帳戶的 IAM 憑證。

Envoy 代理等待授權 sidecar 的響應，並根據 Verified Permissions 的授權決策阻止或轉發請求到後端容器。

當 Istio 部署到 Kubernetes 集群中時，它引入了用於管理服務網格的自定義資源定義 (CRD)。可以使用 ServiceEntry CRD 和 Istio 授權策略實施授權工作流程。作為應用 pod 中本地容器運行的授權服務成為網格中的註冊服務入口。然後可以在授權策略中將此服務入口配置為代理中請求授權的目標。更多詳細信息，請參閱 Istio 文檔中的外部授權部分。

應用容器

當涉及到直接在應用容器中整合 Verified Permissions 時，你可以在應用層面上對授權決策進行細粒度控制。這種方法允許進行更具上下文感知的授權檢查，當你需要根據應用特定數據做出授權決策時，這可能很有用，你可以從策略信息點查詢這些數據。

與 sidecar 模式不同，sidecar 模式在請求到達你的應用代碼之前進行授權，這種方法允許你在進行授權調用之前從應用狀態、數據庫或其他服務中收集必要的上下文。當授權邏輯與業務邏輯緊密相關或需要僅在應用上下文中可用的數據時，這尤其有價值。這種模式還支持最小化授權請求的數量，例如，如果只有單體服務處理的請求子集需要授權。

然而，值得注意的是，授權和業務邏輯之間的緊密耦合使系統更加脆弱，當功能或業務邏輯發生變化時容易出現故障。這意味著對應用代碼的修改可能需要仔細考慮其對授權邏輯的影響，可能會增加維護的複雜性。

從應用容器發出授權請求的架構如圖 6 所示。

圖 6：應用容器中 Amazon Verified Permissions 的整合

工作流程如下：

已驗證的用戶通過彈性負載均衡器訪問應用——根據工作負載需求選擇應用負載均衡器 (ALB) 或 NLB。

後端應用的 Kubernetes 服務或 Ingress 直接由 AWS Load Balancer Controller 註冊到 ALB 或 NLB。

請求直接路由到支持服務的 pod。

後端應用的邏輯負責識別請求是否需要授權。當需要 Verified Permission 的授權決策時，後端使用通過 Pod Identity 在運行時注入的 IAM 角色。如果決策是拒絕，後端應用返回 HTTP 狀態碼 403；否則，它將繼續處理請求。

有關在應用中調用 Verified Permissions 的詳細信息，請參閱博客文章《使用 Amazon Verified Permissions 和 Amazon Cognito 簡化細粒度授權》。

為你的應用選擇合適的模式

你現在擁有一套模式，可以將授權引入到你的容器化工作負載中。你需要考慮多個因素並了解每種模式的權衡，以識別給定場景的最佳選擇。在下表中，我們列出了一些影響你架構決策的領域。

授權決策的粒度
- API gateway
- Ingress 控制器
- Sidecar 代理
- 應用容器

資源開銷
- API gateway
- Ingress 控制器
- Sidecar 代理
- 應用容器

可擴展性
- API gateway
- Ingress 控制器
- Sidecar 代理
- 應用容器

性能
- API gateway
- Ingress 控制器
- Sidecar 代理
- 應用容器

成本
- API gateway
- Ingress 控制器
- Sidecar 代理
- 應用容器

可移植性
- API gateway
- Ingress 控制器
- Sidecar 代理
- 應用容器

複雜性
- API gateway
- Ingress 控制器
- Sidecar 代理
- 應用容器

並非所有服務對授權的要求都相同。你還可以結合本文中討論的模式。例如，你可以在大多數服務前放置一個具有粗粒度訪問控制的基本授權工作流程。然後，你可以依賴具有策略信息點的 sidecar 代理，為特定服務的授權決策注入額外的動態上下文。最後，如果某些服務的某些使用案例需要複雜的授權決策，你可以對代碼庫的特定部分進行應用級別的授權。

結論

在這篇博客文章中，我們探討了將 Verified Permissions 整合到容器化環境中的四種模式。我們討論了在不同層次上實施 Verified Permissions 的好處和考量：從 Kubernetes 集群外的 API gateway，到集群內的網絡組件（如 Ingress 控制器和 sidecar 代理），再到應用內部的授權。我們看到了每種模式提供的獨特優勢。我們還討論了為你的情況找到合適選項的考量以及何時結合模式。

通過使用 Verified Permissions，組織可以在其容器化工作負載中實施一致的細粒度授權，無論它們是在本地運行、在雲中運行還是混合環境中運行。這種集中式授權方法可以增強安全性並簡化策略管理和應用開發。

要了解更多關於實施這些模式和最佳實踐的信息，請訪問 Amazon Verified Permissions 用戶指南。對於動手體驗，我們建議探索 Verified Permissions 工作坊，該工作坊提供實際示例和指導練習。

如果你對這篇文章有反饋，請在下方的評論部分提交評論。如果你對這篇文章有疑問，請聯繫 AWS 支援。

Manuel Heinkel
Manuel 是 AWS 的解決方案架構師，與德國的軟件公司合作，在雲中構建創新和安全的應用。他支持客戶解決業務挑戰並在 AWS 上取得成功。Manuel 在安全和 SaaS 主題上有深入研究的記錄。工作之外，他喜歡與家人共度時光並探索山脈。

Markus Kokott
Markus 是 AWS 的高級解決方案架構師，專門指導軟件公司成為成功的 SaaS 提供商。他在諮詢以及設計、構建和運營軟件產品方面擁有超過十年的經驗，擅長在業務和技術之間架起橋樑。Markus 對容器、平台工程和 DevOps 充滿熱情，利用他的專業知識推動創新和效率。

新聞來源

本文由 AI 台灣 運用 AI 技術編撰，內容僅供參考，請自行核實相關資訊。
歡迎加入我們的 AI TAIWAN 台灣人工智慧中心 FB 社團，
隨時掌握最新 AI 動態與實用資訊！