服务安全

本文档简要介绍了 Traffic Director 的服务安全性。适用于想要向其部署添加身份验证、加密和授权的 Traffic Director 用户。本文档假定您熟悉带有 Envoy 的 Traffic Director 和无代理 gRPC 应用。

借助 Traffic Director，您可以在网格中保护服务间通信。在网格中，每个服务都有一个身份。以下功能为安全通信提供支持：

  • 使用传输层安全性 (TLS) 和双向 TLS (mTLS) 的身份验证和加密，适用于带有 Envoy 的 Traffic Director 和带有无代理 gRPC 应用的 Traffic Director。客户端 TLS 政策和服务器 TLS 政策控制服务是否需要相互证明身份并使用加密通信通道。
  • 根据客户端和请求的特征进行授权。授权政策控制是否允许某服务访问其他服务，以及允许哪些操作。

使用由私有证书授权机构 (CA)，Google 的 Certificate Authority Service 提供的证书和密钥，您可以更轻松地维护服务安全。CA Service 提供 GKE 网格证书。GKE 网格证书功能和 Traffic Director 允许您自动部署这些证书并用于工作负载。您可以修改 pod，以允许工作负载接收和使用 mTLS 凭据。Traffic Director 服务安全目前仅适用于基于 GKE 的工作负载。

在基于微服务的现代架构中，更小、更有针对性的服务取代了大型单体式应用。服务调用通过网络相互通信。这些调用是单体式应用中的进行中调用，存在安全挑战，因此最好对其进行身份验证、加密和授权。这些步骤支持零信任原则，即所有网络流量均被视为有风险，无论流量源自网络内部还是外部。

服务网格设计模式将服务间通信的任何复杂性与业务逻辑分离开来，相反，数据层面负责处理这种复杂性。除了降低应用的复杂性，服务网格设计模式还支持原本难以实现和管理的安全模式。

在此模型中，无代理 gRPC 或 Envoy Sidecar 从 Traffic Director 获取配置信息并从 CA 服务池获取证书，从而安全地进行身份验证和加密。

这些安全功能通过提供以下功能来简化 Traffic Director 部署过程：

  • 自动将密钥和证书供应到网格中的所有服务。
  • 自动轮替键和证书以提供额外的安全性。
  • 与 Google Kubernetes Engine (GKE) 集成，以使用其所有功能，例如部署描述符和标签。
  • Google 代管式服务的高可用性，包括 Traffic Director 和 CA Service 代管式私有证书授权机构池。
  • 与 Google Identity and Access Management (IAM) 相关的安全性：基于授权的 Google 服务账号的服务授权。
  • 与基于 Envoy 的工作负载和无代理工作负载实现无缝互操作性。例如，服务可以位于 Envoy 代理后面，但客户端会使用 gRPC 无代理服务网格安全。相反，服务可以使用 gRPC 无代理服务网格安全机制，但客户端会使用 Envoy 代理。

保障服务间通信的安全

Traffic Director 通过使用 TLS 的加密和身份验证提供授权以及服务间的安全性。客户端 TLS 政策和服务器 TLS 政策允许服务执行以下操作：

  • 声明和验证其身份。
  • 使用 TLS 或 mTLS 加密通信会话。

在服务网格中，数据平面会处理此类安全措施，因此应用无需特进行特殊供应来保证安全性。

授权政策可让您根据自己定义的规则拒绝或允许访问。

使用 TLS 进行加密

当某服务使用 HTTP、HTTP/2 或 gRPC 协议调用其他服务时，传输网络的流量采用纯文本形式。此流量可能会受到中间人攻击，即攻击者拦截流量并检查或操纵其内容。

要缓解此潜在问题，您可以将基于 TLS 的 HTTP、HTTP/2 或 gRPC 与 Traffic Director 搭配使用。使用基于 TLS 的这些协议时，客户端和服务器之间的流量使用基于服务器证书的 TLS 进行加密。流量不再是纯文本形式，这降低了攻击者拦截并检查或操纵流量内容的可能性。

使用 TLS 进行身份验证

