4. Envoy 访问控制基础:RBAC 过滤器原理、Action(ALLOW/DENY)、Shadow 模式

Envoy 的 RBAC(Role-Based Access Control,基于角色的访问控制)过滤器是构建零信任网络与云原生运行基线核验的核心组件。它允许运维人员根据请求的源、目标、路径、方法等属性,定义精细化的访问策略。本章将深入解析 RBAC 过滤器的内部原理、Action 的 ALLOW/DENY 语义以及极具实用价值的 Shadow 模式。

4.1 RBAC 过滤器原理与核心数据结构

RBAC 过滤器在 Envoy 的 HTTP 连接管理器(HCM)或网络过滤器链中工作,其核心逻辑基于 主体(Principal) 与 权限(Permission) 的匹配。过滤器会遍历规则列表,根据 Action 类型决定请求的最终命运。

核心概念: RBAC 规则由 action、policies 组成。每个 policy 包含一组 permissions(匹配请求特征)和一组 principals(匹配请求来源或身份)。

下图展示了 RBAC 过滤器在请求处理管道中的位置及其决策流程:

Envoy RBAC 过滤器决策流程 入站请求 提取属性 策略匹配引擎 Action 判定 ALLOW 放行 DENY 拒绝 Shadow 日志/审计 说明:Shadow 模式下请求始终被放行,但会记录匹配结果用于审计与策略验证。

4.2 Action 语义:ALLOW 与 DENY

RBAC 过滤器的 action 字段决定了策略的最终效果。Envoy 支持两种标准 Action 和一种特殊模式:

Action 类型 枚举值 行为描述 典型使用场景
ALLOW ALLOW 匹配策略的请求被放行;未匹配任何 ALLOW 策略的请求默认被拒绝。 白名单模式:只允许特定服务或用户访问。
DENY DENY 匹配策略的请求被拒绝;未匹配任何 DENY 策略的请求默认被放行。 黑名单模式:禁止已知恶意 IP 或路径。
LOG(Shadow 模式) LOG 匹配策略的请求被记录日志,但请求本身始终被放行。 策略预演、审计、灰度验证。
最佳实践: 在云原生基线核验中,推荐优先使用 ALLOW 模式构建最小权限策略。将 DENY 用于紧急阻断或已知威胁的快速响应。

4.3 Shadow 模式:无风险策略验证

Shadow 模式(即 action: LOG)是 RBAC 过滤器中最具实用价值的功能之一。它允许运维人员在不影响生产流量的前提下,验证新策略的有效性。

Shadow 模式的工作流程:

  1. 策略部署: 将新策略配置为 action: LOG,并附加到 RBAC 过滤器中。
  2. 请求匹配: 每个请求都会经过 Shadow 策略的匹配计算。
  3. 日志输出: 匹配结果(ALLOW/DENY)被写入 Envoy 的访问日志或统计指标,但请求的实际处理不受影响。
  4. 结果分析: 通过日志分析,判断新策略是否过松(误放行)或过严(误拒绝)。
  5. 正式切换: 确认策略准确后,将 action 改为 ALLOW 或 DENY 并重新部署。
注意: Shadow 模式会增加一定的 CPU 开销(策略匹配计算),但不会增加请求延迟,因为匹配过程是同步的且不阻塞转发。建议在低峰期进行大规模策略验证。

4.4 策略配置示例与字段解析

以下是一个完整的 RBAC 策略配置示例,展示了 ALLOW 与 Shadow 模式的组合使用:

# 示例:Envoy RBAC 过滤器配置(YAML 格式)
filter_chains:
- filters:
  - name: envoy.filters.http.rbac
    typed_config:
      "@type": type.googleapis.com/envoy.extensions.filters.http.rbac.v3.RBAC
      rules:
        action: ALLOW
        policies:
          # 策略1:允许 admin 服务访问 /admin 路径
          admin_access:
            permissions:
              - url_path:
                  path: { prefix: "/admin" }
            principals:
              - metadata:
                  filter: "envoy.filters.http.jwt_authn"
                  path:
                    - key: "payload"
                    - key: "role"
                  value: { exact: "admin" }
          # 策略2:允许内部服务访问 /api/v1
          internal_api:
            permissions:
              - url_path:
                  path: { prefix: "/api/v1" }
            principals:
              - remote_ip: { address_prefix: "10.0.0.0", prefix_len: 8 }
      # Shadow 模式:记录所有对 /api/v2 的访问尝试
      shadow_rules:
        action: LOG
        policies:
          shadow_api_v2:
            permissions:
              - url_path:
                  path: { prefix: "/api/v2" }
            principals:
              - any: true
      stat_prefix: "rbac_http"

关键字段说明:

字段 类型 说明
rules RBAC 主规则,决定请求的最终放行/拒绝。
shadow_rules RBAC 影子规则,仅用于日志记录,不影响请求。
permissions 列表 匹配请求特征(路径、方法、头等)。
principals 列表 匹配请求来源(IP、JWT 声明、证书等)。
any: true 布尔 匹配任意主体或权限,常用于 Shadow 模式的通配。

4.5 与云原生基线核验的集成点

RBAC 过滤器是云原生运行基线核验的关键执行点。以下表格总结了集成场景:

基线要求 RBAC 实现方式 推荐 Action
禁止外部访问管理接口 匹配 /admin 路径 + 非内网 IP DENY
仅允许认证用户调用写 API 匹配 POST/PUT/DELETE 方法 + JWT 角色 ALLOW
灰度验证新 API 策略 匹配新 API 路径 + Shadow 模式 LOG
审计所有跨命名空间调用 匹配源 IP 非本命名空间 CIDR LOG(配合审计日志)
关键结论: RBAC 过滤器的 ALLOW/DENY 提供了强制的访问控制能力,而 Shadow 模式则为策略变更提供了安全垫。在云原生基线核验中,建议采用“先 Shadow 验证,后 ALLOW 收紧”的策略生命周期管理流程。