Cloud Service Mesh 安全性最佳做法

本文說明如何建立及控管在 Google Kubernetes Engine (GKE) 上執行的安全 Cloud Service Mesh 設定，並提供相關最佳做法。本文件提供的指引不只說明如何設定及安裝 Cloud Service Mesh，也介紹如何搭配使用 Cloud Service Mesh 與其他 Google Cloud產品和功能，防範網格中應用程式可能面臨的安全威脅。

本文件適用於管理 Cloud Service Mesh 政策的管理員，以及在 Cloud Service Mesh 中執行服務的使用者。此外，如果機構需要提升服務網格的安全性，以符合法規遵循要求，也可以參考本文所述的安全防護措施。

本文的編排方式如下：

• 簡介
• 攻擊媒介和安全風險
  • 攻擊向量
  • 安全風險
• 保護服務網格的措施
  • 安全架構
  • 叢集安全性
    • 啟用嚴格的雙向 TLS
    • 啟用存取權控管
      • 強制執行 Cloud Service Mesh 驗證政策
      • JSON Web Token (JWT)
      • Cloud Service Mesh 使用者驗證
      • 強制執行授權政策
      • 強制執行權杖交換，以存取網格服務
    • 安全地處理 Cloud Service Mesh 政策例外狀況
      • 強制執行 Kubernetes 網路政策
    • 安全存取控制層
    • 強制執行命名空間界線
      • 強制執行 Kubernetes RBAC 政策
  • 網格邊緣安全
    • 叢集 Ingress 存取權控管
    • 控管叢集輸出流量
    • 使用私人叢集或 VPC Service Control 鎖定外部存取權
    • 防範外部 DDoS 攻擊
  • 網格管理和自動化安全防護
    • 區隔用於網格作業的角色
    • 自動驗證政策設定
      • 使用 Config Sync 搭配 GitOps 方法，避免設定偏移
    • 強制執行稽核記錄和監控
    • 保護叢集內憑證的憑證授權單位
  • 工作負載安全防護
    • 限制 Pod 權限
    • 確保容器映像檔安全無虞
    • 降低網格安全漏洞的影響
    • 使用 Workload Identity Federation for GKE 安全地存取 Google 服務
    • 透過安全性資訊主頁和遙測技術監控安全性狀態
  • 保護使用者機密資料和憑證的安全

簡介

Cloud Service Mesh 提供各種功能和工具，協助您以統一方式觀察、管理及保護服務。這項服務以應用程式為中心，並使用受信任的應用程式身分，而非以網路 IP 為中心。您可以透明地部署服務網格，不必修改現有的應用程式程式碼。Cloud Service Mesh 可對網路行為進行宣告式控制，有助於將負責交付及發布應用程式功能的團隊工作，與負責安全性和網路的管理員職責分開。

Cloud Service Mesh 以開放原始碼的 Istio 服務網格為基礎，可進行精密的設定和拓撲。視貴機構的架構而定，可能由一或多個團隊或角色負責安裝及設定網格。系統會選擇預設的 Cloud Service Mesh 設定來保護應用程式，但在某些情況下，您可能需要自訂設定或授予例外狀況，方法是從網格中排除特定應用程式、連接埠或 IP 位址。因此，請務必採取控管措施，管理網格設定和安全性例外狀況。

注意： 本指南是 Istio 安全性最佳做法說明文件的補充資料，其中包含相互 TLS (mTLS)、授權政策、閘道和其他安全性設定的詳細設定建議。您應將這些建議視為基礎，並搭配本指南討論的最佳做法使用。本指南說明 Cloud Service Mesh 的其他最佳做法，以及如何運用 Google Cloud 技術保護網格中的所有層級、元件和資訊流。

攻擊媒介和安全風險

攻擊向量

Cloud Service Mesh 安全性遵循零信任安全模型，假設安全威脅來自機構安全邊界內外。以下列舉幾種可能威脅服務網格中應用程式的安全攻擊類型：

• 資料竊取攻擊。舉例來說，攻擊者可能會竊聽服務對服務流量中的機密資料或憑證。
• 中間人攻擊。舉例來說，惡意服務可能會偽裝成合法服務，藉此取得或修改服務之間的通訊內容。
• 權限提升攻擊。舉例來說，攻擊者可能會非法取得網路中的高權限，然後進行作業。
• 阻斷服務 (DoS) 攻擊。
• 殭屍網路攻擊，企圖入侵及操控服務，對其他服務發動攻擊。

