Cloud Service Mesh 安全最佳实践

注意 ：本指南仅支持使用 Istio API 的 Cloud Service Mesh，不支持 Google Cloud API。如需了解详情，请参阅 Cloud Service Mesh 概览。

本文档介绍了确定和管理 Google Kubernetes Engine (GKE) 上运行的安全 Cloud Service Mesh 配置的最佳实践。本文档中的指导不仅介绍了用于配置和安装 Cloud Service Mesh 的设置，并且还介绍了如何将 Cloud Service Mesh 与其他 Google Cloud 产品和功能搭配使用，以应对网格中的应用可能面临的安全威胁。

本文档的目标受众群体包括在 Cloud Service Mesh 中管理政策的管理员，以及在 Cloud Service Mesh 中运行服务的用户。对于需要增强服务网格安全性以满足合规性要求的组织，此处介绍的安全措施也非常有用。

文档的结构如下：

• 简介
• 攻击途径和安全风险
  • 攻击途径
  • 安全风险
• 保护服务网格的措施
  • 安全架构
  • 集群安全
    • 启用严格的双向 TLS
    • 启用访问权限控制
      • 强制执行 Cloud Service Mesh 身份验证政策
      • JSON Web 令牌 (JWT)
      • Cloud Service Mesh 用户身份验证
      • 强制执行授权政策
      • 强制执行令牌交换来访问网格服务
    • 安全处理 Cloud Service Mesh 政策例外
      • 强制执行 Kubernetes 网络政策
    • 安全访问控制平面
    • 强制执行命名空间边界
      • 强制执行 Kubernetes RBAC 政策
  • 网格边缘安全
    • 集群入站流量访问权限控制
    • 监管集群出站流量
    • 使用专用集群或 VPC Service Controls 锁定外部访问
    • 防范外部 DDoS 攻击
  • 网格管理和自动化的安全性
    • 细分用于网格操作的角色
    • 自动验证政策配置
      • 将 GitOps 方法与 Config Sync 搭配使用以防止配置偏移
    • 强制执行审核日志记录和监控
    • 保护集群内证书的证书授权机构
  • 工作负载安全
    • 限制 Pod 权限
    • 保护容器映像
    • 抵御网格漏洞
    • 使用适用于 GKE 的工作负载身份联合安全地访问 Google 服务
    • 通过安全信息中心和遥测监控安全状态
  • 敏感的用户数据和凭据的安全性

简介

Cloud Service Mesh 提供的功能和工具可帮助您以统一的方式观察、管理和保护服务。它采用以应用为中心的方法并使用可信应用身份，而非基于网络 IP 的方法。您可以透明地部署服务网格，而无需修改现有的应用代码。Cloud Service Mesh 以声明方式控制网络行为，有助于将负责交付和发布应用功能的团队的工作与负责安全和网络的管理员的工作分离。

Cloud Service Mesh 基于开源 Istio 服务网格，可实现复杂的配置和拓扑。根据您的组织的结构，一个或多个团队或角色可能负责安装和配置网格。系统会选择默认的 Cloud Service Mesh 设置来保护应用（但在某些情况下，您可能需要使用自定义配置），或通过阻止某些应用、端口或 IP 地址参与网格来授予例外。制定管理网格配置和安全异常的控制措施非常重要。

注意：本指南是对 Istio 安全性方面的最佳做法文档的补充，其中包括双向 TLS (mTLS)、授权政策、网关和其他安全配置的详细配置建议。您应该将这些建议作为基础，与本指南中所述的最佳做法结合使用。本指南介绍了 Cloud Service Mesh 的其他最佳实践，以及 Google Cloud 中的技术如何保护网格中的所有层、组件和信息流。

攻击途径和安全风险

攻击途径

Cloud Service Mesh 安全遵循零信任安全模型，该模型假定安全威胁源自组织的安全边界的内部和外部。可能威胁服务网格中的应用的安全攻击类型示例包括：

• 数据渗漏攻击。例如，监听来自服务间流量的敏感数据或凭据的攻击。
• 中间人攻击。例如，伪装成合法服务来获得或修改服务之间的通信的恶意服务。
• 提升权限攻击。例如，通过非法使用提升的权限在网络中执行操作的攻击。
• 拒绝服务 (DoS) 攻击。
• 尝试入侵和操纵某些服务来对其他服务发起攻击的僵尸网络攻击。

您还可以根据攻击目标对攻击进行分类：

• 网格内部网络攻击。针对篡改、窃听或仿冒网格内部服务到服务或服务到控制平面通信的攻击。
• 控制平面攻击。针对导致控制平面故障（例如 DoS 攻击）或渗漏控制平面的敏感数据的攻击。
• 网格边缘攻击。针对篡改、窃听或仿冒网格入站流量或出站流量的通信的攻击。
• 网格操作攻击。针对网格操作的攻击。攻击者可能会尝试获取提升的权限以在网格中执行恶意操作，例如修改其安全政策和工作负载映像。

