将 Cloud Service Mesh 与 Istio API 搭配使用的安全性最佳实践

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

本文档的目标受众包括负责管理 和在 Cloud Service Mesh 中运行的服务所有者， Cloud Service Mesh。此处所述的安全措施还 对需要增强服务安全性的组织非常有用 以满足合规性要求。

文档的结构如下：

简介

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 在多个层级提供安全保障，包括：

  • 网格边缘安全
    • Cloud Service Mesh 入站流量安全为外部 并保护对服务公开的 API 的外部访问 。
    • Cloud Service Mesh 出站流量安全通过 内部工作负载
    • Cloud Service Mesh 用户身份验证 与 Google 基础设施集成，对外部调用进行身份验证 从网络浏览器迁移到运行 Web 应用的服务。
    • Cloud Service Mesh 网关证书管理 保护和轮替 使用 Certificate Authority Service 的 Cloud Service Mesh 入站流量和出站流量网关。
    • VPC 和 VPC Service Controls 通过专用网络访问权限控制来保护网格边缘。
  • 集群安全
    • Cloud Service Mesh 双向 TLS (mTLS) 会强制执行工作负载到工作负载的流量加密和身份验证。
    • Cloud Service Mesh 证书授权机构安全地预配和管理使用的证书 工作负载
    • Cloud Service Mesh 授权会根据网格服务的身份和其他特性对其强制执行访问权限控制。
    • GKE Enterprise 安全信息中心可监控工作负载的安全政策和 Kubernetes 网络政策的配置。
    • 基于 IP 的 Kubernetes 网络政策强制执行 Pod 访问权限控制 Pod 标签和命名空间等
  • 工作负载安全
    • 及时了解 Cloud Service Mesh 安全版本，以确保 在网格中运行的 Cloud Service Mesh 二进制文件不含众所周知 漏洞
    • 适用于 GKE 的工作负载身份联合可让工作负载获取凭据以安全地调用 Google 服务。
    • Cloud Key Management Service (Cloud KMS) 通过硬件安全模块 (HSM) 来保护敏感数据或凭据。例如，工作负载可以使用 Cloud KMS 存储凭据或其他敏感数据。CA 服务（用于为网格工作负载颁发证书）支持由 Cloud KMS 管理的每个客户受 HSM 支持的签名密钥。
    • Kubernetes 容器网络接口 (CNI) 通过消除对特权 Cloud Service Mesh init 容器的需求来防止提升权限攻击。
  • 运维人员安全
    • Kubernetes 基于角色的访问权限控制 (RBAC) 会限制对 Kubernetes 资源的访问权限并限制运维人员权限，以抵御恶意运维人员或运维人员冒充别人的攻击。
    • GKE Enterprise Policy Controller 会验证并审核网格中的政策配置，以防止配置错误。
    • Google Cloud Binary Authorization 可确保网格中的工作负载映像是由管理员授权的映像。
    • Cloud Audit Logs 可审核网格操作。

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

安全流量流

集群安全

本部分介绍与集群安全相关的最佳实践。

启用严格的双向 TLS

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

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

如需了解详情，请参阅云端服务网格示例：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 身份验证政策

在考虑 Cloud Service Mesh 身份验证政策时，请考虑以下几点。

JSON Web 令牌 (JWT)

除了 mTLS 身份验证外，网格管理员还可以要求服务根据 JWT 对请求进行身份验证和授权。Cloud Service Mesh 不充当 JWT 提供方，但会根据 已配置的 JSON Web 密钥集 (JWKS) 端点。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 等令牌，以便通过网格服务进行身份验证和授权。来自网格外部的令牌可能是长期有效的令牌。为了防范令牌重放攻击，请在网格入站处将来自网格外部的令牌交换为范围受限的短期有效的网格内部令牌。网格服务会对网格内部令牌进行身份验证，并根据网格内部令牌授权访问请求。

Cloud Service Mesh 支持与 Identity-Aware Proxy (IAP) 集成，后者会生成在 Cloud Service Mesh 中用于授权的 RequestContextToken（从外部令牌交换的短期有效的网格内部令牌）。通过令牌交换，攻击者无法在网格中使用被盗的令牌来访问服务。交换后的令牌的范围和生命周期有限可以大大降低令牌重放的可能性。

安全地处理 Cloud Service Mesh 政策例外情况

您的服务网格可能有特殊用例。例如，您可能需要向纯文本流量公开某个网络端口。为了满足 但有时可能需要创建例外， 要从 Cloud Service Mesh 安全中排除的内部或外部流量 政策，这会带来安全问题

您可能会出于正当理由绕过 Cloud Service Mesh 安全政策， 部分端口和 IP 范围您可以添加 annotations， 例如 excludeInboundPorts、excludeOutboundPorts 和 excludeOutboundIPRanges 发送到 Pod，以排除 Envoy Sidecar。除了通过注释排除流量外，您可以绕过网格 只需使用 Google Cloud Armor 已停用 Sidecar 注入 - 例如，将标签sidecar.istio.io/inject="false"添加到 应用 Pod