您也可以根據攻擊目標將攻擊分類：

• 防範內部網路攻擊。攻擊目標是竄改、竊聽或偽造網格內部服務對服務或服務對控制層的通訊。
• 控制層攻擊。攻擊目的是要造成控制層故障 (例如 DoS 攻擊)，或是從控制層竊取機密資料。
• 網狀網路邊緣攻擊。攻擊目的是要竄改、竊聽或偽造網格輸入或輸出端的通訊內容。
• 網格作業攻擊。針對網格作業的攻擊。攻擊者可能會嘗試取得進階權限，在網格中執行惡意作業，例如修改安全政策和工作負載映像檔。

安全性風險

除了安全攻擊，網狀架構也面臨其他安全風險。以下列出幾種可能的安全性風險：

• 安全防護不完整。服務網格尚未設定驗證和授權政策，無法保護安全。舉例來說，網格中的服務未定義任何驗證或授權政策。
• 安全性政策例外狀況。為配合特定用途，使用者可以為特定流量 (內部或外部) 建立安全性政策例外狀況，將這些流量從 Cloud Service Mesh 安全性政策中排除。如要安全地處理這類情況，請參閱「安全地處理政策例外狀況」一節。
• 忽略圖片升級。網格中使用的映像檔可能會發現安全漏洞。您必須將網格元件和工作負載映像檔更新至最新版本，才能取得最新的安全漏洞修正程式。
• 缺乏維護 (沒有專業知識或資源)。網狀架構軟體和政策設定需要定期維護，才能運用最新的安全防護機制。
• 無法掌握情況。網格政策設定錯誤或不安全，以及網格流量/作業異常，都不會通知網格管理員。
• 設定漂移。 網格中的政策設定與可靠資料來源不一致。

保護服務網格的措施

本節將提供服務網格安全性的操作手冊。

安全架構

服務網格的安全性取決於網格系統和應用程式不同層級的元件安全性。建議的 Cloud Service Mesh 安全性態勢，是希望透過在不同層級整合多種安全機制，確保服務網格安全，在零信任安全模型下共同達成整體系統安全。下圖顯示建議的 Cloud Service Mesh 安全性狀態。

Cloud Service Mesh 提供多層安全防護，包括：

• 網格邊緣安全性
  • Cloud Service Mesh 入口安全防護功能可控管外部流量的存取權，並確保外部存取網格中服務公開的 API 時安全無虞。
  • Cloud Service Mesh 輸出安全防護功能可控管內部工作負載的輸出流量。
  • Cloud Service Mesh 使用者驗證 與 Google 基礎架構整合，可驗證從網頁瀏覽器到執行網頁應用程式的服務， 所發出的外部呼叫。
  • Cloud Service Mesh 閘道憑證管理功能會使用憑證授權單位服務，保護及輪替 Cloud Service Mesh 輸入和輸出閘道使用的私密金鑰和 X.509 憑證。
  • Cloud Armor 可防範外部分散式阻斷服務 (DDoS) 和第 7 層攻擊。這項服務可做為網頁應用程式防火牆 (WAF)，保護網格免於網路攻擊。例如，注入和遠端程式碼執行攻擊。
  • VPC 和 VPC Service Controls 可透過私人網路存取控管機制，保護網格邊緣。
• 叢集安全性
  • Cloud Service Mesh 雙向傳輸層安全標準 (mTLS) 會強制執行工作負載對工作負載的流量加密和驗證。
  • 代管的憑證授權單位 (例如 Cloud Service Mesh 憑證授權單位和憑證授權單位服務) 會安全地佈建及管理工作負載使用的憑證。
  • Cloud Service Mesh 授權會根據網格服務的身分和其他屬性，強制執行網格服務的存取權控管。
  • GKE Enterprise 安全性資訊主頁可監控工作負載的安全政策和 Kubernetes 網路政策設定。
  • Kubernetes 網路政策會根據 IP 位址、Pod 標籤、命名空間等，強制執行 Pod 存取權控管。
  • 控制層安全防護功能可防範控制層遭受攻擊。這項防護措施可防止攻擊者修改、利用或洩漏服務和網格設定資料。
