Cloud Service Mesh 和 Traffic Director 現已改名為 Cloud Service Mesh。詳情請參閱 Cloud Service Mesh 總覽。

本頁面由 Cloud Translation API 翻譯而成。

服務安全用途

本文說明常見的 Cloud Service Mesh 安全性用途。您可以根據這些資訊，判斷哪種安全模式最符合需求。本文也概略說明各項用途的設定需求。

如要瞭解服務安全性的總覽，請參閱「Cloud Service Mesh 服務安全性」。

為網格中的服務啟用雙向 TLS

在服務網格中，您可以啟用雙向 TLS (mTLS)，讓通訊中的用戶端和伺服器都必須證明自己的身分，並加密通訊內容。

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

下節將省略 Mesh、Gateway 和 Route 資源的討論。建立網格和傳輸流量時，必須使用這些 API 資源，但您不需要更新這些資源即可啟用 mTLS。

如要達成上述模式，請設定下列 Compute Engine API 資源。這張圖使用 Sidecar Proxy，但設定採用 mTLS 的無 Proxy gRPC 應用程式時，會使用相同的資源。

網格內 mTLS 的 Compute Engine API 資源。 — 網格內 mTLS 的 Compute Engine API 資源 (按一下可放大)

如要建立這個模型，請執行下列操作：

建立用戶端傳輸層安全標準 (TLS) 政策。
建立伺服器 TLS 政策。
更新現有全域後端服務中的 securitySettings 欄位，以參照新的用戶端 TLS 政策。
建立端點政策：
1. 在 server_tls_policy 欄位中參照伺服器 TLS 政策。
2. 定義 EndpointMatcher，選取應對輸入流量強制執行驗證的 Cloud Service Mesh 用戶端。
  
  選取 Cloud Service Mesh 用戶端時，系統會根據 Cloud Service Mesh 用戶端啟動程序設定中指定的標籤。這些標籤可手動提供，或根據提供給 Google Kubernetes Engine (GKE) 部署項目的標籤自動填入。
  
  在上圖中，標籤 "mesh-service":"true" 是在端點政策和 Cloud Service Mesh 用戶端上設定。您可以選擇適合部署作業的標籤。
3. (選用) 定義 TrafficPortSelector，僅在對資料平面實體上的指定連接埠提出連入要求時套用政策。

下圖顯示您為 mTLS 設定的 Compute Engine 資源，無論您使用 Envoy 或無 Proxy 的 gRPC 應用程式都一樣。

下圖顯示流量，並列出您設定的 Compute Engine API 資源，以啟用 mTLS。與服務 B 的 GKE Pod 並存的本機補充 Proxy，就是通訊中的端點。

網格內 mTLS 的 Compute Engine API 資源和流量。 — 網格內 mTLS 的 Compute Engine API 資源和流量流程 (按一下即可放大)

端點政策會執行下列作業：

使用端點比對器選取一組端點，並視需要選取這些端點上的通訊埠。
1. 端點比對器可讓您指定規則，判斷 Cloud Service Mesh 用戶端是否會收到設定。這些規則是以資料層實體提供給控制層 (在本例中為 Cloud Service Mesh) 的 xDS 中繼資料為依據。
  
  您可以按照下列步驟，為 Cloud Service Mesh 用戶端新增標籤：
  - 您可以在 Cloud Service Mesh 用戶端的啟動程序檔案中手動指定這項中繼資料。
  - 或者，使用 GKE 時，只要將鍵/值組合新增至 demo_server.yaml 或 demo_client.yaml 檔案的 env 區段，系統就會自動填入中繼資料。這些值會提供在 Envoy 設定指南和無 Proxy 的 gRPC 設定指南中。
    
    舉例來說，如果只使用 Envoy，您可以在金鑰前面加上 ISTIO_META_ 前置字元。以 ISTIO_META_ 開頭的 Proxy 環境變數名稱會納入產生的啟動程序，並傳送至 xDS 伺服器。
```
- name: ISTIO_META_app
  value: 'review'
- name: ISTIO_META_version
  value: 'canary'
```
2. 如果您指定通訊埠，系統只會對指定相同通訊埠的連入要求，強制執行端點政策中參照的政策。如果未指定通訊埠，系統會對指定通訊埠的連入要求強制執行政策，而該通訊埠也位於 TRAFFICDIRECTOR_INBOUND_BACKEND_PORTS 欄位中，該欄位會提供給 Cloud Service Mesh 用戶端，做為啟動資訊。
參考用戶端 TLS、伺服器 TLS 和授權政策，設定要求解析的端點。

