服務安全性

本文件概述了 Cloud Service Mesh 的服務安全性。這項功能適用於希望在部署中加入驗證、加密和授權功能的 Cloud Service Mesh 使用者。本文件假設您已熟悉 Cloud Service Mesh 總覽和無 Proxy gRPC 應用程式。

Cloud Service Mesh 可讓您保護網格中的服務對服務通訊。在網格中，每項服務都有一個身分。下列功能可協助您支援安全的通訊方式：

  • 針對使用 Envoy 的 Cloud Service Mesh 和使用無 Proxy gRPC 應用程式的 Cloud Service Mesh，採用傳輸層安全標準 (TLS) 和雙向 TLS (mTLS) 的驗證和加密機制。用戶端 TLS 政策和伺服器 TLS 政策會控制服務是否需要向彼此證明身分，以及是否使用加密通訊管道。
  • 根據用戶端和要求的特性進行授權。授權政策可控管服務是否可存取其他服務，以及允許哪些動作。

使用私人憑證授權單位 (CA) 提供的憑證和金鑰 (Google 的憑證授權單位服務)，有助於您更輕鬆地維護服務安全。CA 服務提供 GKE 網格憑證。您可以使用 GKE 網格憑證功能和 Cloud Service Mesh，自動部署這些憑證，並讓工作負載使用這些憑證。您可以修改 Pod，讓工作負載接收及使用 mTLS 憑證。Cloud Service Mesh 服務安全性目前僅適用於以 GKE 為基礎的工作負載。

在以微服務為基礎的現代架構中，較小且更專注的服務取代了大型單體式應用程式。服務呼叫會透過網路彼此通訊。這些呼叫是單體應用程式中的處理中呼叫，會帶來安全性挑戰，因此最好對這些呼叫進行驗證、加密和授權。這些步驟可支援零信任原則，在該原則中，不論流量來自網路內部或外部，都會假設所有網路流量都存在風險。

服務網格設計模式可將服務間通訊相關的複雜性與商業邏輯分開。相反地，資料平面會處理這項複雜作業。除了降低應用程式複雜度，服務網格設計模式還可支援安全性模式，否則這些模式可能難以實作及管理。

在這個模型中，無 Proxy gRPC 或 Envoy 附屬程式會從 Cloud Service Mesh 取得設定資訊，並從 CA 服務資源池取得憑證，藉此安全地驗證及加密通訊。

這些安全性功能可提供下列功能，讓您更輕鬆地部署 Cloud Service Mesh：

  • 自動為網格中的所有服務提供金鑰和憑證。
  • 自動輪替金鑰和憑證，提供額外安全性。
  • 與 Google Kubernetes Engine (GKE) 整合，以便使用其所有功能，例如部署描述和標籤。
  • Google 代管服務 (包括 Cloud Service Mesh 和 CA 服務代管的私人憑證授權單位集區) 的可用性高。
  • 與 Google Identity and Access Management (IAM) 相關的安全性：根據已授權的 Google 服務帳戶授予服務授權。
  • 與 Envoy 和無 Proxy 工作負載的完美互通性。舉例來說，服務可能位於 Envoy Proxy 後方，但用戶端使用 gRPC 無 Proxy 服務網格安全性。反之，服務可能位於 gRPC 無 Proxy 服務網格安全性後方，但用戶端使用 Envoy Proxy。

確保服務對服務的通訊安全

Cloud Service Mesh 提供授權，以及使用傳輸層安全標準 (TLS) 的加密和驗證服務對服務安全性。用戶端 TLS 政策和伺服器 TLS 政策可讓服務執行以下操作：

  • 斷言及驗證身分。
  • 使用 TLS 或 mTLS 加密通訊工作階段。

在服務網格中，資料層會處理這類安全性機制，因此應用程式不必採取特殊措施就能確保安全性。

授權政策可讓您根據自訂規則拒絕或允許存取權。

使用 TLS 進行加密

當服務使用 HTTP、HTTP/2 或 gRPC 通訊協定呼叫其他服務時，透過網路傳輸的流量會以明文傳送。這類流量可能會遭受中間人攻擊，攻擊者會攔截流量，並檢查或操縱其內容。

