2. Istio安全架构基础：AuthorizationPolicy、PeerAuthentication、RequestAuthentication的关系
在Istio服务网格中，安全访问控制由三个核心CRD（自定义资源）协同完成：AuthorizationPolicy（授权策略）、PeerAuthentication（对等认证）和RequestAuthentication（请求认证）。理解三者之间的层级关系与协作机制，是构建回滚护栏策略的前提。
2.1 三层安全模型概览
Istio的安全架构遵循“认证 → 授权”的流水线模型。认证层先验证通信双方的身份，授权层再根据身份决定是否允许请求通过。三者并非平级，而是存在明确的依赖与触发顺序。
核心原则：认证是授权的前提。如果PeerAuthentication或RequestAuthentication拒绝了请求，AuthorizationPolicy将不会被执行。
2.2 三种策略的职责与配置维度
| 策略类型 | 作用层级 | 核心职责 | 配置维度 | 生效时机 |
|---|---|---|---|---|
| PeerAuthentication | 传输层（TLS） | 控制服务间通信是否启用mTLS | 网格级别 / 命名空间级别 / 工作负载级别 | 连接建立阶段 |
| RequestAuthentication | 身份层（JWT） | 验证请求中的JWT令牌有效性 | 工作负载级别（通过selector） | 请求到达Sidecar后、授权前 |
| AuthorizationPolicy | 授权层（RBAC） | 基于身份和请求属性执行访问控制 | 网格级别 / 命名空间级别 / 工作负载级别 | 认证通过后、路由转发前 |
实战提示：在回滚护栏场景中，AuthorizationPolicy是最常被变更的对象，而PeerAuthentication和RequestAuthentication通常作为稳定的认证基线，不建议频繁修改。
2.3 三者协作的执行流程
当一个请求从客户端进入服务网格时，Envoy Sidecar代理会按照以下顺序执行安全检查：
- TLS握手阶段：PeerAuthentication决定是否要求客户端提供证书，以及是否启用mTLS。
- JWT验证阶段：如果配置了RequestAuthentication，Sidecar会提取请求中的JWT令牌，验证签名、签发者和过期时间。
- 授权决策阶段：AuthorizationPolicy根据认证结果（来源身份、JWT claims）和请求属性（路径、方法、请求头）做出允许/拒绝决策。
常见误区：很多用户认为AuthorizationPolicy可以独立工作。实际上，如果PeerAuthentication设置为DISABLE（禁用mTLS），且RequestAuthentication未配置，AuthorizationPolicy中的source.principal将无法匹配任何身份，导致策略“形同虚设”。
2.4 策略作用域与优先级
三种策略都支持在多个作用域配置，Istio会按照最精确匹配原则合并策略：
- 网格级别：通过
mesh关键字配置，影响网格内所有工作负载。 - 命名空间级别：配置在特定命名空间，影响该命名空间下所有工作负载。
- 工作负载级别：通过
selector匹配特定Pod，优先级最高。
回滚护栏关联：AuthorizationPolicy支持
action: AUDIT模式（Istio 1.18+），可以在不实际拒绝请求的情况下记录策略匹配结果。这是实现“先审计、后阻断”回滚策略的关键能力。
2.5 三者关系总结
| 对比维度 | PeerAuthentication | RequestAuthentication | AuthorizationPolicy |
|---|---|---|---|
| 安全层级 | 传输层（L4） | 身份层（L7） | 授权层（L7） |
| 验证对象 | 服务证书（SPIFFE） | JWT令牌 | 认证后的身份+请求属性 |
| 失败后果 | 连接被拒绝 | 请求被拒绝（401） | 请求被拒绝（403） |
| 变更频率 | 低（基础设施级） | 中（接入新客户端时） | 高（业务策略频繁调整） |
| 回滚关注点 | 避免误设为DISABLE导致通信中断 | 避免JWKS端点不可用导致认证失败 | 避免规则过严或过松导致业务受损 |
课程衔接：在后续章节中，我们将重点围绕AuthorizationPolicy的变更回滚展开，因为它是业务访问控制策略变更最频繁、风险最高的组件。PeerAuthentication和RequestAuthentication将作为“认证基线”在回滚护栏中扮演校验前置条件的角色。