設定不相容的 TLS 模式可能會導致通訊中斷。舉例來說，如果在全域後端服務中設定 OPEN，或將用戶端 TLS 政策欄位留空，並在端點政策中將 MTLS 設為伺服器 TLS 政策的值，就會導致通訊嘗試失敗。這是因為設定為僅接受 mTLS 的端點會拒絕建立未經驗證通訊管道的嘗試。

請注意，用戶端 TLS 政策和伺服器 TLS 政策分別附加至全域後端服務和端點政策，兩者之間有所區別：

用戶端 TLS 政策會套用至全域後端服務。這會告知 Envoy Proxy 或無 Proxy 用戶端，在處理服務時要使用哪種 TLS 模式、身分和對等驗證方法。
伺服器 TLS 政策會附加至端點政策。這個物件會告知伺服器，要對連入連線使用哪種 TLS 模式、身分和對等驗證方法。

為輸入閘道啟用 TLS

為網格內通訊設定 mTLS 後，您可能想保護進入網格的流量，也就是輸入流量。Cloud Service Mesh 可設定資料層，要求傳入流量使用 TLS 加密通訊管道。

如要達成這個目標，請選擇下列其中一個架構選項：

網格中的服務會終止來自負載平衡器的流量 TLS。在這個模型中，網格中的每個服務都會在負載平衡器的設定中 (具體來說，是在負載平衡器的網址對應中) 設為後端。
在將流量轉送至網格中的服務之前，連入閘道會終止來自負載平衡器的流量 TLS。在這個模型中，網格中的專屬服務 (即進入閘道) 會在負載平衡器的設定中 (具體來說，是在負載平衡器的網址對應中) 設為後端。

本節將說明這兩種做法。

網格中的服務會終止負載平衡器傳送的流量 TLS

如要讓Google Cloud外部的用戶端存取服務，您可以使用外部應用程式負載平衡器。用戶端會將流量傳送至負載平衡器的全域 Anycast 虛擬 IP 位址 (VIP)，然後負載平衡器會將流量轉送至網格中的服務。也就是說，外部用戶端需要連線至網格中的服務時，會有兩個連線。

使用內部應用程式負載平衡器時，也適用相同模式。內部用戶端的流量會先抵達負載平衡器，然後建立與後端的連線。

如要保護這兩種連線，請採取下列做法：

使用外部應用程式負載平衡器，確保用戶端與負載平衡器之間的連線安全。
設定負載平衡器，在嘗試與網格中的服務建立連線時，使用 HTTPS 或 HTTP/2 通訊協定。
設定 Cloud Service Mesh，讓 Cloud Service Mesh 用戶端終止 HTTPS 並向用戶端 (在本例中為負載平衡器) 提供憑證。

如要進一步瞭解步驟 1 和 2，請參閱設定以內容為基礎的多區域外部 HTTPS 負載平衡器。

設定 Cloud Service Mesh 安全性時，您會設定各種 Compute Engine API 資源。這些資源與您為負載平衡器設定的資源不同。您要為負載平衡器建立一組 Compute Engine API 資源 (通用轉送規則、目標 Proxy、網址對應和通用後端服務)，並使用服務轉送 API 設定 Cloud Service Mesh。此外，在後端服務資源中，負載平衡器具有負載平衡架構 INTERNAL_MANAGED，Cloud Service Mesh 則具有負載平衡架構 INTERNAL_SELF_MANAGED。

在步驟 3 中，您會設定 Cloud Service Mesh，讓 Cloud Service Mesh 用戶端終止 HTTPS 並向用戶端出示憑證。

服務網格中服務的 TLS 適用的 Compute Engine API 資源。 — Compute Engine API 資源，用於網格中服務的 TLS (按一下可放大)

在本模型中，您將執行下列操作：