安全风险

除安全攻击外，网格还会面临其他安全风险。以下列表介绍了一些可能的安全风险：

• 安全保护不完整。服务网格未配置身份验证和授权政策来保护其安全性。例如，没有为网格中的服务定义身份验证或授权政策。
• 安全政策例外。为了适应特定的使用场景，用户可能会为某些流量（内部或外部）创建安全政策例外，以便从 Cloud Service Mesh 安全政策中排除。如需安全处理此类场景，请参阅安全处理政策例外部分。
• 忽视映像升级。可能会发现网格中使用的映像存在漏洞。您需要确保网格组件和工作负载映像始终使用最新的漏洞修复程序。
• 缺少维护（无专业知识或资源）。网格软件和政策配置需要定期维护，以利用最新的安全保护机制。
• 缺少可见性。配置错误或不安全的网格政策配置以及异常网格流量/操作未受到网格管理员的注意。
• 配置偏移。网格中的政策配置不符合可靠来源。

保护服务网格的措施

本部分提供了保护服务网格的操作手册。

安全架构

服务网格的安全性取决于网格系统及其应用中不同层的组件的安全性。建议的 Cloud Service Mesh 安全状况的总体意图是通过集成不同层的多个安全机制来保护服务网格，这些机制在零信任安全模型下共同实现整体系统安全性。下图展示了建议的 Cloud Service Mesh 的安全状况。

Cloud Service Mesh 在多个层提供安全性，包括：

• 网格边缘安全
  • Cloud Service Mesh 入站流量安全可为外部流量提供访问权限控制，并保护对网格中服务公开的 API 的外部访问权限。
  • Cloud Service Mesh 出站流量安全可监管来自内部工作负载的出站流量。
  • Cloud Service Mesh 用户身份验证与 Google 基础架构集成，可对网络浏览器到运行 Web 应用的服务的外部调用进行身份验证。
  • Cloud Service Mesh 网关证书管理通过 Certificate Authority Service 来保护并轮替 Cloud Service Mesh 入站和出站流量网关使用的私钥和 X.509 证书。
  • Cloud Armor 可以防范外部分布式拒绝服务 (DDoS) 攻击和第 7 层攻击。它可充当 Web 应用防火墙 (WAF) 来保护网格免受网络攻击。例如，注入和远程代码执行攻击。
  • VPC 和 VPC Service Controls 通过专用网络访问权限控制来保护网格边缘。
• 集群安全
  • Cloud Service Mesh 双向 TLS (mTLS) 会强制执行工作负载到工作负载的流量加密和身份验证。
  • 代管式 CA（例如 Cloud Service Mesh 证书授权机构和 Certificate Authority Service）可安全地预配和管理工作负载使用的证书。
  • Cloud Service Mesh 授权会根据网格服务的身份和其他特性对其强制执行访问权限控制。
  • GKE Enterprise 安全信息中心可监控工作负载的安全政策和 Kubernetes 网络政策的配置。
  • Kubernetes 网络政策会根据 IP 地址、Pod 标签、命名空间等强制执行 Pod 访问权限控制。
  • 控制平面安全可防范对控制平面的攻击。此保护可防止攻击者修改、利用或泄露服务和网格配置数据。
• 工作负载安全
  • 及时了解 Cloud Service Mesh 安全版本，以确保网格中运行的 Cloud Service Mesh 二进制文件不存在公开已知的漏洞。
  • 适用于 GKE 的工作负载身份联合可让工作负载获取凭据以安全地调用 Google 服务。
  • Kubernetes CNI（容器网络接口）通过消除对特权 Cloud Service Mesh init 容器的需求来防止提升权限攻击。
• 运维人员安全
  • Kubernetes 基于角色的访问权限控制 (RBAC) 会限制对 Kubernetes 资源的访问权限并限制运维人员权限，以抵御恶意运维人员或运维人员冒充别人的攻击。
  • GKE Enterprise Policy Controller 会验证并审核网格中的政策配置，以防止配置错误。
  • Google Cloud Binary Authorization 可确保网格中的工作负载映像是由管理员授权的映像。
  • Google Cloud Audit Logging 可审核网格操作。

下图展示了使用 Cloud Service Mesh 中的集成式安全解决方案的通信和配置流程。

集群安全

启用严格的双向 TLS

中间人 (MitM) 攻击会尝试在两个通信方之间插入恶意实体，以监听或操纵通信。Cloud Service Mesh 通过对所有通信方强制执行 mTLS 身份验证和加密来防范 MitM 和数据渗漏攻击。宽松模式在双方都支持 mTLS 时使用 mTLS，但允许不使用 mTLS 的连接。相比之下，严格的 mTLS 要求使用 mTLS 对流量进行加密和身份验证，并且不允许纯文本流量。

借助 Cloud Service Mesh，您可以为工作负载中的 TLS 连接配置满足安全性及合规性要求所需的最低 TLS 版本。