• 工作負載安全防護
  • 請隨時掌握 Cloud Service Mesh 安全性版本，確保網格中執行的 Cloud Service Mesh 二進位檔沒有公開已知的安全漏洞。
  • Workload Identity Federation for GKE 可讓工作負載取得憑證，安全地呼叫 Google 服務。
  • Cloud Key Management Service (Cloud KMS) 可透過硬體安全模組 (HSM) 保護機密資料或憑證。舉例來說，工作負載可以使用 Cloud KMS 儲存憑證或其他機密資料。憑證授權單位服務：用於向網格工作負載核發憑證，支援由 Cloud KMS 管理的客戶專屬 HSM 支援簽署金鑰。
  • Kubernetes CNI (容器網路介面) 可避免權限提升攻擊，因為不需要使用具備權限的 Cloud Service Mesh 初始化容器。
• 操作人員安全
  • Kubernetes 角色型存取權控管 (RBAC) 會限制 Kubernetes 資源的存取權，並限制運算子權限，以防範惡意運算子或運算子模擬行為發動攻擊。
  • GKE Enterprise Policy Controller 會驗證及稽核網格中的政策設定，防止設定錯誤。
  • Google Cloud 二進位授權可確保網格中的工作負載映像檔是管理員授權的映像檔。
  • Google Cloud 稽核記錄會稽核網格作業。

下圖顯示 Cloud Service Mesh 中整合式安全解決方案的通訊和設定流程。

叢集安全性

啟用嚴格的雙向 TLS

中間人 (MitM) 攻擊會試圖在兩個通訊方之間插入惡意實體，藉此竊聽或操控通訊內容。Cloud Service Mesh 會對所有通訊方強制執行 mTLS 驗證和加密，防範中間人攻擊和資料外洩攻擊。寬鬆模式會在雙方都支援 mTLS 時使用 mTLS，但允許不使用 mTLS 的連線。相較之下，嚴格 mTLS 要求流量必須透過 mTLS 加密及驗證，且不允許純文字流量。

Cloud Service Mesh 可讓您設定 TLS 連線的最低 TLS 版本，確保工作負載之間的 TLS 連線符合安全性和法規遵循要求。

詳情請參閱「Anthos Service Mesh by example: mTLS | Enforcing mesh-wide mTLS」(Anthos 服務網格範例：mTLS | 強制執行網格範圍的 mTLS)。

啟用存取控管

除非有充分理由將服務或 Pod 排除在 Cloud Service Mesh 安全性政策之外，否則應對進出網格的所有流量強制執行 Cloud Service Mesh 安全性政策 (例如驗證和授權政策)。在某些情況下，使用者可能基於正當理由，需要略過部分連接埠和 IP 範圍的 Cloud Service Mesh 安全性政策。舉例來說，如要與 Cloud Service Mesh 未管理的服務建立原生連線，如要在這類使用情境下保護 Cloud Service Mesh，請參閱「安全地處理 Cloud Service Mesh 政策例外狀況」。

服務存取權控管對於防止未經授權存取服務至關重要。強制執行 mTLS 會加密及驗證要求，但網格仍需Cloud Service Mesh 授權政策，才能對服務強制執行存取權控管。舉例來說，拒絕來自已驗證用戶端的未授權要求。

Cloud Service Mesh 授權政策提供彈性的存取控管設定方式，可保護服務免於未經授權的存取。Cloud Service Mesh 授權政策應根據驗證結果 (mTLS 或 JSON Web Token (JWT) 驗證) 衍生的已驗證身分強制執行，並一併做為 Cloud Service Mesh 授權政策的一部分。

強制執行 Cloud Service Mesh 驗證政策

JSON Web Token (JWT)

除了 mTLS 驗證，網格管理員也可以要求服務根據 JWT 驗證及授權要求。 Cloud Service Mesh 不會做為 JWT 提供者，但會根據設定的 JSON Web 金鑰集 (JWKS) 端點驗證 JWT。JWT 驗證可套用至 Ingress 閘道 (適用於外部流量)，或套用至內部服務 (適用於網格內流量)。當 JWT 用做代表最終呼叫端的憑證，且所要求服務需要證明是代表最終呼叫端呼叫時，JWT 驗證可與 mTLS 驗證合併使用。強制執行 JWT 驗證可防範攻擊，避免攻擊者在沒有有效憑證的情況下存取服務，並冒充真實使用者。

Cloud Service Mesh 使用者驗證

Cloud Service Mesh 使用者驗證是整合式解決方案，可為工作負載提供以瀏覽器為基礎的使用者驗證和存取權控管。這項服務會將服務網格與現有的身分識別提供者 (IdP) 整合，實作標準的網頁式 OpenID Connect (OIDC) 登入和同意流程，並使用 Cloud Service Mesh 授權政策進行存取權控管。