建立 serverTlsPolicy：在 serverTlsPolicy 資源上設定 serverCertificate。
建立端點政策：
1. 在 authentication 欄位中參照伺服器 TLS 政策。
2. 定義 EndpointMatcher，選取應對傳入流量強制執行驗證的 xDS 資料平面實體。
3. 您可以選擇定義 TrafficPortSelector，僅在對 Cloud Service Mesh 用戶端上的指定通訊埠提出連入要求時套用政策。

由於外部應用程式負載平衡器已設定為啟動與網格中服務的 TLS 連線，因此 Cloud Service Mesh 只需要設定 Cloud Service Mesh 用戶端來終止 TLS 連線。

Ingress 閘道會終止來自負載平衡器的流量 TLS，然後將流量轉送至網格中的服務

如果只想將輸入閘道公開給負載平衡器，可以使用輸入閘道部署模式。在這個模式中，負載平衡器不會直接處理網格中的服務。而是位於網格邊緣的中間 Proxy，並根據從 Cloud Service Mesh 收到的設定，將流量轉送至網格內的服務。中間 Proxy 可以是您部署在 Compute Engine 代管執行個體群組中虛擬機器 (VM) 執行個體的 Envoy Proxy。

透過網格內的 mTLS，將 TLS 傳送至 Ingress 閘道。 — 網格內使用 mTLS 的 Ingress 閘道 TLS (按一下可放大)

從安全性的角度來看，您可以設定 Ingress 閘道來終止 TLS，然後視需要設定網格內的連線，確保連線受到 mTLS 保護。包括 Ingress 閘道與網格內服務之間的連線，以及網格內服務之間的連線。

從設定角度來看，您需要執行下列操作：

設定服務網格，並為網格內的通訊啟用 mTLS (如前所述)。
設定負載平衡器，將流量轉送至 Ingress 閘道，並使用 HTTPS 通訊協定啟動連線 (如先前所述)。
建立一組 Compute Engine API 資源，代表 Ingress 閘道及其伺服器 TLS 政策。

在第三個步驟中，請設定 Cloud Service Mesh 終止 HTTPS 並提供憑證，如下所示：

建立 Mesh 資源來代表網格。
建立指向正確全域後端服務的 Route 資源，並將 Route 資源附加至 Mesh 資源。
建立伺服器 TLS 政策：設定 serverCertificate。
建立 Gateway 資源，代表 Cloud Service Mesh 管理的 Ingress 閘道。
將伺服器 TLS 政策資源附加至 Gateway 資源。

對於使用共用虛擬私有雲的大型機構而言，這項模式特別實用。在這種情況下，團隊可能只允許透過 Ingress 閘道存取服務。在上圖中，設定負載平衡器的全域轉送規則時，您提供的 IP 位址 (本例為 10.0.0.2) 與設定網格時提供的 IP 位址不同 (本例中，網格位址為 10.0.0.1)。透過 Cloud Service Mesh 設定的 xDS 資料層實體通訊的用戶端，可以使用這個位址存取 Ingress 閘道。

舉例來說，假設：

兩個服務專案 (1 和 2)，都附加至同一個共用虛擬私有雲網路。
服務專案 1 包含由 Cloud Service Mesh 設定的服務網格。

服務專案 1 已設定網格和 Ingress 閘道。這個 Ingress 閘道可透過 10.0.0.2 位址/VIP 存取。
服務專案 2 包含由 Cloud Service Mesh 設定的服務網格。

服務專案 2 可能有自己的 Ingress 閘道，也可能沒有。
Cloud Service Mesh 會在每個服務專案中設定 Cloud Service Mesh 用戶端。用戶端會啟動，使用相同的網路。

有了這項設定，服務專案 2 網格中的用戶端就能使用 10.0.0.2 VIP，與服務專案 1 中的 Ingress 閘道通訊。這樣一來，服務專案 1 的擁有者就能設定專屬於進入網格流量的路由、安全性和其他政策。實際上，服務專案 1 的擁有者可以告訴其他人「網格中的用戶端可以透過 10.0.0.2存取我的服務」。

限制

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

後續步驟

如要使用 Envoy Proxy 設定 Cloud Service Mesh 服務安全防護，請參閱使用 Envoy 設定 Cloud Service Mesh 服務安全防護。

如要使用無 Proxy gRPC 應用程式設定 Cloud Service Mesh 服務安全防護，請參閱「使用無 Proxy gRPC 設定 Cloud Service Mesh 服務安全防護」。