準備部署 Amazon Web Services （AWS） 網頁應用程式工作負載到 Azure

本文提供全面指南，說明如何部署一個穩健且可生產環境的基礎架構，以促進 Azure 平台上網頁應用程式的託管、保護、擴展與監控。

在 AWS 上部署 Yelb

AWS 上的 Yelb 範例網頁應用程式是使用 Bash、 AWS CLI、 eksctl、 kubectl 和 Helm 部署的。 配套程式 sample 包含 Bash 腳本與 YAML 清單，可用於自動化部署 Yelb 應用程式於 AWS Elastic Kubernetes Service （EKS）。 此解決方案示範如何利用 AWS WAF 實作網頁應用防火牆，以保護運行於 Amazon Elastic Kubernetes Service（EKS）上的網頁應用程式。 你可以用 Bash 腳本建立 EKS 叢集並部署 Yelb 應用程式。 Yelb Web 應用程式透過 Amazon Application Load Balancer（ALB） 對外公開至公用網際網路，並使用 AWS WAF Web 存取控制清單（web ACL） 加以保護。 詳細說明請參閱 將網頁應用程式從 AWS Elastic Kubernetes Service（EKS）移植至 Azure Kubernetes Service (AKS)。

這是 Yelb 服務介面的截圖。

Yelb 在 Azure 上的部署

在接下來的章節中，你會學習如何在 Azure Kubernetes Service (AKS) 叢集上部署 Yelb範例網頁應用程式，並透過像 NGINX 入口控制器 這樣的入口控制器來公開。 入口控制器服務可透過 內部（或私有）負載平衡器存取，該負載平衡器在包含 AKS 叢集的虛擬網路內進行流量平衡。 在混合情境中，負載平衡器的前端可從本地網路存取。 想了解更多內部負載平衡，請參見 使用內建負載平衡器搭配 Azure Kubernetes Service (AKS)。

配套的 範例 支援安裝 搭配應用程式路由附加元件的受控 NGINX 輸入控制器，或使用 Helm 圖表 安裝非受控的 NGINX 輸入控制器。 搭配 NGINX 入口控制器的應用程式路由外掛提供以下功能：

針對其他組態，

為了增強安全性，Yelb 應用程式受到 Azure 應用程式閘道 資源保護。 此資源部署於與 AKS 叢集同一虛擬網路內的專用子網路，或是對等虛擬網路中。 Azure Web 應用程式防火牆 (WAF) 可保護對託管於 Azure Kubernetes Service (AKS) 並透過 Azure 應用程式閘道 對外公開的 Web 應用程式之存取，使其免受常見攻擊手法和弱點的威脅。

Prerequisites

Architecture

本範例提供一系列 Bicep 範本、Bash 指令碼及 YAML 清單，用於建置 AKS 叢集、部署 Yelb 應用程式、使用 NGINX ingress controller 對外公開 UI 服務，並透過 Azure 應用程式閘道 和 Azure Web 應用程式防火牆 (WAF) 加以保護。

此範例還包含兩個獨立的 Bicep 參數檔案，以及兩組 Bash 腳本與 YAML 清單，各自針對部署兩種不同的解決方案方案。 欲了解更多Bicep資訊，請參見 什麼是Bicep？

在應用閘道終止 TLS 及透過 HTTP 呼叫 Yelb

在此解決方案中，Azure Web 應用程式防火牆（WAF）透過阻擋惡意攻擊來確保系統安全。 Azure 應用程式閘道接收來自用戶端應用程式的來電，執行 TLS 終止，並將請求轉發至 AKS 託管的 yelb-ui 服務。 此通訊透過內部負載平衡器與 NGINX 入口控制器，使用 HTTP 傳輸協定來實現。 下圖說明了該架構：

基於 HTTP 應用閘道 WAFv2 與 NGINX 入口控制器的解決方案示意圖。

訊息流程如下：

