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 政策
  • Mesh Edge 安全性
    • 叢集輸入端存取權控管
    • 規範叢集輸出流量
    • 使用私人叢集或 VPC Service Control 鎖定外部存取權
    • 防範外部 DDoS 攻擊
  • 網格管理和自動化功能的安全性
    • 區隔用於網格運算的角色
    • 自動驗證政策設定
      • 搭配使用 GitOps 和 Config Sync，避免設定偏移
    • 強制執行稽核記錄和監控功能
    • 保護叢集內憑證的憑證授權單位
  • 工作負載安全性
    • 限制 Pod 權限
    • 安全的容器映像檔
    • 降低網格安全漏洞的風險
    • 使用 Workload Identity Federation for GKE 安全存取 Google 服務
    • 透過安全性資訊主頁和遙測資料監控安全性狀態
  • 機密使用者資料和憑證的安全性

簡介

Cloud Service Mesh 提供的功能和工具可協助您以統一方式觀察、管理及保護服務。它採用以應用程式為中心的方法，並使用可信任的應用程式身分，而非以網路 IP 為重點的方法。您可以公開部署服務網格，而無須修改現有的應用程式程式碼。Cloud Service Mesh 可宣告式控制網路行為，有助於將負責提供及發布應用程式功能的團隊工作，與負責安全性和網路的管理員工作分開。

Cloud Service Mesh 以開放原始碼的 Istio 服務網格為基礎，可支援複雜的設定和拓樸。視貴機構的結構而定，一或多個團隊或角色可能會負責安裝及設定網格。預設的 Cloud Service Mesh 設定可用於保護應用程式，但在某些情況下，您可能需要自訂設定，或是將特定應用程式、連接埠或 IP 位址排除在網格之外，以便授予例外狀況。因此，請務必設立控管機制，管理網狀結構設定和安全性例外狀況。

攻擊媒介和安全風險

攻擊媒介

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

• 資料竊取攻擊。例如從服務對服務流量竊聽機密資料或憑證的攻擊。
• 中間人攻擊。舉例來說，惡意服務會偽裝成合法服務，以便取得或修改服務間的通訊。
• 權限提升攻擊。例如，攻擊者會利用非法存取權取得提升權限，在網路中執行操作。
• 阻斷服務 (DoS) 攻擊。
• 嘗試入侵及操控服務，以便對其他服務發動攻擊的殭屍網路攻擊。

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

• 內部網路攻擊。攻擊目標是竄改、竊聽或偽造網格內部服務對服務或服務對控制層的通訊。
• 控制層攻擊。攻擊目標是讓控制層發生故障 (例如拒絕服務攻擊)，或從控制層竊取機密資料。
• 網格邊緣攻擊。攻擊目標是竄改、竊聽或偽造網格輸入或輸出時的通訊。
• 網格運算攻擊。針對網格運算的攻擊。攻擊者可能會嘗試取得提升權限，以便在網格中執行惡意操作，例如修改安全性政策和工作負載映像檔。

安全性風險

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

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

保護服務網格的措施

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

安全架構

服務網格的安全性取決於網格系統及其應用程式不同層級的元件安全性。建議的 Cloud Service Mesh 安全性態度高層意圖，是透過整合不同層級的多種安全機制來保護服務網格，共同在零信任安全性模型下達成整體系統安全性。下圖顯示建議的 Cloud Service Mesh 安全性防護措施。

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

