Anthos Service Mesh 安全概览
Anthos Service Mesh 安全可帮助您确保工作负载之间的所有通信均已加密、互相进行身份验证和授权，从而缓解内部威胁并降低数据泄露风险。
传统上，使用基于 IP 的规则的微细分用于缓解内部风险。但是，如果将采用的容器、共享服务和分布式生产环境分布在多个云中，则这种方法的配置和维护起来会更加困难。
通过 Anthos Service Mesh，您可以配置服务内容感知和请求内容感知网络安全，这种安全独立于底层网络安全。因此，Anthos Service Mesh 允许您采用与零信任安全原则一致的深度防御状况。这将让您可通过声明式政策实现此状况，而无需修改任何应用代码。
双向 TLS
Anthos Service Mesh 使用双向 TLS (mTLS) 进行对等身份验证。身份验证指的是身份：此服务是什么？此最终用户是谁？我可以相信他们是哪些人？
mTLS 能够帮助工作负载彼此进行身份验证。您可能熟悉如何在 HTTPS 中使用简单 TLS，以允许浏览器信任 Web 服务器以及加密交换的数据。使用简单 TLS 时，客户端会验证服务器证书，从而信任该服务器。mTLS 是 TLS 的一种实现，在这种协议中，客户端和服务器互相提供证书并验证彼此的身份。
mTLS 是 Anthos Service Mesh 实现服务间身份验证和加密的方式。
在 Anthos Service Mesh 1.6 及更高版本中，自动 mTLS 默认处于启用状态。通过自动 mTLS，客户端边车代理会自动检测服务器是否具有 Sidecar。客户端 Sidecar 会将 mTLS 发送到具有 Sidecar 的工作负载，并将纯文本流量发送到没有 Sidecar 的工作负载。但请注意，服务会接受纯文本和 mTLS 流量。为了保护您的服务网格，我们建议您迁移服务，使其仅接受 mTLS 流量。
如需详细了解如何仅强制执行 mTLS，请参阅“Anthos Service Mesh 示例：mTLS”。
加密套件配置
以下列表包含 Anthos Service Mesh 的符合 FIPS 要求的默认加密套件：
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
为了提高安全性，Anthos Service Mesh 工作负载支持的服务器端最低 TLS 版本为 1.2，它支持自定义加密套件。请注意，Anthos Service Mesh 还支持 TLS v1.3，后者对加密套件进行硬编码并且不支持更改加密套件。
如需详细了解加密套件，请参阅 Envoy 的通用 TLS 配置和 Istio 的双向 TLS 身份验证。
安全优势
Anthos Service Mesh 具有以下安全优势：
降低使用被盗凭据重放或冒充别人攻击的风险。Anthos Service Mesh 依赖于 mTLS 证书来进行对等身份验证，而不是 JSON Web 令牌 (JWT) 等不记名令牌。由于 mTLS 证书与 TLS 通道绑定，因此生产环境中的实体无法仅通过重放身份验证令牌而未访问私钥来冒充另一个实体。
确保传输加密。使用 mTLS 进行身份验证还可确保所有 TCP 通信在传输过程中都经过加密。
确保只有获得授权的客户端才能访问包含敏感数据的服务。只有经过授权的客户端才能访问包含敏感数据的服务，而不考虑客户端的网络位置和应用级层凭据。您可以指定只有具有授权服务身份或授权 Kubernetes 命名空间中的客户端才能访问服务。您还可以使用基于 IP 的访问权限政策向在 GKE Enterprise 环境之外部署的客户端授予访问权限。
降低您的生产网络中发生用户数据泄露的风险。您可以确保内部人员只能通过获授权的客户端访问敏感数据。此外，您可以确保仅当某些客户端出具有效的短期用户令牌时，客户端才能访问用户数据。这样可以规避单个客户端凭据的泄露让攻击者可访问所有用户数据的风险。
识别哪些客户端访问了包含敏感数据的服务。除 IP 地址外，Anthos Service Mesh 访问日志记录还会捕获客户端的 mTLS 身份。因此，即使工作负载是临时、动态部署的，并且在其他集群或虚拟私有云 (VPC) 网络中，您也可以轻松了解访问服务的工作负载。
特性
本部分介绍 Anthos Service Mesh 提供用于实现其安全优势的功能。
自动证书和密钥轮替
使用基于服务身份的 mTLS 可以加密所有 TCP 通信，并为访问权限控制提供更安全的不可重放凭据。大规模使用 mTLS 的一项关键挑战在于管理所有目标工作负载的密钥和证书。Anthos Service Mesh 负责为 GKE Enterprise 工作负载轮替 mTLS 密钥和证书，而不中断通信。配置较小的证书刷新间隔可以降低风险。
Anthos Service Mesh 证书授权机构 (Mesh CA)
Anthos Service Mesh 包含一个代管式多区域私有证书授权机构 Mesh CA，用于为 mTLS 颁发证书。Mesh CA 是一项高度可靠的可扩缩服务，针对云平台上动态扩缩的工作负载进行了优化。通过 Mesh CA，Google 负责管理 CA 后端的安全性和可用性。Mesh CA 让您可在 GKE Enterprise 集群中依赖单个信任根。使用 Mesh CA 时，您可以依赖工作负载身份池来提供粗粒度隔离。默认情况下，如果客户端和服务器不在同一个工作负载身份池中，则身份验证会失败。
来自 Mesh CA 的证书包含有关应用的服务的以下数据：
- Google Cloud 项目 ID
- GKE 命名空间
- GKE 服务账号名称
Certificate Authority Service
作为 Mesh CA 的替代方案，您可以将 Anthos Service Mesh 配置为使用 Certificate Authority Service，该产品适合以下使用场景：
- 您需要不同的证书授权机构对不同集群上的工作负载证书签名。
- 您需要使用 Istiod 自定义 CA 插件证书。
- 您需要将签名密钥备份到代管式 HSM 中。
- 您从事的要是严格监管的行业，且需要遵守法规。
- 您需要将 Anthos Service Mesh CA 链接到自定义企业根证书来为工作负载证书签名。
Mesh CA 的费用包含在 Anthos Service Mesh 价格中。CA Service 不包含在 Anthos Service Mesh 基础价格中，而是单独计费。此外，CA Service 附带显式 SLA，但 Mesh CA 没有。
对于此集成，Anthos Service Mesh 中的所有工作负载都被授予两个 IAM 角色：
身份感知访问权限控制（防火墙）政策
借助 Anthos Service Mesh，您可以配置基于 mTLS 身份（而非对等 IP 地址）的网络安全政策。这样，您就可以创建与工作负载的网络位置无关的政策。目前仅支持同一 Google Cloud 项目中各集群之间的通信。
请求声明感知访问权限控制（防火墙）政策
除了 mTLS 身份外，您还可以根据 HTTP 或 gRPC 请求的 JWT 标头中的请求声明授予访问权限。借助 Anthos Service Mesh，您可以断言 JWT 是由可信实体签名的。这意味着，您可以配置政策，以仅在存在请求声明或请求声明与指定值匹配时，才允许某些客户端访问。
使用 Identity-Aware Proxy 进行用户身份验证
您可以使用 Identity-Aware Proxy (IAP) 对访问 Anthos Service Mesh 入站流量网关上公开的任何服务的用户进行身份验证。IAP 可以对从浏览器登录的用户进行身份验证、与自定义身份提供商集成，以及颁发短期 JWT 令牌或 RCToken，接着可以使用此类令牌向入站流量网关或下游服务授予访问权限（使用 Sidecar）。如需了解详情，请参阅将 IAP 与 Anthos Service Mesh 集成。
使用您现有的身份提供商进行用户身份验证
您可以将现有身份提供商与 Anthos Service Mesh 集成，为部署的工作负载提供基于浏览器的最终用户身份验证和访问权限控制。如需了解详情，请参阅配置 Anthos Service Mesh 用户身份验证。
访问日志记录和监控
Anthos Service Mesh 可确保在 Google Cloud Observability 中提供访问日志和指标，并提供集成式信息中心，以便根据这些数据了解服务或工作负载的访问模式。您也可以选择配置私有目的地。借助 Anthos Service Mesh，可以在可配置的时间窗口内仅记录一次成功访问，从而减少访问日志中的噪声。系统会始终记录安全政策拒绝的请求或导致错误的请求。这样一来，您就可以大幅降低与提取、存储和处理日志相关的费用，而不会丢失密钥安全信号。
符合 FIPS 要求
x86 架构上的所有集群内控制平面组件和代理均使用已通过 FIPS 140-2 验证的加密模块。
限制
Anthos Service Mesh 安全目前存在以下限制：
- 使用 IAP 的用户身份验证要求将服务发布到互联网。借助 IAP 和 Anthos Service Mesh，您可以配置政策，以限制许可的 IP 范围中的授权用户和客户端的访问权限。如果您选择仅向同一网络中的客户端公开服务，则需要配置自定义政策引擎以进行用户身份验证和令牌颁发。