服務安全性

本文將概略說明 Cloud Service Mesh 的服務安全性。適用於想在部署作業中加入驗證、加密和授權機制的 Cloud Service Mesh 使用者。本文假設您已熟悉 Cloud Service Mesh 總覽，以及無 Proxy gRPC 應用程式。

Cloud Service Mesh 可讓您保護網格中服務之間的通訊。在網格中，每項服務都有身分。下列功能有助於支援安全通訊：

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

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

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

服務網格設計模式會將與服務間通訊相關的任何複雜性，從商業邏輯中分離出來。而是由資料平面處理這項複雜作業。除了降低應用程式複雜度，服務網格設計模式還能啟用安全性模式，否則這些模式可能難以實作及管理。

在這個模型中，無 Proxy gRPC 或 Envoy Sidecar 會從 Cloud Service Mesh 取得設定資訊，並從 CA 服務集區取得憑證，安全地驗證及加密通訊。

這些安全防護功能提供下列項目，可簡化 Cloud Service Mesh 部署程序：

  • 自動為網格中的所有服務佈建金鑰和憑證。
  • 自動輪替金鑰和憑證，進一步提升安全性。
  • 與 Google Kubernetes Engine (GKE) 整合，使用所有功能，例如部署描述元和標籤。
  • Google 代管服務的高可用性，包括 Cloud Service Mesh 和 CA Service 代管的私人憑證授權單位集區。
  • 與 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 通訊協定呼叫另一項服務時，透過網路傳輸的流量會以純文字形式傳送。這類流量可能會遭受中間人攻擊，攻擊者會攔截流量並檢查或操控內容。

如要減輕這項潛在問題，您可以透過 Cloud Service Mesh 使用 HTTP、HTTP/2 或 gRPC over TLS。透過 TLS 使用這些通訊協定時，系統會根據伺服器的憑證，使用 TLS 加密用戶端與伺服器之間的流量。流量不再以純文字形式傳輸，因此攻擊者攔截、檢查或操縱流量內容的可能性降低。

使用 TLS 進行驗證

當某項服務呼叫另一項服務時，請考量下列問題：

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

  • 如果攻擊者攔截該流量，會發生什麼情況？舉例來說，HTTP 流量不會經過加密，因此任何收到流量的人都能檢查內容。這就是所謂的中間人攻擊。

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

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

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

在一般的 HTTP over TLS 交換中 (並非以雙向驗證為基礎)，伺服器會使用憑證加密用戶端與伺服器之間的通訊。用戶端可以檢查伺服器在 TLS 握手期間傳回的簽章，驗證伺服器身分。但伺服器不會驗證用戶端的身分。

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

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

授權服務呼叫

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

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

使用授權限制存取權

在服務網格中，最佳做法是遵守最低權限原則。如要遵守這項原則，請只允許依賴服務的呼叫端存取服務。如果呼叫者嘗試存取未獲授權的服務，系統會拒絕該要求。

透過 Cloud Service Mesh，您可以設定授權政策，讓資料層根據您定義的規則，允許或拒絕服務存取權。這些政策包含兩項要素：

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

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

  • 使用 mTLS 時，呼叫服務的 Kubernetes 服務帳戶
  • 呼叫服務的 IP 位址 (或位址範圍)
  • 目的地服務的通訊埠
  • 要求的 HTTP 屬性，包括主機名稱、方法和使用者定義的 HTTP 標頭。
因此系統會錯誤地允許要求，後端也會處理要求。

安全命名

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

在閘道保護流量

如要設定閘道，可以使用 Cloud Service Mesh。閘道是獨立的 Envoy 代理程式，通常會做為下列其中一項：

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

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

安全性元件

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

加密和支援的驗證模式

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

您可以設定下列安全等級：

  • 未加密/未驗證
  • TLS
  • 雙向傳輸層安全標準 (TLS)
  • 寬容模式：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 時，您必須提供機制，讓用戶端在 TLS 交換期間，使用 serverValidationCa API 欄位驗證從伺服器收到的憑證。用戶端會使用這項資訊取得驗證憑證，以便驗證伺服器憑證。

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

在這個版本中，Cloud Service Mesh 支援代管的憑證授權單位「憑證授權單位服務」。設定方式很簡單：設定憑證提供者時，請指定 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 配額

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

後續步驟