為降低這項潛在問題的影響，您可以使用 HTTP、HTTP/2 或透過 TLS 的 gRPC 與 Cloud Service Mesh 搭配使用。當您透過 TLS 使用這些通訊協定時，系統會使用以伺服器憑證為基礎的 TLS 加密用戶端和伺服器之間的流量。流量不再以純文字形式傳輸，因此攻擊者較難攔截、檢查或操縱內容。

使用 TLS 進行驗證

當服務呼叫其他服務時，請考量下列問題：

  • 用戶端如何知道收到的回應來自正確的伺服器，而非冒用者？舉例來說，在以 HTTP 為基礎的一般要求-回應互動中，用戶端不會驗證伺服器的身分。

  • 如果攻擊者攔截該流量，會發生什麼情況？舉例來說，HTTP 流量並未加密，因此任何接收流量的使用者都可以檢查內容。這就是所謂的「人為攔截」攻擊。

為減輕這些問題，您可以使用 TLS 的 HTTP、HTTP/2 和 gRPC。在用戶端和伺服器之間的這些交換作業中，伺服器必須使用伺服器憑證向用戶端證明自身身分。然後使用 TLS 加密要求和回應。

雙向傳輸層安全標準 (TLS) 驗證

當 Cloud Service Mesh 為用戶端和伺服器設定應用程式網路時 (例如在用戶端設定 Envoy Proxy，並在伺服器端設定另一個 Envoy Proxy)，您就能運用雙向驗證等進階驗證模式。

在非以雙向驗證為基礎的典型 HTTP 傳輸層安全標準交換中，伺服器會提供用於加密用戶端和伺服器之間通訊的憑證。用戶端可以檢查伺服器在 TLS 握手期間傳回的簽名，藉此驗證伺服器的身分。不過，伺服器不會驗證用戶端的身分。

啟用雙向驗證時，用戶端也會有憑證。如上一節所述，用戶端會驗證伺服器的身分，而伺服器也可以驗證用戶端的身分。用戶端和伺服器憑證都會用於加密通訊管道。這也讓伺服器能夠根據已驗證的用戶端身分授權用戶端。

服務網格中的相互傳輸層安全標準 (mTLS) 驗證。
服務網格中的相互傳輸層安全性 (mTLS) 驗證 (按一下即可放大)

授權服務呼叫

您可以使用授權政策選擇允許或拒絕服務存取權。您可以使用 Cloud Service Mesh 定義允許和拒絕規則，根據要求參數授權存取權。您可以根據第 3 層和第 7 層參數建立這些規則，包括用戶端 ID (這是從 mTLS 連線中的 client-cert 衍生而來)、來源 IP 位址、主機比對、方法比對和標頭比對。下圖顯示使用 Envoy 代理程式進行授權。這個程序與 gRPC 用戶端類似。

服務網格中的授權。
使用 Envoy 在服務網格中授權 (按一下可放大)

使用授權限制存取

服務中介網中的最佳做法是遵循最低權限原則。您可以遵循這項原則，將服務存取權限制為僅限於依賴該服務的呼叫端。當呼叫端嘗試存取未經授權的服務時，系統會拒絕該嘗試。

您可以使用 Cloud Service Mesh 設定授權政策，讓資料層依據您定義的規則允許或拒絕服務存取權。這些政策包含兩個元件：

  • 動作：允許或拒絕
  • 規則清單

傳送要求或 RPC 時，呼叫服務的 Cloud Service Mesh 用戶端會判斷是否有相符的規則。如果找到相符項目，系統就會允許或拒絕要求或 RPC。您可以定義規則，以便比對屬性，例如：

  • 使用 mTLS 時，呼叫服務的 Kubernetes 服務帳戶
  • 呼叫服務的 IP 位址 (或位址範圍)
  • 目的地服務的通訊埠
  • 要求的 HTTP 屬性，包括主機名稱、方法和使用者定義的 HTTP 標頭。

安全命名

您可以使用 Cloud Service Mesh 設定安全命名，做為額外的安全機制。這可讓您為用戶端嘗試連線的特定服務，定義一組允許的名稱清單或 SPIFFE (Secure Production Identity Framework for Everyone) 身分。在 TLS 交換期間，服務的後端會將 X.509 憑證傳回給用戶端。接著，用戶端會檢查憑證，確認 X.509 憑證與其中一個名稱或 SPIFFE 身分相符。如要進一步瞭解 SPIFFE 身分，請參閱「適用於所有人的安全正式版身分架構」。

