4. 鉴权拦截点分析：API Server 准入控制、Webhook Hook、Sidecar 注入点
在 Kubernetes 分布式事务鉴权体系中，拦截点决定了“在哪个环节、以何种粒度、对哪些请求执行鉴权检查”。错误的拦截点选择会导致鉴权绕过或性能瓶颈。本章聚焦三大核心拦截点：API Server 内置准入控制、动态 Webhook Hook 以及 Sidecar 注入点，分析其拦截能力、故障模式与恢复策略。
4.1 拦截点分层模型
Kubernetes 请求从客户端到达 etcd 的完整路径中，鉴权拦截点分布在三个层级：
| 层级 | 拦截点 | 执行时机 | 鉴权粒度 |
|---|---|---|---|
| L1 | API Server 内置准入控制 | 请求认证/授权之后，对象持久化之前 | 粗粒度（资源类型、命名空间） |
| L2 | 动态 Webhook Hook | Mutating 阶段（修改请求）或 Validating 阶段（校验请求） | 细粒度（字段级、上下文相关） |
| L3 | Sidecar 注入点 | Pod 创建时的 Mutating Webhook 回调 | 容器级（注入代理、策略执行器） |
关键原则：L1 拦截失败时，L2 可作为第二道防线；L2 超时或不可用时，L3 的 Sidecar 仍能提供运行时鉴权。三层形成纵深防御，单点故障不应导致鉴权完全失效。
4.2 API Server 内置准入控制
内置准入控制是 Kubernetes 核心组件的一部分，以插件形式编译进 kube-apiserver。它们无法被动态卸载，故障时会导致 API Server 启动失败或请求被静默拒绝。
4.2.1 关键内置准入插件
| 插件名称 | 鉴权职责 | 故障影响 |
|---|---|---|
| NamespaceLifecycle | 禁止在正在终止的命名空间中创建资源 | 命名空间 Terminating 状态下新资源创建失败 |
| NodeRestriction | 限制 kubelet 只能修改自身 Node 和绑定 Pod | kubelet 越权修改其他节点对象 |
| PodSecurity | 强制执行 Pod 安全标准（基线/受限） | 非安全 Pod 被创建，集群暴露提权风险 |
| ServiceAccount | 自动注入 default ServiceAccount 并校验挂载 | Pod 无有效身份凭证，鉴权失败 |
故障恢复要点：内置准入控制故障通常需要重启 API Server 或调整 kube-apiserver 启动参数
--enable-admission-plugins。恢复期间，建议临时启用 --disable-admission-plugins 排除故障插件，但必须评估安全降级风险。
4.3 动态 Webhook Hook
动态 Webhook 通过 MutatingWebhookConfiguration 和 ValidatingWebhookConfiguration 资源注册，允许集群管理员插入自定义鉴权逻辑。这是分布式事务鉴权拦截最灵活的扩展点，也是故障高发区。
4.3.1 Webhook 故障模式
- 超时故障：Webhook 服务响应超过 30 秒（默认 timeoutSeconds），API Server 默认行为是允许请求通过（failurePolicy: Ignore），导致鉴权绕过。
- 证书故障：Webhook 证书过期或 CA 不匹配，API Server 拒绝调用，请求被拒绝（failurePolicy: Fail）或放行（failurePolicy: Ignore）。
- 服务不可达：Webhook 后端 Pod 被驱逐或网络隔离，API Server 重试 3 次后按 failurePolicy 处理。
- 死循环：Webhook 修改对象后又触发自身 Webhook，导致无限递归，API Server 最终拒绝请求。
4.3.2 failurePolicy 策略对比
| failurePolicy | Webhook 不可用时的行为 | 适用场景 | 恢复难度 |
|---|---|---|---|
Ignore |
跳过 Webhook，请求继续 | 非关键鉴权（审计、日志） | 低（请求不中断） |
Fail |
拒绝请求，返回错误 | 关键鉴权（事务一致性校验） | 高（集群可能不可用） |
最佳实践：分布式事务鉴权的 Webhook 应使用
failurePolicy: Fail，但必须配合 timeoutSeconds: 5 和健康检查，避免 Webhook 故障导致整个集群拒绝写入。同时部署 ValidatingAdmissionPolicy 作为降级方案。
4.4 Sidecar 注入点
Sidecar 注入点位于 Pod 创建时的 Mutating Webhook 回调阶段。鉴权代理（如 Istio sidecar、自定义策略执行器）在此处被注入到 Pod 中，实现运行时请求级鉴权。这是分布式事务鉴权的最后一道防线。
4.4.1 注入点故障场景
- 注入失败：Webhook 返回错误，Pod 创建被拒绝（failurePolicy: Fail），导致工作负载无法调度。
- 注入延迟：Sidecar 容器启动慢于主容器，主容器在无鉴权代理的情况下处理请求，造成鉴权盲区。
- 注入绕过：攻击者通过
sidecar.istio.io/inject: "false"注解或直接使用原始 Pod 规范绕过注入。 - 版本不兼容：Sidecar 代理版本与集群鉴权策略不匹配，导致鉴权规则执行错误。
4.4.2 注入点故障恢复策略
| 故障类型 | 检测手段 | 恢复操作 | 恢复时间目标 |
|---|---|---|---|
| 注入失败 | Pod 事件 FailedCreate |
调整 Webhook 配置或临时关闭注入 | < 5 分钟 |
| 注入延迟 | 容器启动时间监控 | 配置 holdApplicationUntilProxyStarts: true |
< 2 分钟 |
| 注入绕过 | 审计日志 + OPA 策略校验 | 强制注入策略 + 拒绝未注入 Pod | < 10 分钟 |
| 版本不兼容 | Sidecar 版本与策略版本比对 | 回滚 Sidecar 版本或更新策略 | < 15 分钟 |
恢复原则：Sidecar 注入点故障时，优先保证工作负载可用性（临时关闭注入），再通过运行时策略（如 OPA Gatekeeper 或 Kyverno）补充鉴权，避免安全盲区长期存在。
4.5 拦截点故障恢复对比
| 拦截点 | 故障影响范围 | 恢复手段 | 恢复期间安全风险 |
|---|---|---|---|
| 内置准入控制 | 全局（API Server 级别） | 重启 API Server / 调整启动参数 | 高（插件禁用后无替代） |
| 动态 Webhook | 按资源/命名空间隔离 | 修复 Webhook 服务 / 切换 failurePolicy | 中（Ignore 策略下鉴权绕过） |
| Sidecar 注入点 | 按工作负载隔离 | 调整注入策略 / 运行时策略补充 | 低（运行时鉴权可兜底） |
理解三个拦截点的故障模式与恢复策略，是设计分布式事务鉴权高可用方案的基础。下一层将深入 Webhook 的证书管理与故障自愈机制。