基於應用閘道 WAFv2 與 NGINX 入口控制器透過 HTTP 的解決方案訊息流程示意圖。

  1. Azure 應用程式閘道負責TLS終止，並透過HTTP向AKS託管的yelb-ui服務發送來電。
  2. 應用閘道監聽器使用來自 Azure Key Vault 取得的 SSL 憑證以確保通訊安全。
  3. 與監聽器相關的 Azure WAF 政策會對收到的請求套用 OWASP 規則和自訂規則，有效防止多種惡意攻擊。
  4. 應用閘道後端 HTTP 設定透過 HTTP 埠 80 呼叫 Yelb 應用程式。
  5. 應用閘道後端池與健康探針透過 AKS 內部負載平衡器呼叫 NGINX 入口控制器 ，使用 HTTP 協定進行流量管理。
  6. NGINX 入口控制器使用 AKS 內部負載平衡器以確保叢集內的安全通訊。
  7. Kubernetes Ingress 物件使用 NGINX Ingress Controller，透過內部負載平衡器經由 HTTP 對外提供應用程式。
  8. yelb-ui使用該ClusterIP類型的服務會限制其呼叫範圍僅限於叢集內部或透過 NGINX 入口控制器。

使用 Azure 應用程式閘道 實作端對端 TLS

TLS 終止

Azure 應用程式閘道 支援閘道層級的 TLS 終止，意即流量在閘道器解密後再送往後端伺服器。 要設定 TLS 終止，你需要在監聽器上新增 TLS/SSL 憑證。 憑證應採用個人資訊交換（Personal Information Exchange，PFX）格式，包含私鑰與公鑰。 你可以將憑證從 Azure Key Vault 匯入到 Application Gateway。 如需詳細資訊，請參閱使用 金鑰保存庫 憑證終止 TLS。

零信任安全性模型

如果你採用零信任安全模型，應該避免像 Azure 應用程式閘道 這樣的服務代理與後端伺服器之間進行未加密的通訊。 在 零信任 安全模型中，任何試圖存取網路資源的使用者或裝置，並不會自動獲得信任。 相反地，它要求每次請求都持續驗證身份並取得授權，無論使用者身處何地或網路為何。 在我們的情境中，實作 零信任 安全模型時，使用 Azure 應用程式閘道 作為服務代理，作為前端處理來電請求。 這些請求會以加密格式傳送到 Azure Kubernetes Service （AKS） 上的 NGINX 入口控制器。

端對端TLS搭配應用閘道

你可以透過設定 Azure 應用程式閘道 來實現 零信任 方法，與後端伺服器進行端對端 TLS 加密。 端對端 TLS 加密 讓您能安全地將敏感資料傳送到後端，同時利用 Application Gateway 的第 7 層負載平衡功能，包括基於 Cookie 的會話親和性、基於 URL 的路由、基於網站的路由，以及重寫或注入 X-Forwarded-* 標頭的能力。

當應用閘道設定為端對端 TLS 通訊模式時，會在閘道處終止 TLS 會話並解密使用者流量。 接著會根據已設定的規則，選擇適當的後端集區執行個體來將流量路由至該執行個體。 接著，應用閘道會啟動新的 TLS 連線給後端伺服器，並利用後端伺服器的公鑰憑證重新加密資料，然後再將請求傳送到後端。 網頁伺服器的回應在抵達最終使用者前也會遵循相同的流程。 要啟用端對端 TLS，你需要在後端 HTTP 設定中將協定設定設為 HTTPS，並套用到後端池。 此方法確保你與後端伺服器的通訊安全且符合需求。

欲了解更多資訊，請參閱 應用閘道端對端 TLS 加密 及 保護應用閘道的最佳實務。

在此解決方案中，Azure Web 應用程式防火牆（WAF）透過阻擋惡意攻擊來確保系統安全。 Azure 應用程式閘道 會處理來自用戶端應用程式的傳入要求、執行 TLS 終止，並透過內部負載平衡器和 NGINX Ingress Controller，使用 HTTPS 傳輸協定呼叫底層由 AKS 託管的 服務，以實作 yelb-ui。 下圖說明了該架構：

基於應用閘道 WAFv2 與 NGINX 入口控制器（透過 HTTPS 的解決方案）示意圖。

