Cloud Service Mesh 安全性最佳做法

您可以對 GKE 上的 Cloud Service Mesh 套用安全控管機制,保護應用程式免受威脅,並控管環境。除了基準安裝設定外,這些做法還能將網格與更廣泛的 Google Cloud 安全防護功能整合,強化工作負載保護,並滿足法規遵循要求。

本文適用於管理網格政策的管理員,以及在網格中執行服務的使用者。請注意,本指南僅適用於使用 Istio API 的 Cloud Service Mesh 設定,不適用於Google Cloud API。

本文件架構如下:

簡介

Cloud Service Mesh 提供多項功能和工具,可協助您以統合的方式觀測、管理及保護服務。這項服務採用以應用程式為中心的方法,並使用可信任的應用程式身分,而非以網路 IP 為中心的方法。您可以透明地部署服務網格,不必修改現有的應用程式程式碼。Cloud Service Mesh 可讓您以宣告式做法控管網路行為,將負責提供及發布應用程式功能的團隊工作,與負責安全性和網路的管理員職責區隔開來。

Cloud Service Mesh 以開放原始碼 Istio 服務網格為基礎,可支援複雜的設定和拓撲。視組織結構而定,可能有一或多個團隊或角色負責安裝及設定網格。Cloud Service Mesh 預設設定旨在保護應用程式,但在某些情況下,您可能需要自訂設定,或排除特定應用程式、通訊埠或 IP 位址,不讓其加入網格,藉此授予例外狀況。因此,必須建立控管機制,管理網格設定和安全性例外狀況。

攻擊向量和安全風險

攻擊向量

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 憑證。
    • Cloud Armor 可防範外部分散式阻斷攻擊 (DDoS) 和第 7 層攻擊。可做為網頁應用程式防火牆 (WAF),保護網格免受網路攻擊。例如插入和遠端程式碼執行攻擊。
    • 虛擬私有雲和 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 服務。
    • Kubernetes CNI (容器網路介面) 可避免權限提升攻擊,因為不需要具備特殊權限的 Cloud Service Mesh init 容器。
  • 操作人員安全
    • Kubernetes 角色式存取控管 (RBAC) 會限制 Kubernetes 資源的存取權,並限制操作員權限,以減輕來自惡意操作員或操作員模擬的攻擊。
    • GKE Enterprise Policy Controller 會驗證及稽核網格中的政策設定,避免設定錯誤。
    • Google Cloud 二進位授權可確保網格中的工作負載映像檔,是由管理員授權。
    • Google Cloud 稽核記錄會稽核網格作業。

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

安全性圖表流量

叢集安全性

啟用嚴格的 mTLS

中間人 (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 安全性政策 (例如驗證和授權政策)。在某些情況下,使用者可能有正當理由,需要略過 Cloud Service Mesh 安全性政策,才能存取特定通訊埠和 IP 範圍。例如,與非 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 Key Set (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 位址和通訊埠的網路存取權。

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

為防範權杖重送攻擊 (竊取權杖並重複使用,藉此存取網格服務),應在網格邊緣將來自網格外部的要求中的權杖,換成短效的網格內部權杖。

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

後續步驟