绕过 Cloud Service Mesh 安全政策会对整体系统安全性产生负面影响。例如，如果通过注解对网络端口绕过 Cloud Service Mesh mTLS 和授权政策，则不会对端口上的流量进行访问权限控制，并且可能造成窃听或流量修改。此外，绕过 Cloud Service Mesh 政策 还会影响 非安全政策，例如网络政策

当某个端口绕过 Cloud Service Mesh 安全政策时，或 IP 地址（可以是 ），我们强烈建议您使用 采取了安全措施来保护网格并监控安全异常 潜在安全漏洞和整体安全性强制执行状态。在这种情况下，如需保护网格，您可以执行以下操作：

  • 确保绕过 Sidecar 的流量采用原生方式进行加密和身份验证，以防止 MitM 攻击。
  • 强制执行 Kubernetes 网络政策，以限制具有政策例外的端口的连接性（例如，限制具有政策例外的端口，仅允许来自同一命名空间中的其他服务的流量），或仅允许流量通过强制执行了 Cloud Service Mesh 安全政策的端口。

将 GitOps 方法与 Config Sync 搭配使用以防止配置偏移

当网格中的政策配置不符合其真实来源时，会发生配置偏移。您可以使用 Config Sync 来防止配置偏移。

强制执行 Cloud Audit Logs 和监控

我们建议网格管理员监控以下资源：

管理员可以使用这些可观测性资源来验证安全配置是否按预期工作，并监控是否存在任何安全政策强制执行例外。例如，未通过 Sidecar 的访问、没有有效凭据但到达服务的访问。

虽然开源可观测性软件（例如 Prometheus）可与 Cloud Service Mesh 搭配使用，但我们强烈建议您使用 Google Cloud Observability。这一 Google Cloud 内置的可观测性解决方案提供日志记录、 指标收集、监控和提醒，是一项全代管式服务。

工作负载安全

工作负载安全可防止发生以下攻击：入侵工作负载 Pod，然后使用被入侵的 Pod 对集群发起攻击（例如僵尸网络攻击）。

限制 Pod 权限

Kubernetes Pod 可能具有影响节点或集群上的其他 Pod 的权限。对工作负载 Pod 强制实施安全限制非常重要，可以防止被入侵的 Pod 针对集群发起攻击。

对 Pod 上的工作负载强制执行最小权限原则：

  • 网格中部署的服务应以尽可能少的权限运行。
  • 您可以将 Cloud Service Mesh 配置为使用 init 容器来配置指向 Sidecar 的 iptables 流量重定向。这要求用户创建 有权使用容器部署容器的 NET_ADMIN 和 NET_RAW 功能。为避免在运行容器时 进行升级时，网格管理员可以改为 启用 Istio CNI 插件 用于配置将流量重定向到 Sidecar。

保护容器映像

攻击者可能会利用易受攻击的容器映像来发起攻击。管理员应强制执行 Binary Authorization 以验证容器映像的完整性，并确保仅在网格中部署受信任的容器映像。

抵御网格漏洞

  • Artifact Analysis 可以扫描和发现 GKE 工作负载上的漏洞。
  • 常见漏洞和披露 (CVE) 处理。在出现漏洞后 网格管理员可以修复 修复漏洞Google 会自动处理修补 影响网格映像的 CVE。

使用适用于 GKE 的工作负载身份联合安全地访问 Google 服务

对于网格工作负载，建议使用 适用于 GKE 的工作负载身份联合安全地访问 Google 服务。与将 服务账号密钥 存储在 Kubernetes Secret 中，并使用服务账号密钥来访问 Google 安全性较低 凭据泄露、权限升级、信息泄露和 不可否认性。

通过安全信息中心和遥测监控安全状态

服务网格可能存在安全异常和潜在漏洞。呈现和监控网格的安全状态至关重要，其中包括强制执行的安全政策、安全异常以及网格中潜在的安全漏洞。您可以使用 GKE Enterprise 安全信息中心和遥测来呈现和监控网格安全状态。

遥测会监控网格中服务的健康状况和性能，使网格管理员能够观察服务的行为（例如 SLO、异常流量、服务中断和拓扑）。

GKE Enterprise 安全信息中心 应用于服务网格中的工作负载，包括访问权限控制政策 （Kubernetes 网络政策、Binary Authorization 政策和服务访问权限） 控制政策）和身份验证政策 (mTLS)。

敏感的用户数据和凭据的安全性

如果您将敏感的用户数据或凭据存储在永久性 例如 Kubernetes Secret 或 Pod 中直接存储的数据或凭据 可能容易受到来自 Pod 的攻击或恶意操作。 如果通过网络传输数据，数据也容易受到网络攻击 用于向服务进行身份验证的网络。