• 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) 會強制執行工作負載間的流量加密和驗證。
  • 代管 CA (例如 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 儲存憑證或其他機密資料。CA 服務用於為網格工作負載核發憑證，支援由 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 版本，以符合安全性和法規遵循要求。

詳情請參閱「Cloud Service Mesh 範例：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 驗證可套用至外部流量的入口閘道，或套用至網狀結構內流量的內部服務。如果 JWT 用於代表終端呼叫端的憑證，且要求的服務需要證明自己是代表終端呼叫端呼叫，則可以將 JWT 驗證與 mTLS 驗證結合。強制執行 JWT 驗證，可防範攻擊者未經有效憑證，且以實際使用者的名義存取服務。

Cloud Service Mesh 使用者驗證

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

強制執行授權政策

Cloud Service Mesh 授權政策可控管下列項目：

• 允許存取服務的使用者或物件。
• 可存取哪些資源。
• 可對允許的資源執行哪些作業。

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

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

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

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

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

強制執行存取網格服務的權杖交換程序

為了防範權杖重播攻擊，竊取權杖並重複使用竊取的權杖存取網狀網路服務，網狀網路邊緣應將網狀網路外部要求中的權杖，換成短效的網狀網路內部權杖。

網格服務必須驗證並授權網格外部存取網格服務的要求，因此要求中必須包含 JWT 或 Cookie 等權杖。來自網格的符記可能會保留很長一段時間。為防範權杖重送攻擊，您應將來自網格外部的權杖，換成網格內部短期權杖，並在網格輸入端限制其範圍。網格服務會驗證網格內部權杖，並根據網格內部權杖授權存取要求。

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

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

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

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

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

當 Cloud Service Mesh 安全政策 (無論是故意或意外) 遭到某個連接埠或 IP 規避時，應採取其他安全措施來保護網格，並監控安全例外狀況、潛在的安全漏洞，以及整體安全執行狀態。如要在這種情況下確保網格安全，您可以：

• 請務必確保繞過 sidecar 的流量已完成原生加密和驗證，以防範中間人攻擊。
• 強制執行 Kubernetes 網路政策，限制具有政策例外的通訊埠連線 (例如，限制具有政策例外的通訊埠，只允許來自相同命名空間的其他服務流量)，或只允許流量透過已強制執行 Cloud Service Mesh 安全性政策的通訊埠。
• 強制執行 GKE Enterprise 政策控制器，自動驗證 Cloud Service Mesh 政策。例如，強制要求 Cloud Service Mesh 側邊車一律注入工作負載。

強制執行 Kubernetes 網路政策

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

為服務網格建立強大的安全防護機制，請強制執行基礎平台的安全機制，讓這些機制與 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 Network Policy，限制具有政策例外的連接埠。例如，將此類通訊埠的連線限制在命名空間內。

安全的控制層存取權

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 的詳細指南和範例，請參閱「設定角色型存取權控管」。啟用 GKE 的 Workload Identity Federation 後，您也可以讓 Kubernetes 服務帳戶充當 IAM 服務帳戶。

Mesh 邊緣安全性

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

叢集入口存取權控管

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

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

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

規範叢集輸出流量

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

除了使用 VPC 防火牆限制輸出流量，網格管理員也應為叢集強制執行輸出安全政策，並將傳出流量設為透過輸出閘道傳送。

外連政策可緩解下列攻擊：

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

套用至輸出閘道的授權政策可確保只有經過授權的服務才能將流量傳送至網格外部的特定主機。同時，如果是離開網格的流量，TLS 可以從出口閘道產生，而非在個別補充 Proxy 中處理 TLS 來源。這可提供一致且更安全的方式來產生 TLS 流量，因為 mTLS 的用戶端憑證可與應用程式執行的命名空間隔離。

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

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

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

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

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

防範外部 DDoS 攻擊

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

網格管理和自動化功能的安全性

請務必考量管理作業的安全性，以及您在網格中建立的任何自動化作業，例如 CI/CD。以下做法旨在確保網格能安全運作，不會讓服務暴露於其他攻擊風險。

區分用於網格運算的角色

根據角色式存取權控管的相同原則，網格使用者應根據其角色進行分類。每個角色應只授予該角色所需的最低權限組合。

舉例來說，負責服務部署作業的使用者組合不應具備更新驗證和授權政策的權限。

運算子分為不同類別。例如叢集運算子和命名空間運算子。請務必防止運算子提升權限，否則可能會導致未經授權的資源遭到非法存取。

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

自動驗證政策設定

操作員可能會不小心錯誤設定 Cloud Service Mesh 政策，進而導致嚴重的安全事件。為避免設定錯誤並自動驗證 Cloud Service Mesh 政策，網格管理員可以使用政策控制器，在政策設定上強制執行限制。

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

Policy Controller 是以開放原始碼 Gatekeeper 專案為基礎，可做為 Kubernetes 許可控制器執行，拒絕套用無效資源，或在稽核模式下執行，以便向管理員發出違規警報。政策控制器可自動驗證網格中的資源部署作業，例如驗證部署作業上的註解不會略過 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 附屬程式一律會插入工作負載。

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

• 將命名空間排除在 Policy Controller 的許可 Webhook 執行機制之外，但仍會在稽核中回報任何違規情形。
• 將 Constraint spec.enforcementAction 設為 dryrun。雖然存取權限 webhook 不會阻止變更，但仍會在稽核中回報任何違規情形。
• 在限制範本中新增豁免邏輯 (範例)。

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

當網格中的政策設定偏離其可靠資料來源，就會發生設定偏移。您可以使用設定同步功能避免設定偏移。

強制執行稽核記錄和監控

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

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

這些可觀察性資源可用於驗證安全性設定是否正常運作，並監控安全性政策執行作業是否有任何例外狀況。例如未經過 sidecar 的存取權、未具有有效憑證但已存取服務的存取權。

雖然開放原始碼可觀察性軟體 (例如 Prometheus) 可搭配 Cloud Service Mesh 使用，但我們強烈建議您使用 Google Cloud 可觀察性 (原名為 Stackdriver)。 Google Cloud 內建的可觀察性解決方案提供記錄、指標收集、監控和快訊功能，且完全由 Google 管理，使用起來也相當簡單。

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

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

如果您使用的是自行管理的 Istio 憑證授權單位 (CA)，該 CA 會以 Istiod 的一部分形式代管，CA 簽署金鑰會儲存在 Kubernetes 密鑰中，且可供有權存取 istio-system 命名空間中密鑰資源的操作員存取。這會造成風險，因為作業人員可能會獨立於 Istiod 的 CA 使用 CA 金鑰，並可能獨立簽署工作負載憑證。自管 CA 簽署金鑰也可能因作業錯誤而意外外洩。

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

工作負載安全性

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

限制 Pod 權限

Kubernetes Pod 可能會擁有影響節點或叢集中其他 Pod 的權限。請務必對工作負載 Pod 強制執行安全性限制，以免遭到入侵的 Pod 對叢集發動攻擊。

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

• 在網格中部署的服務應以盡可能少的權限執行。
• 在特權模式下執行的 Kubernetes Pod 可操控主機上的網路堆疊和其他核心功能。您可以使用 GKE Enterprise 政策控制器防止 Pod 執行特權容器。
• Cloud Service Mesh 可設定為使用初始容器，將 iptables 流量重新導向至側邊車。因此，使用者必須具備 NET_ADMIN 和 NET_RAW 功能，才能部署容器。為避免以提升權限執行容器的風險，網格管理員可以改為啟用 Istio CNI 外掛程式，以便將流量重新導向至 sidecar。

安全的容器映像檔

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

減輕網格安全漏洞

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

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

如要讓網格工作負載安全地存取 Google 服務，建議您使用 Workload Identity Federation for GKE。在 Kubernetes 機密中儲存服務帳戶金鑰，並使用服務帳戶金鑰存取 Google 服務的做法，因憑證外洩、權限提升、資訊揭露和不否認性等風險，安全性較低。

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

服務網格可能會出現安全例外狀況和潛在漏洞。您必須顯示及監控網格的安全性狀態，包括強制執行的安全性政策、安全性例外狀況，以及網格中的潛在安全漏洞。您可以使用 GKE Enterprise 安全性資訊主頁和遙測功能，顯示及監控網格安全性狀態。

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

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

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

如果敏感的使用者資料或憑證儲存在叢集的永久性儲存空間 (例如使用 Kubernetes 密鑰或直接儲存在 Pod 中)，就可能遭到來自 Pod 或惡意操作的攻擊。如果透過網路傳輸，以便向服務進行驗證，也可能會遭到網路攻擊。

• 盡可能將機密使用者資料和憑證儲存在受保護的儲存空間中，例如 Secret Manager 和 Cloud KMS。
• 請為存取機密資料的 Kubernetes Pod 指定不同的命名空間，並定義 Kubernetes 政策，讓其他命名空間無法存取這些資料。區分用於作業的角色，並強制執行命名空間邊界。
• 強制執行權杖交換，防止長期有效且具有高度權限的權杖外洩。

後續步驟

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