1. 课程导论：Envoy在云原生架构中的角色、访问控制策略的重要性、运行基线核验的概念与价值
1.1 Envoy 在云原生架构中的核心角色
在云原生生态中，Envoy 已从单纯的代理演变为服务网格（Service Mesh）的数据平面标准组件。它作为 sidecar 代理与每个服务实例一同部署，接管所有进出流量，成为基础设施层的关键通信枢纽。
| 角色维度 | 具体职责 | 技术实现 |
|---|---|---|
| 流量代理 | L3/L4/L7 流量转发、负载均衡、健康检查 | Listener/Cluster/Routes 动态配置 |
| 可观测性 | 全链路追踪、访问日志、指标暴露 | OpenTelemetry、StatsD、Access Log |
| 安全执行点 | TLS 终止、身份认证、授权策略执行 | SDS、RBAC、ExtAuthz 过滤器 |
| 协议转换 | HTTP/1.1 ↔ HTTP/2 ↔ gRPC 桥接 | Codec 过滤器、协议嗅探 |
| 故障注入与韧性 | 超时、重试、熔断、限流 | Circuit Breaker、Rate Limit 过滤器 |
关键认知： Envoy 是云原生架构中唯一同时具备流量管理、安全策略、可观测性三大能力的统一代理层，其 xDS 动态配置协议使其成为控制平面（如 Istio）与数据平面之间的标准接口。
1.2 访问控制策略的重要性
云原生环境中的访问控制面临三大挑战：边界模糊（传统防火墙失效）、动态拓扑（Pod 频繁启停）、零信任要求（默认拒绝所有流量）。Envoy 通过以下机制构建多层访问控制防线：
- 传输层安全（TLS/mTLS）： 强制服务间双向认证，防止中间人攻击。
- RBAC 过滤器： 基于来源身份（SPIFFE）、HTTP 方法、路径等属性进行细粒度授权。
- 外部授权（ExtAuthz）： 对接 OPA、Keto 等策略引擎，实现动态策略决策。
- 速率限制（Rate Limit）： 防止暴力破解和 DDoS 攻击。
实践建议： 在 Istio 中，AuthorizationPolicy CRD 直接映射到 Envoy RBAC 过滤器，建议从“默认拒绝 + 白名单”模式开始，逐步开放必要权限。
1.3 运行基线核验的概念与价值
运行基线核验是指在生产环境中持续验证实际运行状态是否与预期安全基线一致的过程。它不同于一次性合规扫描，而是作为 CI/CD 流水线和运行时监控的组成部分，形成闭环反馈。
| 核验维度 | 基线内容示例 | 核验方法 |
|---|---|---|
| 配置基线 | Envoy 必须启用 mTLS、禁止明文端口 | xDS 配置审计、静态配置校验 |
| 策略基线 | 所有跨命名空间流量必须显式授权 | AuthorizationPolicy 覆盖率检查 |
| 运行时基线 | Sidecar 注入率 100%、无异常重启 | Prometheus 指标 + 准入 Webhook |
| 依赖基线 | Envoy 版本 ≥ 1.28、无已知 CVE | SBOM 扫描 + 版本比对 |
常见误区： 基线核验不是一次性的“合规快照”，而是需要与 GitOps 工作流集成——当基线被违反时，应自动触发告警、回滚或阻断操作，而非仅生成报告。
1.4 集成部署的价值总结
将 Envoy 访问控制策略与运行基线核验集成部署，能够实现以下核心收益：
- 策略即代码： 访问控制策略与基线定义统一存储在 Git 仓库，支持版本管理和审计。
- 持续合规： 每次部署变更自动触发基线核验，防止配置漂移。
- 故障自愈： 当运行时状态偏离基线时，Envoy 热重启或策略回滚可自动执行。
- 可审计性： 所有策略变更和核验结果记录为不可篡改的审计日志。