在閘道中保護流量

如要設定閘道，您可以使用 Cloud Service Mesh。閘道是獨立的 Envoy 代理程式，通常會扮演下列任一角色：

  • 輸入閘道：處理進入網格或其他網域的流量
  • 輸出閘道：處理離開網格或其他網域的流量
  • 反向 Proxy 或中介 Proxy，可將傳入流量分配至一或多項服務

如要將流量傳送至中繼或從中繼傳送流量的用戶端，會將流量傳送至中繼。接著，閘道會根據您透過 Cloud Service Mesh 設定的規則處理要求。舉例來說，您可以強制要求進入網格的流量 (透過入口閘道) 必須使用 TLS 加密。

安全性元件

Cloud Service Mesh 服務安全性支援用戶端 TLS 政策、伺服器 TLS 政策和授權政策。您建立這些政策，讓 Cloud Service Mesh 能夠設定資料層並啟用安全性功能。如要建立或更新這些政策，您不需要變更應用程式。

加密和支援的驗證模式

當服務呼叫其他服務時，建立安全通訊的第一步驟就是讓每項服務向其他服務證明自己的身分。服務需要證明自身身分的程度取決於您設定的 TLS 模式。

您可以設定下列安全性層級：

  • 未加密/未經驗證
  • TLS
  • 相互傳輸層安全標準 (mTLS)
  • 寬容模式：mTLS 或未加密/未驗證，視用戶端啟動連線的方式而定

憑證和憑證授權單位

憑證和信任的憑證授權單位 (CA) 為服務網格等分散式系統提供信任基礎。使用憑證時，服務可以透過下列方式證明自身身分，並驗證向其提供的身分：

  • 如要向其他服務證明自身身分，服務會將憑證提交給其他服務。兩項服務都信任的 CA 會進行加密編譯簽署並核發此憑證。
  • 接收此憑證的服務可以驗證憑證是否來自其信任的 CA。

Cloud Service Mesh 不是憑證授權單位。如要啟用安全通訊功能，您必須設定可執行下列操作的機制：

  • 佈建身分和憑證
  • 讓 Cloud Service Mesh 設定的 Cloud Service Mesh 用戶端 (例如 Envoy 代理程式) 可使用憑證

Cloud Service Mesh 支援 Google 的 CA 服務。Envoy 和無 Proxy gRPC 的設定指南包含相關設定說明 (詳情請參閱「後續步驟」)。

架構與資源

Cloud Service Mesh 包含 Network Security API 命名空間，其中包含三個 Google Cloud API 資源，可讓您指定應套用至資料層的安全性政策。

兩個 Google Cloud API 資源可支援網格中的驗證：用戶端 TLS 政策和伺服器 TLS 政策。第三個資源 (授權政策) 則支援授權。

Network Services API 命名空間包含端點政策資源，可讓 Cloud Service Mesh 為端點提供設定 (伺服器 TLS、用戶端 TLS 和授權政策)。端點是 Cloud Service Mesh 用戶端，可終止來自其他 Cloud Service Mesh 用戶端的傳入通訊。

用戶端 TLS 政策

您可以使用用戶端 TLS 政策指定用戶端 TLS 模式，以及要套用至資料層的憑證提供者資訊。用戶端 TLS 政策支援 TLS 和 mTLS 驗證。用戶端 TLS 政策必須附加至全域後端服務資源。

設定 TLS 時，您必須提供一種機制，讓用戶端使用 serverValidationCa API 欄位，驗證在 TLS 交換期間從伺服器收到的憑證。用戶端會使用這些資訊取得驗證憑證，以便驗證伺服器憑證。

設定 mTLS 時，您也必須提供一種機制，讓用戶端使用 clientCertificate API 欄位取得憑證和私密金鑰。用戶端會在 TLS 握手期間使用這項資訊，向伺服器提供憑證。

