Cloud Service Mesh 與 Istio API 安全性最佳做法

本文說明如何建立及控管在 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 安全性最佳做法文件的補充內容,其中包含雙向 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 提供多層安全防護,包括:

  • 網格邊緣安全性
    • 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 加密及驗證,且不允許純文字流量。

Cloud Service Mesh 可讓您設定工作負載間 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 驗證政策

考量 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 位址和連接埠的網路存取權。

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

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

如要從網格外部存取網格服務,要求必須包含權杖 (例如 JWT 或 Cookie),才能通過網格服務的驗證和授權。網狀網路外部的權杖可能存留時間較長。如要防範權杖重送攻擊,請在網格的進入點,將網格外部的權杖換成存留時間短暫的網格內部權杖,並限制權杖範圍。網格服務會驗證網格內部權杖,並根據網格內部權杖授權存取要求。

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

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

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

您可能基於正當理由,需要對某些通訊埠和 IP 範圍略過 Cloud Service Mesh 安全性政策。您可以將註解 (例如 excludeInboundPortsexcludeOutboundPortsexcludeOutboundIPRanges) 新增至 Pod,排除 Envoy Sidecar 處理的流量。除了使用註解排除流量,您也可以部署停用 Sidecar 插入的應用程式,完全略過網格。舉例來說,只要在應用程式 Pod 中加入 sidecar.istio.io/inject="false" 標籤即可。

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

如果系統略過 Cloud Service Mesh 安全性政策,允許特定通訊埠或 IP 位址 (無論是刻意或無意),我們強烈建議您採取其他安全措施,確保網格安全無虞,並監控安全例外狀況、潛在安全漏洞和整體安全強制執行狀態。如要在這類情況下保護網狀網路安全,可以採取下列做法:

  • 請確保繞過 Sidecar 的流量已原生加密及驗證,以防範中間人攻擊。
  • 強制執行 Kubernetes 網路政策,限制通訊埠的連線能力 (但政策例外狀況除外)。舉例來說,您可以限制通訊埠 (但政策例外狀況除外),只允許來自相同命名空間中其他服務的流量,或只允許流量通過已強制執行 Cloud Service Mesh 安全性政策的通訊埠。

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

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

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

建議網狀網路管理員監控下列事項:

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

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

工作負載安全性

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

限制 Pod 權限

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

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

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

保護容器映像檔

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

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

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