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 地址参与网格来授予例外。制定管理网格配置和安全异常的控制措施非常重要。

攻击途径和安全风险

攻击途径

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

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

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

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

安全风险

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

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

保护服务网格的措施

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

安全架构

服务网格的安全性取决于网格系统及其应用中不同层的组件的安全性。建议的 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 基于网络令牌 (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 用户身份验证是一种集成式解决方案，用于基于浏览器的最终用户身份验证和对工作负载的访问权限控制。它将服务网格与现有 Identity 集成 用于实现标准 Web OpenID Connect (OIDC) 登录的提供方 (IdP) 和同意流程，并使用 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 等令牌，以便通过网格服务进行身份验证和授权。来自网格外部的令牌可能是长期有效的令牌。为了防范令牌重放攻击，来自网格外部的令牌应交换为网格入站处范围受限的短期有效的网格内部令牌。网格服务会对网格内部令牌进行身份验证，并根据网格内部令牌授权访问请求。

后续步骤