訊息流程如下：

  1. Azure 應用程式閘道 負責 TLS 終止，並透過 HTTPS 與後端應用程式通訊。
  2. 應用閘道監聽器使用 從 Azure Key Vault 取得的 SSL 憑證。
  3. 與監聽器相關的 Azure WAF 政策會執行 OWASP 規則及自訂規則，以阻擋惡意攻擊。
  4. 應用閘道後端 HTTP 設定設定為透過 443 埠的 HTTPS 呼叫 AKS 託管 yelb-ui 服務。
  5. 應用閘道後端池與健康探針透過 AKS 內部負載平衡器使用 HTTPS 呼叫 NGINX 入口控制器 。
  6. NGINX 入口控制器部署為使用 AKS 內部負載平衡器。
  7. SAKS 叢集已設定 Azure Key Vault provider for Secrets Store CSI Driver 增益集，可透過 CSI 磁碟區從 Azure Key Vault 擷取祕密、憑證和金鑰。
  8. SecretProviderClass 用於從 金鑰保存庫 取回應用閘道所使用的憑證。
  9. Kubernetes Ingress 物件使用 NGINX Ingress Controller，透過 AKS 內部負載平衡器以 HTTPS 對外公開應用程式。
  10. 該 yelb-ui 服務有一個 ClusterIP 類型，限制其呼叫僅限於叢集內部或透過 NGINX 入口控制器。

為確保系統的安全性與穩定性，請考慮以下建議：

  • 定期更新 Azure WAF 政策，加入最新規則以確保最佳安全性。
  • 實施監控與記錄機制，以追蹤和分析來到的請求及潛在攻擊。
  • 定期維護與更新 AKS 叢集、NGINX 入口控制器及應用閘道，以解決安全漏洞並維護安全的基礎設施。
  • 實施監控與記錄機制，以追蹤和分析來到的請求及潛在攻擊。
  • 定期維護與更新 AKS 叢集、NGINX 入口控制器及應用閘道，以解決安全漏洞並維護安全的基礎設施。

Hostname

應用程式閘道監聽器與 Kubernetes 入口 設定為使用相同的主機名稱。 使用相同的主機名稱作為服務代理和後端網頁應用程式非常重要，原因如下：

  • 保留會話狀態：當你使用不同的主機名稱作為代理和後端應用程式時，會話狀態可能會遺失。 這表示使用者會話可能無法正常持續運作，導致使用者體驗不佳及資料遺失的風險。
  • 認證失敗：如果代理與後端應用程式的主機名稱不同，認證機制可能會失效。 此方法可能導致使用者無法登入或存取應用程式內的安全資源。
  • URL 的意外洩露：如果未保留主機名稱，後端 URL 可能會暴露給終端使用者。 這可能導致潛在的安全漏洞及敏感資訊的未經授權存取。
  • Cookie 問題：Cookie 在維護使用者會話及客戶端與伺服器間資訊傳遞中扮演關鍵角色。 當主機名稱不同時，Cookie 可能無法如預期運作，導致驗證失敗、會話處理不當及重定向錯誤等問題。
  • 端對端 TLS/SSL 需求：若代理與後端服務間需要端對端 TLS/SSL 進行安全通訊，則需為原始主機名稱提供匹配的 TLS 憑證。 使用相同的主機名稱簡化了憑證管理流程，並確保安全通訊能無縫建立。

你可以透過使用相同的主機名稱作為服務代理和後端網頁應用程式，來避免這些問題。 後端應用程式會看到與網頁瀏覽器相同的網域，確保會話狀態、認證及 URL 處理正常運作。

訊息流程

以下圖表顯示部署和執行階段期間的訊息流程步驟。

基於應用閘道 WAFv2 與 NGINX 入口控制器透過 HTTPS 的解決方案訊息流示意圖。

部署工作流程

