搭配 Istio API 的 Cloud Service Mesh 安全性最佳做法

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

本文件的目標對象包括管理 Cloud Service Mesh 政策的管理員，以及在 Cloud Service Mesh 中執行服務的服務擁有者。如要強化服務網格的安全性以符合法規遵循要求，這裡介紹的安全措施也能派上用場。

文件的結構如下：

簡介

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

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

本文件可與 Istio 的安全性最佳做法文件互補，其中包含雙向傳輸層安全標準 (mTLS)、授權政策、閘道和其他安全性設定的詳細設定建議。請將這些建議視為基礎，並搭配本文所述的最佳做法使用。本文件說明瞭 Cloud Service Mesh 的其他最佳做法，以及 Google Cloud 中的技術如何保護網格中的所有層級、元件和資訊流。

攻擊媒介和安全風險

攻擊媒介

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

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

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

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

安全性風險

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

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

保護服務網格的措施

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

安全架構

服務網格的安全性取決於網格系統及其應用程式不同層級的元件安全性。建議的 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 憑證。
    • VPC 和 VPC Service Controls 可透過私人網路存取控管機制保護邊緣裝置。
  • 叢集安全性
    • Cloud Service Mesh 雙向傳輸層安全標準 (mTLS) 會強制執行工作負載間的流量加密和驗證。
    • Cloud Service Mesh 憑證授權單位會安全地佈建及管理工作負載使用的憑證。
    • Cloud Service Mesh 授權會根據網格服務的身分和其他屬性，強制執行網格服務的存取權控管。
    • GKE Enterprise 安全性資訊主頁可監控工作負載的安全性政策和 Kubernetes NetworkPolicy 設定。
    • 以 IP 位址、Pod 標籤、命名空間等為依據的 Kubernetes 網路政策強制 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 二進位授權可確保網格中的負載映像檔為管理員授權的映像檔。
    • 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」。

啟用存取控管

建議您在網格中執行所有進出流量時，強制執行 Cloud Service Mesh 安全性政策 (例如驗證和授權政策)，除非有充分理由將服務或 Pod 排除在 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 驗證政策

在考量 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 層) 流量屬性 (例如要求標頭) 和網路層 (第 3 層和第 4 層) 屬性 (例如 IP 位址範圍和連接埠) 執行的實際身分，設定存取權控管。

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

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

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

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

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

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

網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務網格服務來自網格的符記可能會保留很長一段時間。為防範權杖重播攻擊，請在網格輸入端將網格外部權杖換成網格內部權杖，並限制其範圍。網格服務會驗證網格內部權杖，並根據網格內部權杖授權存取要求。

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 注入的應用程式，藉此完全略過網格，例如在應用程式 Pod 中新增標籤 sidecar.istio.io/inject="false"。

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

如果 Cloud Service Mesh 安全政策遭到繞過 (無論是故意或意外)，我們強烈建議您採取其他安全措施，確保網格安全，並監控安全例外狀況、潛在的安全漏洞，以及整體安全執行狀態。如要在這種情況下保護網格，您可以：

  • 請確認繞過 sidecar 的流量已完成原生加密和驗證，以防範中間人攻擊。
  • 強制執行 Kubernetes 網路政策，限制具有政策例外的通訊埠連線，例如限制具有政策例外的通訊埠，只允許來自相同命名空間的其他服務流量，或只允許流量透過已強制執行 Cloud Service Mesh 安全性政策的通訊埠。

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

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

強制執行 Cloud 稽核記錄和監控

我們建議網格管理員監控下列項目：

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

雖然開放原始碼可觀察性軟體 (例如 Prometheus) 可與 Cloud Service Mesh 搭配使用，但我們強烈建議您使用 Google Cloud 可觀察性。這個 Google Cloud 內建的可觀察性解決方案提供記錄、指標收集、監控和快訊功能，並由 Google 全權管理。

工作負載安全性

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

限制 Pod 權限

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

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

  • 在網格中部署的服務應以盡可能少的權限執行。
  • 您可以設定 Cloud Service Mesh，使用初始容器將 iptables 流量重新導向至側邊車。這需要使用者建立工作負載部署作業，並具備使用 NET_ADMIN 和 NET_RAW 功能部署容器的權限。為避免以提升權限執行容器的風險，網格管理員可以改為啟用 Istio CNI 外掛程式，以便將流量重新導向至 sidecar。

安全的容器映像檔

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

減輕網格安全漏洞

  • 構件分析可掃描 GKE 工作負載並顯示安全漏洞。
  • 常見安全漏洞與弱點 (CVE) 處理方式。在容器映像檔中發現安全漏洞後，網格管理員可以盡快修正安全漏洞。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 或惡意操作的攻擊。如果資料是透過網路傳輸，以便向服務進行驗證，也可能遭到網路攻擊。