📚 课程目录第4章准入控制原理

4. 准入控制原理：Admission Webhook（Mutating & Validating）、Webhook 配置、证书管理

Kubernetes 准入控制（Admission Control）是 API Server 在对象持久化之前的一道关键安全与策略防线。当 Fluent Bit 版本漂移校验需要拦截 Pod 创建或更新请求时，我们依赖 Admission Webhook 机制将校验逻辑外挂到自定义服务中。本章深入剖析 Mutating 与 Validating 两种 Webhook 的工作差异、Webhook 配置的 YAML 结构以及证书管理的核心要点。

4.1 准入控制阶段与 Webhook 定位

Kubernetes API 请求处理流程中，准入控制位于认证（Authentication）和授权（Authorization）之后，对象持久化（etcd）之前。Webhook 是动态的准入控制器，允许集群管理员注册外部 HTTPS 端点来修改或验证请求。

  关键路径： 认证 → 授权 → Admission（MutatingWebhook → Object Validation → ValidatingWebhook）→ 持久化

4.2 Mutating 与 Validating Webhook 对比

两种 Webhook 在准入控制链中扮演不同角色，理解其差异是正确设计版本漂移校验服务的前提。

对比维度	MutatingWebhook	ValidatingWebhook
执行顺序	先执行（在对象验证之前）	后执行（在对象验证之后）
核心能力	修改（Mutate）请求对象，如注入、替换、补全字段	验证（Validate）请求对象，通过/拒绝请求
对 Fluent Bit 漂移场景	自动修正镜像版本为允许列表中的版本	拒绝包含非预期版本的 Pod 创建请求
响应要求	返回 JSON Patch 或修改后的对象	返回 allowed: true/false 及拒绝原因
幂等性要求	必须幂等，避免重复修改	通常幂等，但需注意状态依赖

最佳实践： 在 Fluent Bit 版本漂移校验中，推荐组合使用 MutatingWebhook 自动修正 + ValidatingWebhook 兜底拒绝，形成“修正优先、拒绝兜底”的双层防护。

4.3 Webhook 配置详解

Webhook 配置通过 MutatingWebhookConfiguration 和 ValidatingWebhookConfiguration 资源定义。以下是一个用于 Fluent Bit 版本校验的 ValidatingWebhook 配置示例：

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: fluentbit-version-validator
webhooks:
- name: fluentbit-version.validator.example.com
  clientConfig:
    service:
      name: fluentbit-webhook-svc
      namespace: webhook-system
      path: /validate
    caBundle: <base64-encoded-ca-cert>
  rules:
  - operations: ["CREATE", "UPDATE"]
    apiGroups: [""]
    apiVersions: ["v1"]
    resources: ["pods"]
    scope: "Namespaced"
  failurePolicy: Fail
  matchPolicy: Equivalent
  sideEffects: None
  admissionReviewVersions: ["v1"]
  timeoutSeconds: 10
  objectSelector:
    matchLabels:
      app: fluent-bit
  namespaceSelector:
    matchLabels:
      webhook-enabled: "true"

配置字段关键说明：

clientConfig：定义 Webhook 服务的访问地址（Service 或 URL）以及用于 TLS 握手的 CA 证书。
rules：声明拦截哪些操作、资源、API 版本。本例拦截 Pod 的 CREATE 和 UPDATE 操作。
failurePolicy：当 Webhook 服务不可达时的行为——Fail 表示拒绝请求，Ignore 表示允许请求继续。
sideEffects：声明 Webhook 是否产生副作用，None 表示无副作用，是推荐值。
objectSelector / namespaceSelector：通过标签选择器缩小 Webhook 生效范围，避免不必要的调用。

4.4 证书管理

Admission Webhook 要求服务端必须使用 HTTPS，且客户端（API Server）需要验证服务端证书的合法性。证书管理涉及三个核心环节：

CA 证书生成：集群内部或外部 CA 签发根证书，CA 证书的 Base64 编码填入 Webhook 配置的 caBundle 字段。
服务端证书签发：为 Webhook 服务签发 TLS 证书，Common Name (CN) 或 Subject Alternative Names (SAN) 必须匹配服务访问地址（如 Service DNS 名称）。
证书轮换：证书有有效期，需在过期前更新。推荐使用 cert-manager 自动管理证书生命周期。

4.5 证书管理常见问题与避坑

证书 SAN 不匹配：如果 Webhook 通过 Service 引用，证书 SAN 必须包含 <service-name>.<namespace>.svc 或通配符。
caBundle 更新滞后：CA 证书轮换后，必须同步更新所有 Webhook 配置中的 caBundle，否则 API Server 将无法验证服务端证书。
证书过期导致 Webhook 失效：设置证书有效期监控和自动轮换策略，避免生产环境准入控制突然中断。
自签名证书不被信任：测试环境可使用自签名证书，但生产环境建议使用集群内部 CA 或企业 PKI 体系。

注意： 在 Fluent Bit 版本漂移校验场景中，Webhook 服务的高可用和证书健康状态直接影响集群的 Pod 创建流程。建议将证书监控纳入集群可观测性体系，并设置 failurePolicy: Fail 以确保策略强制生效。