Anthos Service Mesh 和 Traffic Director 现已更名为 Cloud Service Mesh。如需了解详情，请参阅 Cloud Service Mesh 概览。

此页面由 Cloud Translation API 翻译。

服务安全使用场景（旧版）

本文档介绍了 Cloud Service Mesh 的常见安全用例。这些信息可以帮助您确定哪种安全模型最符合您的需求。本文档还简要介绍在每种使用场景中需要进行的配置。

如需简要了解服务安全性，请参阅 Cloud Service Mesh 服务安全。

本文档适用于使用负载均衡 API 的配置。这是旧版文档。

为网格中的服务启用双向 TLS

在服务网格中，您可以启用双向 TLS (mTLS)，从而使通信中的客户端和服务器必须证明其身份并加密通信。

服务网格中的双向 TLS (mTLS) 身份验证。 — 服务网格中的双向 TLS (mTLS) 身份验证（点击可放大）

以下部分省略了对全局转发规则、目标 HTTPS 代理和网址映射的讨论。创建网格时需要这些 Compute Engine API 资源，但启用 mTLS 不需要更新这些资源。

可以通过配置以下 Compute Engine API 资源实现上述模式。此图使用 Sidecar 代理，但使用 mTLS 配置无代理 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 还是无代理 gRPC 应用。

下图展示了流量并列出了为启用 mTLS 而配置的 Compute Engine API 资源。服务 B 的 GKE pod 旁边的本地 Sidecar 代理是通信中的端点。

mTLS 中网格内 mTLS 的 Compute Engine API 资源和流量。 — 网格中 mTLS 的 Compute Engine API 资源和流量（点击可放大）

端点政策执行以下操作：

使用端点匹配器选择一组端点以及（可选）这些端点上的端口。
1. 通过端点匹配器，您可以指定用于确定 Cloud Service Mesh 客户端是否接收配置的规则。这些规则基于数据平面实体向控制层面提供的 xDS 元数据（本例中为 Cloud Service Mesh）。
  
  您可以向 Cloud Service Mesh 客户端添加标签，如下所示：
  - 您可以在 Cloud Service Mesh 客户端的引导文件中手动指定此元数据。
  - 或者，在使用 GKE 时，可以通过将键值对添加到 demo_server.yaml 或 demo_client.yaml 文件的 env 部分自动填充该元数据。Envoy 设置指南和无代理 gRPC 设置指南中提供了这些值。
    
    例如，如果只使用 Envoy，您可以在键前面添加 ISTIO_META_ 前缀。以 ISTIO_META_ 开头的代理环境变量名称会包含在生成的引导文件中，并发送到 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 代理或无代理客户端在对服务进行寻址时使用的 TLS 模式、身份和对等方验证方法。
服务器 TLS 政策附加到端点政策，它告知服务器用于传入连接的 TLS 模式、身份和对等方验证方法。

为入站网关启用 TLS

为网格内通信设置 mTLS 后，您可能需要保护进入网格的流量（称为入站流量）。Cloud Service Mesh 可以将数据平面配置为要求入站流量使用 TLS 加密的通信通道。

为了实现此目标，请选择以下架构选项之一：

网格中的服务针对来自负载均衡器的流量终止 TLS。在此模型中，网格中的每个服务都在负载均衡器配置中配置为后端；具体而言，是在负载均衡器的网址映射中。
入站网关针对来自负载均衡器的流量终止 TLS，然后再将流量转发到网格中的服务。在此模型中，网格中的专用服务入站网关在负载均衡器配置中配置为后端；具体而言，是在负载均衡器的网址映射中。

本部分将介绍这两个选项。

网格中的服务针对来自负载均衡器的流量终止 TLS

如果您希望 Google Cloud 外部的客户端能够使用您的服务，则可以使用外部应用负载均衡器。客户端将流量发送到负载均衡器的全局任播虚拟 IP 地址 (VIP)，然后将该流量转发到网格中的服务。这意味着，当外部客户端需要访问网格中的服务时，会有两个连接。

通过 TLS 访问网格中的服务。 — 通过 TLS 访问网格中的服务（点击可放大）

使用内部应用负载均衡器时遵循相同的模式。来自内部客户端的流量先到达负载均衡器，然后负载均衡器再与后端建立连接。

要保护两个连接，请执行以下操作：

使用外部应用负载均衡器保护客户端与负载均衡器之间的连接。
将负载均衡器配置为在尝试与网格中的服务建立连接时使用 HTTPS 或 HTTP/2 协议。
配置 Cloud Service Mesh，使 Cloud Service Mesh 客户端终止 HTTPS 并向客户端（在此例中为负载均衡器）提供证书。