当某服务调用其他服务时，请考虑以下问题：

  • 客户端如何确定它收到的响应来自正确的服务器（而不是假冒的服务器）？例如，在基于 HTTP 的典型请求-响应交互中，客户端不会验证服务器的身份。

  • 如果攻击者拦截了该流量，会发生什么情况？例如，HTTP 流量未经加密，因此任何收到流量的人都可以检查其内容。这称为“中间人攻击”。

要缓解这些问题，您可以使用 HTTP、HTTP/2 和 gRPC over TLS。在客户端与服务器之间的这些交换中，服务器必须使用服务器证书向客户端证明其身份。然后，请求和响应会通过 TLS 加密。

双向 TLS 身份验证

当 Traffic Director 同时为客户端和服务器配置应用网络时（例如，在客户端配置 Envoy 代理，并在服务器端配置另一个 Envoy 代理），您可以利用高级身份验证模式，例如双向身份验证。

在典型的 HTTP over TLS 交换（不是基于双向身份验证）中，服务器使用一个证书加密客户端和服务器之间的通信。客户端可以通过检查服务器在 TLS 握手期间发回的签名来验证服务器的身份。但是，服务器不会验证客户端的身份。

如果启用双向身份验证，客户端也会有一个证书。客户端会验证服务器的身份（如上一段所述），服务器也可以验证客户端的身份。客户端证书和服务器证书均用于加密通信通道。这也使得服务器能够根据经过验证的客户端身份向客户端授权。

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

向服务调用授权

您可以选择使用授权政策来允许或拒绝服务访问。借助 Traffic Director，您可以定义允许和拒绝规则，以根据请求参数来授权访问。这些规则可以基于第 3 层和第 7 层参数，包括客户端 ID（源自 mTLS 连接中的 client-cert）、来源 IP 地址、主机匹配、方法匹配和标头匹配。下图展示了 Envoy 代理授权。该过程与 gRPC 客户端类似。

服务网格中的授权。
使用 Envoy 在服务网格中进行授权（点击可放大）

使用授权限制访问权限

服务网格中的最佳做法是遵循最小权限原则。要遵循此原则，您可以仅允许依赖某个服务的调用者访问该服务。当未获授权的调用者尝试访问服务时，尝试将被拒绝。

借助 Traffic Director，您可以配置授权政策，使数据层面能够根据您定义的规则允许/拒绝服务访问。这些政策由两个部分组成：

  • 操作：允许或拒绝
  • 规则列表

请求或 RPC 发送后，被调用服务上的 Traffic Director 客户端确定是否有规则匹配。如果找到匹配项，则允许或拒绝请求或 RPC。您可以定义规则来匹配如下所示的特性：

  • 使用 mTLS 时，调用服务的 Kubernetes 服务账号
  • 调用服务的 IP 地址（或地址范围）
  • 目标服务的端口
  • 请求的 HTTP 特性，包括主机名、方法和用户定义的 HTTP 标头。

安全命名

作为额外的安全机制，您可以使用 Traffic Director 配置安全命名。您可以为客户端尝试连接的特定服务定义允许的名称或 SPIFFE (Secure Production Identity Framework for Everyone) 身份的列表。在 TLS 交换期间，服务的后端向客户端返回 X.509 证书。然后，客户端检查证书，以确认 X.509 证书与其中一个名称或 SPIFFE 身份匹配。如需详细了解 SPIFFE 身份，请参阅 Secure Production Identity Framework for Everyone。

保护网关的流量

如需配置网关，您可以使用 Traffic Director。网关是一个独立的 Envoy 代理，通常担任以下角色：

  • 处理进入网格或其他网域的流量的入站网关
  • 处理离开网格或其他网域的流量的出站网关
  • 在一个或多个服务之间分配入站流量的反向代理或中间代理

想要将流量发送到网格或发离网格的客户端会将流量发送到网关。然后，网关会根据您使用 Traffic Director 设置的规则处理请求。例如，您可以强制通过入站网关进入网格的流量使用 TLS 加密。

安全组件

Traffic Director 服务安全支持客户端 TLS 政策、服务器 TLS 政策和授权政策。您创建这些政策后，Traffic Director 可以配置数据层面并启用安全功能。如需创建或更新这些政策，您无需更改应用。

加密和支持的身份验证模式

