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 过滤器在请求处理管道中的位置及其决策流程:
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 模式的工作流程:
- 策略部署: 将新策略配置为
action: LOG,并附加到 RBAC 过滤器中。 - 请求匹配: 每个请求都会经过 Shadow 策略的匹配计算。
- 日志输出: 匹配结果(ALLOW/DENY)被写入 Envoy 的访问日志或统计指标,但请求的实际处理不受影响。
- 结果分析: 通过日志分析,判断新策略是否过松(误放行)或过严(误拒绝)。
- 正式切换: 确认策略准确后,将
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 收紧”的策略生命周期管理流程。