如需详细了解第 1 步和第 2 步，请参阅设置基于内容的多区域外部 HTTPS 负载均衡器。

设置 Cloud Service Mesh 安全时，您需要配置各种 Compute Engine API 资源。这些资源独立于您为负载均衡器配置的资源。换句话说，您使用不同的负载平衡方案创建两组 Compute Engine API 资源（全局转发规则、目标代理、网址映射和全局后端服务）：

一组资源配置负载均衡器，其负载平衡方案为 INTERNAL_MANAGED。
另一组资源配置 Cloud Service Mesh，其负载平衡方案为 INTERNAL_SELF_MANAGED。

在第 3 步中，您将配置 Cloud Service Mesh，使得 Cloud Service Mesh 客户端终止 HTTPS 并向客户端提供证书。

通过 TLS 访问网格中服务所需的 Compute Engine API 资源（点击可放大）

在此模型中，您将执行以下操作：

创建服务器 TLS 政策：在 transportAuthentication 上配置 terminationTls。
创建端点政策。
1. 在 authentication 字段中引用服务器 TLS 政策。
2. 定义 EndpointMatcher 以选择应对入站流量强制执行身份验证的 xDS 数据层面实体。
3. （可选）定义一个 TrafficPortSelector，它仅在入站请求发送到 Cloud Service Mesh 客户端上的指定端口时应用政策。

由于外部应用负载平衡器已配置为启动与网格中服务的 TLS 连接，因此 Cloud Service Mesh 只需要将 Cloud Service Mesh 客户端配置为终止 TLS 连接。

入站网关针对来自负载均衡器的流量终止 TLS，然后再将流量转发到网格中的服务

如果您只想向负载平衡器公开入站网关，可以使用入站网关部署模式。在此模式中，负载均衡器不会直接寻址网格中的服务。相反，中间代理位于网格的边缘，并根据其从 Cloud Service Mesh 收到的配置将流量路由到网格内的服务。中间代理可以是您在 Compute Engine 代管式实例组中的虚拟机实例中部署的 Envoy 代理。

TLS 到网格内具有 mTLS 的入站流量网关。 — 通过 TLS 访问入站网关并在网格内使用 mTLS（点击可放大）

从安全角度来看，您可以将入站流量网关配置为终止 TLS，然后选择性地配置网格中的连接，使其受 mTLS 保护。包括入站流量网关和网格服务之间的连接，以及网格服务之间的连接。

从配置的角度，您需要执行以下操作：

配置服务网格并为网格内的通信启用 mTLS（如前所述）
配置负载均衡器以将流量路由到入站网关并使用 HTTPS 协议启动连接（如前所述）
创建一组 Compute Engine API 资源，以表示入站流量网关及其服务器 TLS 政策。

对于第三步，请将 Cloud Service Mesh 配置为终止 HTTPS 并提供证书，如下所示：

创建全局转发规则和目标 HTTPS 代理以表示进入网格的入站流量的路径。
将网格的现有网址映射附加到此目标 HTTPS 代理。根据您在配置网格和 mTLS 时提供的配置，网址映射已包含对网格的各种全局后端服务的引用。
创建服务器 TLS 政策：配置 serverCertificate。
将服务器 TLS 政策资源附加到目标 HTTPS 代理。

入站网关模式在使用共享 VPC 的大型组织中尤为有用。在这样的设置中，团队可以只允许通过入站网关访问其服务。在上图中，配置全局转发规则时提供的 IP 地址（在此示例中为 10.0.0.2）与配置网格时提供的 IP 地址（在此示例中，网格地址为 10.0.0.1）不同。通过 Cloud Service Mesh 配置的 xDS 数据平面实体进行通信的客户端可以使用此地址访问入站网关。

举例说明，假设有以下架构：

两个服务项目（1 和 2），均连接到同一共享 VPC 网络。
服务项目 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 中的入站网关进行通信。这使服务项目 1 的所有者可以配置专门针对进入网格的流量的路由、安全设置和其他政策。事实上，服务项目 1 的所有者可以告诉其他人“您的网格中的客户端可以通过 10.0.0.2 访问我的服务”。

限制

只有 GKE 支持 Cloud Service Mesh 服务安全。您无法使用 Compute Engine 部署服务安全。

后续步骤

如需使用 Envoy 代理配置 Cloud Service Mesh 服务安全，请参阅使用 Envoy（旧版）设置 Cloud Service Mesh 服务安全。
如需使用无代理 gRPC 应用配置 Cloud Service Mesh 服务安全，请参阅使用无代理 gRPC（旧版）设置 Cloud Service Mesh 服务安全。