当某个服务调用另一个服务时，建立安全通信的第一步是让每个服务向另一个服务证明自己的身份。服务证明身份的强度取决于您配置的 TLS 模式。

您可以配置以下安全级别：

  • 未加密/未经身份验证
  • TLS
  • 双向 TLS (mTLS)
  • 宽松：mTLS 或未加密/未经身份验证，具体取决于客户端发起连接的方式

证书和证书授权机构

证书和可信的证书授权机构 (CA) 在分布式系统（如服务网格）中提供信任基础。使用证书，服务可以通过以下方式证明其身份并验证提供给它们的身份：

  • 想要向另一个服务证明其身份的服务将证书提供给另一个服务。两种服务均信任的证书授权机构以加密方式签署并颁发此证书。
  • 收到此证书的服务可以验证证书来源于其信任的 CA。

Traffic Director 不是证书授权机构。为实现安全通信，您必须设置可以执行以下操作的机制：

  • 供应身份和证书
  • 将证书提供给 Traffic Director 配置的 Traffic Director 客户端（例如 Envoy 代理）。

Traffic Director 支持 Google 的 CA Service。Envoy 和无代理 gRPC 的设置指南介绍了如何进行此设置（如需了解详情，请参阅后续步骤）。

架构和资源

Traffic Director 包含 Network Security API 命名空间，其中包含三个 Google Cloud API 资源，您可以通过这些资源指定应用于数据层面的安全政策。

两个 Google Cloud API 资源支持网格中的身份验证：客户端 TLS 政策和服务器 TLS 政策。第三个资源是授权政策，该资源支持授权。

Network Services API 命名空间包含端点政策资源，该资源使 Traffic Director 能够向端点提供配置（服务器 TLS、客户端 TLS 和授权政策）。端点是 Traffic Director 客户端，终止来自另一个 Traffic Director 客户端的入站通信。

客户端 TLS 政策

通过客户端 TLS 政策，您可以指定客户端 TLS 模式和要应用于数据平面的证书提供商信息。客户端 TLS 政策支持 TLS 和 mTLS 身份验证。客户端 TLS 政策必须附加到全局后端服务资源。

配置 TLS 时，您必须提供一个机制，供客户端验证其在 TLS 交换期间从服务器收到的证书（通过使用 serverValidationCa API 字段）。客户端使用此信息来获取验证证书，用于验证服务器证书。

配置 mTLS 时，您还必须提供一个机制，使客户端能够通过使用 clientCertificate API 字段获取其证书和私键。客户端在 TLS 握手期间使用此信息向服务器提供证书。

在此版本中，Traffic Director 支持代管式证书授权机构 CA Service。其配置十分简单：在配置证书提供商时指定 google_cloud_private_spiffe 插件名称。这会使 xDS 客户端从静态位置加载证书和密钥。作为前提条件，您必须在 GKE 集群上配置 CA 服务池并启用网格证书。

服务器 TLS 政策

借助服务器 TLS 政策（ServerTlsPolicy 资源），您可以指定要应用于数据平面的服务器端 TLS 模式和证书提供商信息。服务器 TLS 政策支持 TLS、mTLS，并且支持仅使用 Envoy 的 Open_or_mTLS 身份验证。您需要将服务器 TLS 政策附加到端点政策资源。

主题的备用名称

配置全局后端服务的 securitySettings 字段时，您可以在 subjectAltNames 字段中提供主题备用名称列表。当客户端启动与服务的一个后端的 TLS 握手时，服务器会提供其 X.509 证书。客户端会检查证书的 subjectAltName 字段。如果该字段包含指定值之一，则通信将继续。前面的安全命名中介绍了此机制。

授权政策

授权政策（AuthorizationPolicy 资源）指定服务器如何对传入请求或 RPC 进行授权。您可以将其配置为根据各种参数（例如发送请求的客户端的身份、主机、标头和其他 HTTP 属性）来允许或拒绝传入的请求或 RPC。您需要将授权政策附加到端点政策资源。

限制

只有 GKE 支持 Traffic Director 服务安全。您无法使用 Compute Engine 部署服务安全。

无代理 gRPC 应用的限制

无代理 gRPC 服务的服务安全具有以下限制：

  • 此版本仅限 Java、Python、C++ 和 Go。

后续步骤