如需了解详情，请参阅 Cloud Service Mesh 示例：mTLS | 强制执行网格级 mTLS。

启用访问权限控制

除非有强有力的理由从 Cloud Service Mesh 安全政策中排除服务或 Pod，否则应对进出网格的所有流量都强制执行 Cloud Service Mesh 安全政策（例如身份验证和授权政策）。在某些情况下，用户可能有合法的理由对某些端口和 IP 范围绕过 Cloud Service Mesh 安全政策。例如，与非 Cloud Service Mesh 管理的服务建立原生连接。如需在此类使用场景下保护 Cloud Service Mesh，请参阅安全处理 Cloud Service Mesh 政策例外。

服务访问权限控制对于防止未经授权访问服务至关重要。强制执行 mTLS 会对请求进行加密和身份验证，但网格仍然需要 Cloud Service Mesh 授权政策才能对服务强制执行访问权限控制。例如，拒绝来自经过身份验证的客户端的未经授权请求。

Cloud Service Mesh 授权政策提供了一种灵活的访问权限控制配置方法，可保护您的服务免遭未经授权的访问。应根据从身份验证结果派生的经过身份验证的身份强制执行 Cloud Service Mesh 授权政策，而基于 mTLS 或 JSON Web 令牌 (JWT) 的身份验证应作为 Cloud Service Mesh 授权政策的一部分结合使用。

强制执行 Cloud Service Mesh 身份验证政策

JSON Web 令牌 (JWT)

除了 mTLS 身份验证外，网格管理员还可以要求服务根据 JWT 对请求进行身份验证和授权。Cloud Service Mesh 不充当 JWT 提供方，但会根据配置的 JSON Web 密钥集 (JWKS) 端点对 JWT 进行身份验证。JWT 身份验证可应用于外部流量的入站网关或应用于网格内流量的内部服务。当 JWT 用作凭据来代表最终调用方并且请求的服务需要证明其代表最终调用方进行调用时，JWT 身份验证可与 mTLS 身份验证结合使用。强制执行 JWT 身份验证可以防范没有有效凭据并代表实际最终用户访问服务的攻击。

Cloud Service Mesh 用户身份验证

Cloud Service Mesh 用户身份验证是一种集成式解决方案，用于基于浏览器的最终用户身份验证和对工作负载的访问权限控制。它将服务网格与现有身份提供方 (IdP) 集成以实现标准基于 Web 的 OpenID Connect (OIDC) 登录和同意流程，并使用 Cloud Service Mesh 授权政策进行访问权限控制。

强制执行授权政策

Cloud Service Mesh 授权政策控制：

• 允许谁或什么访问服务。
• 可以访问哪些资源。
• 可对允许的资源执行哪些操作。

授权政策是一种根据服务运行采用的实际身份、流量应用层（第 7 层）属性（例如请求标头）和网络层（第 3 层和第 4 层）属性（例如 IP 范围和端口）配置访问权限控制的通用方法。

应根据从身份验证结果派生的经过身份验证的身份强制执行 Cloud Service Mesh 授权政策，以防范未经授权访问服务或数据。

默认情况下，除非明确定义了授权政策来允许访问服务，否则应拒绝访问服务。如需查看拒绝访问请求的授权政策示例，请参阅授权政策最佳做法。

授权政策应尽可能限制信任。例如，可以根据服务公开的个别网址路径定义对服务的访问权限，以便只有服务 A 可以访问服务 B 的路径 /admin。

授权政策可与 Kubernetes 网络政策结合使用，后者仅在网络层（第 3 层和第 4 层）运行，并控制 Kubernetes Pod 和 Kubernetes 命名空间中的 IP 地址和端口的网络访问权限。

注意 ：Cloud Service Mesh 不处理非 TCP 流量（例如 UDP），因此授权政策无法控制此流量。网格管理员可以使用 Kubernetes 网络政策来为 UDP 流量定义政策。例如，如果网格服务不使用 UDP，则网格管理员可以定义 Kubernetes 网络政策来阻止 UDP 流量。

强制执行令牌交换来访问网格服务

为了防范令牌重放攻击，即窃取令牌并重复使用被盗的令牌来访问网格服务，来自网格外部的请求中的令牌应交换为网格边缘处短期有效的网格内部令牌。

从网格外部访问网格服务的请求需要包含 JWT 或 Cookie 等令牌，以便通过网格服务进行身份验证和授权。来自网格外部的令牌可能是长期有效的令牌。为了防范令牌重放攻击，来自网格外部的令牌应交换为网格入站处范围受限的短期有效的网格内部令牌。网格服务会对网格内部令牌进行身份验证，并根据网格内部令牌授权访问请求。

后续步骤

• 查看在 GKE 集群上使用 Cloud Service Mesh 出站流量网关的最佳实践
• 配置传输安全
• 更新授权政策