強制執行授權政策

Cloud Service Mesh 授權政策可控管：

• 允許誰或哪些項目存取服務。
• 可存取的資源。
• 可對允許的資源執行哪些作業。

授權政策是一種多用途的存取權控管設定方式，可根據服務實際執行的身分、流量的應用程式層 (第 7 層) 屬性 (例如要求標頭)，以及網路層 (第 3 層和第 4 層) 屬性 (例如 IP 範圍和連接埠) 進行設定。

應根據驗證結果衍生的已驗證身分，強制執行 Cloud Service Mesh 授權政策，防範未經授權存取服務或資料。

根據預設，除非明確定義授權政策來允許存取服務，否則應拒絕存取服務。如要查看拒絕存取要求的授權政策範例，請參閱「授權政策最佳做法」。

授權政策應盡可能限制信任關係。舉例來說，您可以根據服務公開的個別網址路徑定義服務存取權，這樣只有服務 A 可以存取服務 B 的路徑 /admin。

授權政策可與 Kubernetes 網路政策搭配使用，後者只會在網路層 (第 3 層和第 4 層) 運作，並控管 Kubernetes Pod 和 Kubernetes 命名空間中 IP 位址和連接埠的網路存取權。

注意： Cloud Service Mesh 不會處理非 TCP 流量 (例如 UDP)，因此授權政策無法控管這類流量。網格管理員可以使用 Kubernetes 網路政策，定義 UDP 流量的政策。舉例來說，如果網格服務未使用 UDP，網格管理員可以定義 Kubernetes 網路政策，封鎖 UDP 流量。

強制執行權杖交換，以存取網格服務

為防範權杖重送攻擊 (這類攻擊會竊取權杖，並重複使用竊取的權杖來存取網格服務)，來自網格外部的要求中的權杖應在網格邊緣交換為短期網格內部權杖。

如要從網格外部存取網格服務，要求必須包含權杖 (例如 JWT 或 Cookie)，才能通過網格服務的驗證和授權。網狀網路外部的權杖可能具有長期效力。為防範權杖重送攻擊，來自網格外部的權杖應在網格的輸入端，換成範圍有限的短期網格內部權杖。網格服務會驗證網格內部權杖，並根據網格內部權杖授權存取要求。

Cloud Service Mesh 支援與 Identity-Aware Proxy (IAP) 整合，後者會產生 RequestContextToken (從外部權杖交換而來的短期網格內部權杖)，用於 Cloud Service Mesh 的授權作業。有了權杖交換機制，攻擊者就無法使用在網格中竊取的權杖存取服務。交換權杖的範圍和效期有限，因此可大幅降低權杖重送攻擊的機率。

注意： IAP 權杖交換與 Cloud Service Mesh 使用者驗證不同，前者會將外部權杖換成短期內部權杖，以防範權杖重送攻擊，後者則會透過網頁瀏覽器對網頁應用程式服務進行外部呼叫。

安全處理 Cloud Service Mesh 政策例外狀況

您可能會遇到服務網格的特殊用途。舉例來說，您可能需要將特定網路連接埠公開給純文字流量。為因應特定使用情境，您有時可能需要建立例外狀況，允許特定內部或外部流量排除在 Cloud Service Mesh 安全性政策之外，但這會造成安全性疑慮。

您可能基於正當理由，需要對某些通訊埠和 IP 範圍略過 Cloud Service Mesh 安全性政策。您可以將註解 (例如 excludeInboundPorts、excludeOutboundPorts、excludeOutboundIPRanges) 新增至 Pod，排除由 Envoy Sidecar 處理的流量。除了使用註解排除流量，您也可以停用補充注入，藉此部署應用程式，完全略過網格。 例如，為應用程式 Pod 新增 sidecar.istio.io/inject="false" 標籤。

略過 Cloud Service Mesh 安全性政策會對整體系統安全性造成負面影響。舉例來說，如果透過註解略過網路通訊埠的 Cloud Service Mesh mTLS 和授權政策，該通訊埠的流量就不會受到存取權控管，可能遭到竊聽或修改。此外，略過 Cloud Service Mesh 政策也會影響非安全性政策，例如網路政策。

如果系統略過特定通訊埠或 IP 的 Cloud Service Mesh 安全性政策 (無論是刻意或無意)，您應採取其他安全措施，確保網格安全無虞，並監控安全例外狀況、潛在安全漏洞和整體安全強制執行狀態。如要在這類情境中保護網格安全，可以採取下列措施：

