4. 准入控制器原理：Admission Webhook、Mutating与Validating模式

Kubernetes 准入控制器（Admission Controller）是 API 服务器请求处理链中的一道关键安全闸门。它位于请求经过认证（Authentication）和授权（Authorization）之后、对象被持久化到 etcd 之前。准入控制器可以拦截、修改甚至拒绝请求，是实现策略自动化、安全基线强制和配置校验的核心机制。

4.1 准入控制器的位置与作用

在 Kubernetes API 请求的生命周期中，准入控制阶段是唯一能够同时拦截创建（CREATE）、更新（UPDATE）和删除（DELETE）操作，并且可以修改请求内容的扩展点。其基本流程如下：

1. 认证：验证请求者身份（TLS 证书、、用户名/密码）。
2. 授权：判断请求者是否有权限执行操作（RBAC、ABAC）。
3. 准入控制：执行一系列准入控制器插件，可能修改或拒绝请求。
4. 持久化：将最终对象写入 etcd。

4.2 Admission Webhook 架构

Kubernetes 内置了数十种准入控制器插件（如 NamespaceLifecycle、LimitRanger、PodSecurity），但用户自定义策略最灵活的方式是使用 Admission Webhook。Webhook 允许用户将准入决策委托给外部 HTTP 回调服务。

Admission Webhook 分为两种类型：

4.3 Mutating 与 Validating 模式对比

两种模式在请求处理链中的位置和职责有明确区分。以下从多个维度进行对比：

4.4 Webhook 配置与请求流程

配置一个 Admission Webhook 需要两个核心资源：MutatingWebhookConfiguration 和 ValidatingWebhookConfiguration。以下是一个典型的 Validating Webhook 配置示例：

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: "secret-rotation-validator.example.com"
webhooks:
- name: "secret-rotation-validator.example.com"
  clientConfig:
    service:
      namespace: "webhook-system"
      name: "webhook-service"
      path: "/validate"
    caBundle: "LS0tLS1CRUdJTiBDRV...=="  # 由证书管理工具注入
  rules:
  - operations: ["CREATE", "UPDATE"]
    apiGroups: [""]
    apiVersions: ["v1"]
    resources: ["secrets"]
  failurePolicy: Fail
  sideEffects: None
  admissionReviewVersions: ["v1"]
  timeoutSeconds: 10
  objectSelector:
    matchLabels:
      rotation-enabled: "true"

4.5 请求处理流程（SVG 架构图）

下图展示了 Mutating 和 Validating Webhook 在 API 请求处理链中的完整协作流程：

4.6 Webhook 的幂等性与副作用控制

在 Secrets 轮换场景中，Mutating Webhook 的幂等性尤为重要。如果 Webhook 在每次请求中都向 Pod 注入相同的 Secret 版本标签，但注入逻辑没有检查标签是否已存在，可能导致重复注入或 Patch 冲突。

幂等性设计原则：

• 检查再修改：在注入前检查对象是否已经包含目标修改，避免重复 Patch。
• 使用 JSON Patch 的 test 操作：在 Patch 中包含条件判断，确保只在特定条件下执行修改。
• 避免副作用：Webhook 处理程序不应修改外部状态（如写入数据库、调用外部 API），除非这些操作本身是幂等的。

4.7 两种模式的协同工作（SVG 时序图）

在 Secrets 轮换自动化策略中，Mutating 和 Validating Webhook 通常协同工作。下图展示了它们在一个完整的 Secrets 轮换请求中的时序关系：

4.8 生产环境注意事项

• 超时设置：Webhook 默认超时时间为 10 秒，建议根据业务复杂度设置为 5-30 秒。超时会导致请求失败，影响集群可用性。
• 失败策略：生产环境建议将 failurePolicy 设置为 Fail，避免 Webhook 不可用时绕过安全策略。仅在非关键校验场景（如审计日志）可使用 Ignore。
• 对象选择器：使用 objectSelector 和 namespaceSelector 缩小 Webhook 作用范围，减少不必要的调用，提升性能。
• Sidecar 注入：在 Secrets 轮换场景中，Mutating Webhook 常用于注入 Sidecar 容器（如 reloader），监听 Secret 变化并触发 Pod 内进程重载。
• 审计日志：Validating Webhook 可以记录所有被拒绝的请求，用于安全审计和策略调优。