在這個版本中，Cloud Service Mesh 支援代管的憑證授權單位 CA 服務。設定方式很簡單：設定憑證提供者時，請指定 google_cloud_private_spiffe 外掛程式名稱。這會導致 xDS 用戶端從靜態位置載入憑證和金鑰。您必須先設定 CA 服務集區，並在 GKE 叢集上啟用網格憑證。

伺服器 TLS 政策

伺服器 TLS 政策 (ServerTlsPolicy 資源) 可讓您指定伺服器端 TLS 模式，以及要套用至資料層的憑證提供者資訊。伺服器 TLS 政策支援 TLS、mTLS，以及僅在 Envoy 中支援的 Open_or_mTLS 驗證。您將伺服器 TLS 政策附加至端點政策資源。

主體替代名稱

設定全球後端服務的 securitySettings 欄位時，您可以在 subjectAltNames 欄位中提供主體替代名稱清單。當用戶端與服務的其中一個後端啟動 TLS 握手時，伺服器會提供 X.509 憑證。用戶端會檢查憑證的 subjectAltName 欄位。如果欄位包含其中一個指定值，通訊就會繼續。這個機制在前文的安全命名一節中已加以說明。

授權政策

授權政策 (AuthorizationPolicy 資源) 會指定伺服器授權傳入要求或 RPC 的方式。可根據各種參數 (例如傳送要求的用戶端身分、主機、標頭和其他 HTTP 屬性) 設定，允許或拒絕傳入的要求或 RPC。您可以將授權政策附加至端點政策資源。

授權政策規則包含下列元件：

  • from：指定規則允許的用戶端身分。身分可從雙向 TLS 連線中的用戶端憑證衍生，也可以是與用戶端 VM 相關聯的環境身分，例如來自服務帳戶或安全性標記。
  • to：指定規則允許的作業，例如可存取的網址或允許的 HTTP 方法。
  • when：可讓您定義必須符合的其他限制。您可以使用一般運算語言 (CEL) 運算式定義限制。
  • action：指定規則的動作。可以是 ALLOW、DENY 或 CUSTOM 其中一個。

限制

只有 GKE 支援 Cloud Service Mesh 服務安全性。您無法使用 Compute Engine 部署服務安全性。

評估要求時，授權政策會採取下列任一動作：

  • ALLOW：如果要求符合授權政策中定義的規則，則會授予要求的資源存取權。如果要求不符合授權政策中定義的任何規則，授權政策就會封鎖對要求資源的存取權。如果要求不符合 ALLOW 政策，即使其他政策允許，系統也會拒絕要求。

  • DENY：如果要求符合 DENY 政策中指定的任何規則，就會封鎖資源存取權。如果要求不符合授權政策中定義的任何規則，授權政策就會授予要求的資源存取權。如果要求符合 DENY 政策，即使其他政策允許，系統也會拒絕這項要求。

  • CUSTOM (Cloud Service Mesh 不支援)：可與外部授權系統整合，以便做出複雜的授權決策。CUSTOM 動作適用於使用服務擴充功能進行授權決策的政策。

授權政策評估順序

當多項授權政策與單一資源相關聯時，系統會依下列順序評估這些政策，以決定是否允許或拒絕要求。

  1. 含有 CUSTOM 動作的政策：如果 CUSTOM 政策拒絕要求，要求會立即遭到拒絕。即使已設定 DENY 或 ALLOW 政策，系統也不會評估這些政策。

  2. 含有 DENY 動作的政策：如果有任何 DENY 政策與要求相符，系統就會拒絕要求。即使已設定 ALLOW 政策，系統也不會評估任何政策。

  3. 含有 ALLOW 動作的政策：如果沒有 ALLOW 政策，或是任何 ALLOW 政策都與要求相符，系統會允許要求。不過，如果沒有任何 ALLOW 政策符合要求，系統會拒絕要求。

無 Proxy gRPC 應用程式的限制

無 Proxy gRPC 服務的服務安全性有以下限制：

  • 此版本僅適用於 Java、Python、C++ 和 Go。

AuthzPolicy 配額

  • 每個 Gateway 最多只能有 5 項授權政策。
  • 每個專案最多只能有 20 個 AuthzPolicy 資源。
  • 單一 AuthzPolicy 最多可指向 100 個 Gateway。

後續步驟