3、信任边界模型:零信任架构下的信任边界定义、数据平面与控制平面分离

在零信任架构(Zero Trust Architecture, ZTA)中,信任不再基于网络位置(如内网/外网),而是基于身份、上下文和持续验证。Envoy 代理作为服务网格的数据平面核心,其信任边界模型必须严格遵循“永不信任,始终验证”的原则。本章将定义零信任下的信任边界,并深入解析数据平面与控制平面分离如何支撑这一模型。

3.1 零信任信任边界的核心定义

传统边界安全模型(城堡+护城河)假设内网流量是可信的。零信任模型则推翻这一假设,将信任边界收缩到每一个请求、每一个工作负载。在 Envoy 代理的上下文中,信任边界定义如下:

维度 传统模型 零信任模型(Envoy 代理)
信任锚点 IP 地址 + 网络段 SPIFFE 身份(工作负载标识)
验证时机 连接建立时(一次) 每次请求(持续验证)
流量决策 基于防火墙规则(静态) 基于身份 + 属性 + 上下文(动态)
加密范围 边界到边界(南北向) 端到端(东西向 + 南北向)
信任边界 数据中心边界 每个 Envoy 代理实例的边界
关键原则:在 Envoy 代理的零信任模型中,信任边界不是物理网络边界,而是每个 Sidecar 代理的进程边界。任何跨越此边界的流量都必须经过双向 TLS(mTLS)认证和授权策略检查。

3.2 数据平面与控制平面分离

零信任架构要求控制平面(策略决策点)与数据平面(策略执行点)严格分离。Envoy 代理作为数据平面,只负责执行;Istiod(控制平面)负责决策。这种分离带来了以下关键优势:

  • 安全隔离:控制平面的泄露不会直接暴露数据平面的流量内容。
  • 策略一致性:控制平面集中下发策略,确保所有 Envoy 代理执行相同的信任规则。
  • 可扩展性:数据平面可以水平扩展,控制平面独立管理策略和证书。
  • 最小权限:Envoy 代理仅拥有执行策略所需的权限,不持有全局密钥。
实践要点:在 Istio 中,控制平面(istiod)通过 xDS 协议(CDS、EDS、LDS、RDS、SDS)将配置和证书推送给数据平面(Envoy)。Envoy 代理从不主动查询控制平面的内部状态,只被动接收策略更新。

3.3 信任边界模型架构图

下图展示了零信任架构下,基于 Envoy 代理的信任边界模型,以及数据平面与控制平面的分离关系:

零信任信任边界模型:数据平面与控制平面分离 零信任信任边界模型:数据平面与控制平面分离 控制平面(Control Plane)— Istiod 策略决策点 (PDP) 证书颁发机构 (CA) 配置分发 (xDS) 数据平面(Data Plane)— Envoy 代理 信任边界 服务 A (工作负载) Envoy Sidecar A 服务 B (工作负载) Envoy Sidecar B mTLS 加密流量 说明:控制平面通过 xDS 协议下发策略和证书,数据平面 Envoy 代理执行策略。信任边界位于每个 Envoy 代理实例处, 所有跨边界流量必须经过 mTLS 认证和授权检查。控制平面与数据平面严格分离,确保安全隔离。

3.4 数据平面与控制平面的职责对比

为了更清晰地理解分离模型,下表对比了数据平面(Envoy)与控制平面(Istiod)在信任边界中的具体职责:

功能领域 数据平面(Envoy 代理) 控制平面(Istiod)
身份认证 执行 mTLS 握手,验证对端证书 签发 SPIFFE 证书,管理证书轮换
授权决策 执行 RBAC/ABAC 策略,允许/拒绝请求 定义并分发 AuthorizationPolicy
路由规则 根据 VirtualService/DestinationRule 转发流量 下发路由配置,管理服务发现
可观测性 生成访问日志、指标、追踪数据 聚合遥测数据,提供全局视图
密钥管理 存储并使用 TLS 证书(通过 SDS) 生成并分发密钥,管理密钥生命周期
故障恢复 执行重试、超时、熔断 监控数据平面健康状态,触发重新配置

3.5 信任边界流量验证流程

在零信任模型下,一个请求从服务 A 到服务 B 的完整信任验证流程如下:

  1. 身份获取:Envoy Sidecar A 从控制平面(Istiod)通过 SDS 获取 SPIFFE 证书。
  2. mTLS 握手:Envoy Sidecar A 与 Envoy Sidecar B 建立 mTLS 连接,双方交换证书并验证身份。
  3. 授权检查:Envoy Sidecar B 根据控制平面下发的 AuthorizationPolicy,检查请求是否满足条件(如来源身份、HTTP 方法、路径)。
  4. 策略执行:如果授权通过,请求被转发到服务 B;否则返回 403 Forbidden。
  5. 审计日志:Envoy Sidecar B 生成访问日志,包含请求身份、决策结果、时间戳,发送到控制平面或日志系统。
常见误区:不要将信任边界等同于网络防火墙规则。在零信任模型中,即使两个服务在同一个 Kubernetes 节点上,它们之间的流量也必须经过 Envoy 代理的 mTLS 和授权检查。信任边界是逻辑的、基于身份的,而不是物理的、基于网络的。

3.6 控制平面与数据平面分离的信任边界示意图

下图从另一个角度展示了控制平面与数据平面分离后,信任边界如何在不同层级发挥作用:

控制平面与数据平面分离的信任边界层级 控制平面与数据平面分离的信任边界层级 基础设施层 Kubernetes 集群 / 虚拟机 / 物理网络 — 不提供信任决策 控制平面层(Istiod) 策略决策点(PDP)— 定义信任规则、签发证书、分发配置 数据平面层(Envoy 代理) 策略执行点(PEP)— 执行 mTLS、授权、路由、可观测性 应用层(服务工作负载) 业务逻辑 — 不感知信任决策,所有信任由 Envoy 代理透明处理 信任边界 信任边界位于数据平面层(Envoy 代理),控制平面只做决策不接触流量,应用层完全透明。

3.7 信任边界模型的最佳实践

  • 最小化信任域:每个 Envoy 代理实例是一个独立的信任域,不要跨代理共享密钥。
  • 持续验证:即使 mTLS 连接已建立,每次请求都应重新进行授权检查(Envoy 的 RBAC 过滤器支持 per-request 评估)。
  • 控制平面高可用:控制平面故障不应导致数据平面立即中断;Envoy 代理会缓存最新的配置和证书。
  • 证书轮换:使用短生命周期证书(如 24 小时),并通过 SDS 自动轮换,减少密钥泄露风险。
  • 审计与监控:启用 Envoy 的访问日志和 OpenTelemetry 追踪,记录所有跨信任边界的请求。
总结:零信任架构下的信任边界模型要求将信任锚点从网络位置转移到工作负载身份,并通过数据平面与控制平面的严格分离,实现策略决策与策略执行的解耦。Envoy 代理作为数据平面,是信任边界的执行者;Istiod 作为控制平面,是信任策略的制定者。这种模型为镜像供应链中的流量验证提供了坚实的安全基础。