• 請確保繞過 Sidecar 的流量會經過原生加密和驗證，以防範中間人攻擊。
• 強制執行 Kubernetes 網路政策，限制通訊埠的連線 (例如限制通訊埠，只允許來自相同命名空間中其他服務的流量)，或只允許流量通過已強制執行 Cloud Service Mesh 安全性政策的通訊埠。
• 強制執行 GKE Enterprise Policy Controller，自動驗證 Cloud Service Mesh 政策。舉例來說，強制將 Cloud Service Mesh Sidecar 一律注入工作負載。

強制執行 Kubernetes 網路政策

Cloud Service Mesh 以基礎平台 (例如 Kubernetes) 為建構基礎。因此，Cloud Service Mesh 的安全性取決於底層平台的安全性。舉例來說，如果無法控管哪些使用者可以更新 Kubernetes 資源，使用者可能會變更服務的 Kubernetes 部署作業，藉此略過服務的 Sidecar。

如要為服務網格建立強大的安全防護機制，應強制執行基礎平台的安全機制，與 Cloud Service Mesh 安全性政策共同運作。

Kubernetes 網路政策會在網路層 (L3 和 L4) 運作，適用於 Kubernetes Pod 和命名空間的 IP 位址和通訊埠。您可以搭配使用 Kubernetes 網路政策和 Cloud Service Mesh 政策，進一步強化網格的安全性。

舉例來說，網格管理員可以設定 Kubernetes 網路政策，只允許流量使用已強制執行 Cloud Service Mesh 安全性政策的通訊埠。如果必須透過 Cloud Service Mesh mTLS 強制執行所有流量，管理員可以設定 Kubernetes 網路政策，只允許透過 Cloud Service Mesh mTLS 政策設定的連接埠傳輸流量。網格管理員也可以設定 Kubernetes 網路政策，限制具有政策例外的連接埠連線。舉例來說，將這類通訊埠的連線限制在命名空間內。

注意： Kubernetes 網路政策限制。雖然您可以使用 Kubernetes 網路政策防止不必要的連線，並限制因安全性政策遭到規避而產生的安全漏洞，但這項政策無法取代 Cloud Service Mesh 安全性政策，因為 Kubernetes 網路政策無法根據應用程式身分或其他第 7 層屬性提供存取權控管。此外，您只能在單一叢集中，將 Pod 和命名空間選取器用於 Kubernetes 網路政策。Pod IP 範圍可與多叢集網格搭配使用，但政策會比較粗略，維護時容易出錯。

安全控制層存取權

Cloud Service Mesh 控制層會驗證所有連線的用戶端。因此，只有具備有效憑證 (Kubernetes JWT 或允許的 CA 發行的 X.509 憑證) 的呼叫端，才能存取 Cloud Service Mesh 控制層。TLS 會加密工作負載與 Cloud Service Mesh 控制層之間的連線。

除了驗證機制外，對於叢集內 Cloud Service Mesh，您可以部署 Kubernetes 網路政策，將 Cloud Service Mesh 系統命名空間 (預設為 istio-system) 與網格外部的非受管理命名空間和用戶端隔離，同時允許資料層存取控制層。虛擬私有雲防火牆規則可防止叢集外部的流量到達 Istiod。有了這類網路隔離措施，即使攻擊者擁有有效憑證，也無法從網格外部存取控制層。如果是代管控制層，Google 會處理控制層的安全防護，因此不需要控制層的這類網路隔離政策。

強制執行命名空間界線

如要防止某個命名空間的使用者存取/更新未經授權命名空間中的資源，請按照下列步驟操作：

• 強制執行存取權控管。
• 強制執行 Kubernetes 網路政策。 如果命名空間中的服務沒有命名空間外部的流量，網格管理員應部署 Kubernetes 網路政策，只允許命名空間內的流量，不允許命名空間的輸入或輸出流量。
• 強制執行 Kubernetes RBAC 政策。
  • 應用程式管理員的角色應繫結至命名空間。
  • 只允許網格管理員擁有 ClusterRole。

強制執行 Kubernetes RBAC 政策

網格管理員應強制執行 Kubernetes RBAC 政策，控管哪些人可以存取及更新 Kubernetes 資源。Kubernetes 存取權控管可降低網格中的安全風險。舉例來說，未經授權的使用者不應變更 Kubernetes 部署作業，也不應規避 Cloud Service Mesh 政策強制執行作業。使用者的角色應繫結至命名空間，這樣使用者就無法存取超出所需範圍的命名空間。如需設定 RBAC 的詳細指南和範例，請參閱「設定角色型存取權控管」。啟用 Workload Identity Federation for GKE 後，您也可以允許 Kubernetes 服務帳戶做為 IAM 服務帳戶。

