Cloud Service Mesh 安全最佳实践

本文档介绍了确定和管理 Google Kubernetes Engine (GKE) 上运行的安全 Cloud Service Mesh 配置的最佳实践。有关 文档中介绍了用于配置和安装 云服务网格 以及如何将 Cloud Service Mesh 与其他 Google Cloud 服务 以抵御应用面临的安全威胁的产品和功能 网格中可能出现的物体

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

文档的结构如下：

简介

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

Cloud Service Mesh 基于开源的 Istio 服务网格 支持复杂的配置和拓扑。根据您的组织的结构，一个或多个团队或角色可能负责安装和配置网格。已选择默认 Cloud Service Mesh 设置 但在某些情况下 自定义配置，或通过排除特定应用、端口 或 IP 地址的 IP 地址制定管理网格配置和安全异常的控制措施非常重要。

攻击途径和安全风险

攻击途径

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

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

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

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

安全风险

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

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

保护服务网格的措施

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

安全架构

服务网格的安全性取决于网格系统及其应用中不同层的组件的安全性。概要 所提议的 Cloud Service Mesh 安全态势的目的是确保 通过在不同位置集成多种安全机制来保障其安全， 各层在零信任机制下共同实现整体系统安全性 安全模型。下图显示了提议的 Cloud Service Mesh 安全状况。

Cloud Service Mesh 的安全状况

Cloud Service Mesh 在多个层级提供安全保障，包括：

  • 网格边缘安全
    • Cloud Service Mesh 入站流量安全为 并保护对由 服务
    • Cloud Service Mesh 出站流量安全控制出站流量 从内部工作负载中移除
    • Cloud Service Mesh 用户身份验证与 Google 基础架构集成，可对网络浏览器到运行 Web 应用的服务的外部调用进行身份验证。
    • Cloud Service Mesh 网关证书管理 保护和轮替 Cloud Service Mesh 入站和出站网关， Certificate Authority Service。
    • 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 可审核网格操作。

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

安全图表流量

集群安全

启用严格的双向 TLS

中间人 (MitM) 攻击会尝试在两个通信方之间插入恶意实体，以监听或操纵通信。Cloud Service Mesh 通过 正在强制执行 mTLS 身份验证和加密 所有通信方宽松模式在双方都支持 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 提供方，但会对 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 地址和端口的网络访问权限。

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

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

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

后续步骤