服務安全性用途

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

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

為網格中的服務啟用 mTLS

在服務網格中，您可以啟用雙向傳輸層安全標準 (mTLS)，讓通訊中的用戶端和伺服器都必須證明自己的身分，並加密通訊。

下節將略過 Mesh、Gateway 和 Route 資源的討論。您必須使用這些 API 資源建立網格和路由流量，但無須更新這些資源即可啟用 mTLS。

如要實現上述模式，請設定下列 Compute Engine API 資源。此圖表使用附加 Proxy，但使用 mTLS 設定無 Proxy gRPC 應用程式時，也會使用相同的資源。

如要建立這個模型，請按照下列步驟操作：

1. 建立用戶端傳輸層安全標準 (TLS) 政策。
2. 建立伺服器 TLS 政策。
3. 更新現有全球後端服務中的 securitySettings 欄位，以參照新的用戶端 TLS 政策。

4. 建立端點政策：

   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 應用程式皆然。

下圖顯示流量流程，並列出您設定用於啟用 mTLS 的 Compute Engine API 資源。與 Service B 的 GKE Pod 並列的本機 Sidecar Proxy 是通訊中的端點。

端點政策會執行以下操作：

1. 使用端點比對器選取一組端點，並視需要選取這些端點上的通訊埠。

   1. 端點比對工具可讓您指定規則，決定 Cloud Service Mesh 用戶端是否會收到設定。這些規則是根據資料層實體提供給控制層的 xDS 中繼資料而定，在本例中為 Cloud Service Mesh。

      您可以按照下列步驟為 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 用戶端。

2. 參照用戶端 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)，然後由後者將流量轉送至網格中的服務。也就是說，當外部用戶端需要存取網格中的服務時，會有兩個連線。

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

如要確保兩個連線的安全，請採取下列做法：

1. 使用外部應用程式負載平衡器，確保用戶端與負載平衡器之間的連線安全。
2. 設定負載平衡器，讓其嘗試建立與網格中服務的連線時使用 HTTPS 或 HTTP/2 通訊協定。
3. 設定 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 並向用戶端顯示憑證。

在這個模型中，您會執行下列操作：

1. 建立 serverTlsPolicy：在 serverTlsPolicy 資源上設定 serverCertificate。
2. 建立端點政策：
   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。

從安全性角度來看，您可以將入口網關設為終止 TLS，然後視需要在網格中設定連線，以便由 mTLS 提供保護。包括入口網關與內部中介服務之間的連線，以及內部中介服務之間的連線。

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

1. 設定服務網格，並啟用 mTLS，以便在網格內進行通訊 (如前所述)。
2. 設定負載平衡器，將流量轉送至入口網關，並使用 HTTPS 通訊協定 (如前所述) 啟動連線。
3. 建立一組代表入口網關及其伺服器 TLS 政策的 Compute Engine API 資源。

第三步驟：設定 Cloud Service Mesh 終止 HTTPS 並呈現憑證，如下所示：

1. 建立 Mesh 資源來代表網格。

2. 建立指向正確全域後端服務的 Route 資源，並將 Route 資源附加至 Mesh 資源。

3. 建立伺服器 TLS 政策：設定 serverCertificate。

4. 建立 Gateway 資源，代表 Cloud Service Mesh 管理的入口閘道。

5. 將伺服器 TLS 政策資源附加至 Gateway 資源。

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

舉例來說，假設有以下情況：

• 兩個服務專案 (1 和 2)，皆已連接至相同的共用虛擬私有雲網路。

• 服務專案 1 包含由 Cloud Service Mesh 設定的服務網格。

  服務專案 1 已設定網格和入口閘道。這個入口閘道可透過 10.0.0.2 位址/VIP 存取。

• 服務專案 2 包含由 Cloud Service Mesh 設定的服務網格。

  服務專案 2 可能有或沒有專屬的輸入網關。

• 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 服務安全性」。