Mesh 邊緣安全性

由於大多數攻擊也可能源自叢集外部，因此確保網格邊緣的安全性至關重要。

叢集輸入存取權控管

Cloud Service Mesh 會透過 Ingress 閘道接收外部傳入流量。Ingress 閘道公開的服務可能會遭到外部來源攻擊。安全管理員應一律確保透過輸入閘道向外部流量公開的服務，具備足夠的安全性，可防禦攻擊。

Ingress 應針對向外部呼叫端公開的服務，強制執行驗證和授權。

• 強制執行叢集 Ingress 安全性政策。叢集需要接收外部流量時，網格管理員應強制執行連入安全性政策，包括 Cloud Service Mesh 閘道 TLS、驗證和授權政策，以驗證外部要求，並確認外部要求已獲授權存取連入閘道公開的服務。強制執行輸入安全政策可防範網格外部的攻擊，避免攻擊者在沒有有效憑證或權限的情況下，試圖存取服務。
• 使用 Cloud Armor 做為網頁應用程式防火牆 (WAF)，防範網路攻擊 (例如插入式攻擊和遠端執行攻擊)。詳情請參閱「從邊緣到網格：透過 GKE Ingress 開放服務網格應用程式」。

控管叢集輸出流量

叢集輸出安全機制對網格安全至關重要，因為輸出安全政策可以防範資料外洩攻擊、強制篩選輸出流量，以及強制執行輸出流量的 TLS 來源。安全管理員應控管及稽核叢集輸出流量。

除了使用虛擬私有雲防火牆限制輸出流量，網格管理員也應為叢集強制執行輸出安全政策，並將輸出流量設定為通過輸出閘道。

輸出政策可防範下列攻擊：

• 資料竊取攻擊。
• 如果未修補服務 Pod 的 CVE，攻擊者可能會加以利用。遭入侵的 Pod 可能會成為攻擊者控制的殭屍網路，用來傳送垃圾郵件或發動 DoS 攻擊。

套用至輸出閘道的授權政策可確保只有授權服務能將流量傳送至網格外部的特定主機。同時，對於離開網格的流量，TLS 可在輸出閘道發起，而非在個別補充 Proxy 發起。這樣一來，由於 mTLS 的用戶端憑證可與應用程式執行的命名空間隔離，因此能以一致且更安全的方式產生 TLS 流量。

使用私人叢集或 VPC Service Control 鎖定外部存取權

除了強制執行輸入和輸出安全政策，也請盡可能使用私人叢集或 VPC Service Controls 鎖定外部存取權。安全政策由網格安全管理員控管，但機構安全管理員可以強制執行私人叢集設定或 VPC Service Controls。

您可以強制執行 VPC Service Controls，為服務定義安全範圍，以便：

• 限制服務存取外部資源。
• 限制外部人士存取安全防護範圍內的服務。

VPC Service Controls 可協助防範資料竊取攻擊，並防止外部攻擊者存取網格內的服務。

防範外部 DDoS 攻擊

外部 DDoS 攻擊可能會導致 Ingress 閘道和後端服務超載，進而無法處理合法要求。Cloud Armor 可用於防範 DDoS 攻擊。Cloud Armor 不僅能防範網路層 (L3 和 L4) DDoS 攻擊，也能防範應用程式層 (L7) DDoS 攻擊。

網格管理和自動化安全防護

請務必考量管理作業的安全性，以及您在網格周圍建構的任何自動化功能 (例如 CI/CD)。下列做法旨在確保網格安全運作，避免服務暴露於額外攻擊的風險。

區隔用於網格作業的角色

與角色型存取權控管的原則相同，網格使用者應根據角色分類。每個角色都應只獲得該角色所需的最低權限。

舉例來說，負責部署服務的使用者群組不應擁有更新驗證和授權政策的權限。

運算子可分為不同類別。例如叢集運算子和命名空間運算子。請務必防止運算子提升權限，以免未經授權存取資源。

Kubernetes RBAC 政策可讓網格管理員限制資源存取權，只允許授權使用者存取。

自動驗證政策設定

運算子可能會不小心誤設 Cloud Service Mesh 政策，導致發生嚴重安全事件。為避免設定錯誤並自動驗證 Cloud Service Mesh 政策，網格管理員可以使用 Policy Controller，對政策設定強制執行限制。