以下步驟描述部署流程。 此工作流程對應前圖中的綠色數字。

  1. 安全工程師會為該工作負載所使用的自訂網域產生憑證，並將其儲存在 Azure 金鑰庫中。 你可以從知名 的認證機構（CA）取得有效的證書。
  2. 平台工程師會在 main.bicepparams Bicep 參數檔中指定必要資訊，並部署 Bicep 範本以建立Azure資源。 必要資訊包括：
    • Azure 資源的前綴。
    • 現有 Azure Key Vault 的名稱及資源群組，其中包含工作負載主機名稱和 Application Gateway 接聽程式自訂網域所使用的 TLS 憑證。
  3. 你可以設定部署 腳本 ，將以下套件安裝到你的 AKS 叢集。 欲了解更多資訊，請參閱 Bicep 模組的參數部分。
  4. Application Gateway 監聽器會從 Azure Key Vault 取得 TLS 憑證。
  5. Kubernetes ingress 物件會使用從 Azure Key Vault provider for Secrets Store CSI Driver 取得的憑證，透過 HTTPS 對外公開 Yelb UI 服務。
  6. 應用程式閘道監聽器會從 Azure 金鑰庫取得 TLS 憑證。
  7. Kubernetes Ingress 物件使用從 Azure Key Vault provider for Secrets Store CSI Driver 取得的憑證，透過 HTTPS 公開 Yelb UI 服務。

執行階段工作流程

  1. 用戶端應用程式會使用範例網頁應用程式的主機名稱呼叫。 與 Application Gateway 接聽程式自訂網域相關聯的 DNS 區域會使用 A 記錄，將 DNS 查詢解析為 Azure 公用 IP 位址；該位址供 Application Gateway 的前端 IP 組態使用。
  2. 請求會傳送到 Application Gateway 前端 IP 設定所使用的 Azure 公共 IP。
  3. 應用閘道執行以下動作：
    1. 應用閘道負責處理 TLS 終止，並透過 HTTPS 與後端應用程式通訊。
    2. 應用閘道監聽器使用 從 Azure Key Vault 取得的 SSL 憑證。
    3. 與監聽器相關的 Azure WAF 政策會針對收到的請求執行 OWASP 規則和自訂規則，並阻擋惡意攻擊。
    4. 應用閘道後端 HTTP 設定可透過 HTTPS 在 443 埠呼叫範例網頁應用程式。
  4. 應用閘道後端池透過 AKS 內部負載平衡器使用 HTTPS 呼叫 NGINX 入口控制器。
  5. 要求會傳送至裝載 NGINX 輸入控制器 Pod 的其中一個代理程序節點。
  6. 其中一個 NGINX 入口控制器副本處理請求並將請求發送給服務的 yelb-ui 其中一個端點。
  7. yelb-ui 呼叫 yelb-appserver 服務。
  8. yelb-appserver 會呼叫 yelb-db 和 yelb-cache 服務。
  9. yelb-ui 呼叫 yelb-appserver 服務。
  10. yelb-appserver 會呼叫 yelb-db 和 yelb-cache 服務。

Deployment

根據預設，Bicep 範本會安裝採用 Azure CNI Overlay 網路外掛和 Cilium 資料平面的 AKS 叢集。 你可以使用替代的網路外掛。 此外，專案展示了如何部署具備以下擴充功能與功能的 AKS 叢集：

在生產環境中，我們強烈建議部署具備 Uptime SLA 的私有 AKS 叢集。 欲了解更多資訊，請參閱 具有公開 DNS 位址的私有 AKS 叢集。

或者，你也可以部署公開的 AKS 叢集，並利用 授權的 IP 位址範圍來保護對 API 伺服器的存取。 如需詳細資訊及如何使用 Bicep 範本部署基礎架構Azure的說明，請參閱 companion Azure 範例程式碼範例。

在生產環境中，我們強烈建議部署具備 Uptime SLA 的私有 AKS 叢集。 欲了解更多資訊，請參閱 具有公共 DNS 位址的私有 AKS 叢集。 或者，你也可以部署公開的 AKS 叢集，並利用 授權的 IP 位址範圍來保護對 API 伺服器的存取。 如需詳細資訊及如何使用 Bicep 範本部署基礎設施於 Azure 上的說明，請參閱 配套Azure程式碼範例。

後續步驟

部署 AWS 網頁應用程式工作負載到 Azure

貢獻者們

本文由 Microsoft 維護。 下列參與者最初撰寫了這份內容：

主要作者：

其他貢獻者：

  • Last updated on