為避免過度信任有權更新 Cloud Service Mesh 安全性政策的個人，並自動驗證 Cloud Service Mesh 政策，網格管理員應使用 Policy Controller 對 Cloud Service Mesh 政策實施限制。

Policy Controller 以開放原始碼 Gatekeeper 專案為基礎，可做為 Kubernetes 許可控制器執行，拒絕套用無效資源，或以稽核模式執行，讓管理員收到違規警示。Policy Controller 可自動驗證網格中資源的部署作業，例如驗證部署作業中的註解不會略過 Cloud Service Mesh 政策、驗證 Cloud Service Mesh 政策是否符合預期，以及驗證部署作業是否包含根功能 (例如 NET_ADMIN 和 NET_RAW)。

Policy Controller 也能稽核現有的 Cloud Service Mesh 資源是否符合限制，偵測政策設定錯誤。

以下列舉幾個 GKE Enterprise Policy Controller 強制執行安全政策的範例：

• 禁止 Pod 執行特殊權限容器。
• 只允許使用特定存放區的映像檔，防止執行未經授權的容器映像檔。
• 禁止在 Istio DestinationRules 中，為所有主機和主機子集停用 TLS。
• 禁止 Istio AuthorizationPolicy 規則中的主體和命名空間使用指定清單中的前置字元。
• 禁止建立會將工作負載暴露於外部 IP 的已知資源。
• 只允許 Ingress 資源使用 HTTPS。
• 在容器上要求唯讀根檔案系統。

Policy Controller 隨附的限制範本程式庫包含一組限制範本，可與現成的Cloud Service Mesh 安全性限制套裝組合搭配使用，強制執行特定的 Cloud Service Mesh 安全性最佳做法，例如驗證、授權和流量政策。以下是套件中包含的幾個限制範例：

• 強制執行網格層級的嚴格 mTLS PeerAuthentication。
• 強制執行所有 PeerAuthentication，不得覆寫嚴格的 mTLS。
• 強制執行網格層級的預設拒絕 AuthorizationPolicy。
• 強制執行 AuthorizationPolicy 安全模式。
• 強制將 Cloud Service Mesh Sidecar 一律注入工作負載。

如要處理例外狀況和緊急情況，網格管理員可以：

• 排除命名空間， 不強制執行 Policy Controller 的許可 Webhook，但系統仍會在稽核中回報任何違規事項。
• 將 Constraint spec.enforcementAction 設為 dryrun。 准入 Webhook 不會阻止變更，但系統仍會在稽核中回報任何違規事項。
• 在限制範本中新增豁免邏輯 (範例)。

使用 GitOps 方法搭配 Config Sync，避免設定偏移

當網格中的政策設定偏離其真實來源時，就會發生設定漂移。您可以使用 Config Sync 避免設定偏移。

強制執行稽核記錄和監控

網格管理員應監控下列事項：

• Cloud 稽核記錄
• Cloud Service Mesh 稽核記錄
• 政策限制稽核記錄
• Anthos Config Sync
• 存取記錄
• 服務層級指標
• 存取追蹤記錄

這些可觀測性資源可用於確認安全性設定是否正常運作，並監控安全性政策強制執行的任何例外狀況。舉例來說，未透過 Sidecar 進行的存取、沒有有效憑證但連上服務的存取。

雖然開放原始碼可觀測性軟體 (例如 Prometheus) 可與 Cloud Service Mesh 搭配使用，但我們強烈建議使用 Google Cloud Observability (原名為 Stackdriver)。內建的 Google Cloud 可觀測性解決方案提供記錄、指標收集、監控和快訊功能，而且完全代管，方便使用。

保護叢內憑證的憑證授權單位

根據預設，Cloud Service Mesh 會使用名為「Cloud Service Mesh 憑證授權單位」的 Google 管理憑證授權單位 (CA)。

如果您使用未受管理的 Istio 憑證授權單位 (CA)，該單位會以 Istiod 的一部分形式代管，CA 簽署金鑰會儲存在 Kubernetes 密鑰中，且可供有權存取 istio-system 命名空間中密鑰資源的運算子使用。這是一項風險，因為運算子可能可以獨立使用 CA 金鑰，不必透過 Istiod 的 CA，並可能獨立簽署工作負載憑證。此外，作業錯誤也可能導致自行管理的 CA 簽署金鑰意外洩漏。

為保護 CA 簽署金鑰，網格管理員可以將網格升級為使用 Cloud Service Mesh 憑證授權單位或憑證授權單位服務 (CA 服務)，這些服務由 Google 管理並提供安全防護。與 Cloud Service Mesh 憑證授權單位相比，CA 服務支援透過 Cloud HSM 支援的 Cloud KMS，為每個客戶提供簽署金鑰。CA 服務也支援受監管的工作負載，但 Cloud Service Mesh 憑證授權單位不支援。

工作負載安全性

工作負載安全防護功能可防範攻擊，避免工作負載 Pod 遭到入侵，然後利用遭入侵的 Pod 對叢集發動攻擊 (例如殭屍網路攻擊)。

限制 Pod 權限

Kubernetes Pod 可能具有影響節點或叢集上其他 Pod 的權限。請務必對工作負載 Pod 實施安全限制，防止遭入侵的 Pod 對叢集發動攻擊。

如要對 Pod 上的工作負載強制執行最低權限原則，請按照下列步驟操作：

• 在網格中部署的服務應盡可能以最少的權限執行。
• 以特權模式執行的 Kubernetes Pod 可以操控主機上的網路堆疊和其他核心功能。您可以使用 GKE Enterprise Policy Controller 防止 Pod 執行具備特殊權限的容器。
• 您可以將 Cloud Service Mesh 設定為使用 init 容器，將 iptables 流量重新導向至 Sidecar。這項作業需要使用者具備權限，才能部署具有 NET_ADMIN 和 NET_RAW 功能的容器。為避免以提升的權限執行容器的風險，網格管理員可以啟用 Istio CNI 外掛程式，設定將流量重新導向至 Sidecar。

保護容器映像檔

攻擊者可能會利用有安全漏洞的容器映像檔發動攻擊。 管理員應強制執行二進位授權，驗證容器映像檔的完整性，確保網格中只會部署受信任的容器映像檔。

減輕網格安全漏洞導致的損害

• 容器分析。 容器分析可以掃描並顯示 GKE 工作負載的安全漏洞。
• 處理 CVE (常見安全漏洞與弱點)。在容器映像檔中發現安全漏洞後，網格管理員應盡快修正安全漏洞。如果是代管 Cloud Service Mesh 搭配代管資料層，Google 會自動修補影響網格映像檔的 CVE。

使用 Workload Identity Federation for GKE 安全地存取 Google 服務

建議您使用 Workload Identity Federation for GKE，讓網格工作負載安全地存取 Google 服務。將服務帳戶金鑰儲存在 Kubernetes 密碼中，並使用服務帳戶金鑰存取 Google 服務，這種做法並非安全無虞，因為有憑證外洩、權限提升、資訊揭露和不可否認性等風險。

透過安全性資訊主頁和遙測技術監控安全性狀態

服務網格可能會有安全性例外狀況和潛在漏洞。因此，找出並監控網格的安全狀態至關重要，包括強制執行的安全政策、安全例外狀況，以及網格中潛在的安全漏洞。GKE Enterprise 安全性資訊主頁和遙測資料可用於顯示及監控網格安全性狀態。

遙測 可監控網格中服務的健康狀態和效能，讓網格管理員觀察服務的行為 (例如服務等級目標、異常流量、服務中斷、拓撲)。

GKE Enterprise 安全性資訊主頁會分析並顯示套用至服務網格中工作負載的安全政策，包括存取控制政策 (Kubernetes 網路政策、二進位授權政策和服務存取控制政策) 和驗證政策 (mTLS)。

保護機密使用者資料和憑證

如果敏感的使用者資料或憑證儲存在叢集永久儲存空間 (例如使用 Kubernetes 密碼或直接在 Pod 中)，就可能遭到來自 Pod 或惡意作業的攻擊。如果透過網路傳輸這些憑證來驗證服務，也容易遭到網路攻擊。

• 如有可能，請將機密使用者資料和憑證儲存在受保護的儲存空間，例如 Secret Manager 和 Cloud KMS。
• 為存取機密資料的 Kubernetes Pod 指定個別命名空間，並定義 Kubernetes 政策，禁止其他命名空間存取這些 Pod。區隔用於作業的角色，並強制執行命名空間界線。
• 強制執行權杖交換，防止長期高權限權杖遭竊。

後續步驟

• 查看在 GKE 叢集中使用 Cloud Service Mesh 輸出閘道的最佳做法
• 設定傳輸安全性
• 更新授權政策