📚 课程目录第3章准入控制基础

3. 准入控制基础：Kubernetes准入控制器原理、Mutating与Validating Webhook、Kyverno的Webhook注册机制

3.1 Kubernetes 准入控制（Admission Control）原理

Kubernetes 准入控制是 API Server 请求处理链中的一个关键安关。当用户或服务通过 kubectl、客户端库或 REST 调用向 API Server 发送请求时，请求必须经过 认证（Authentication） → 授权（Authorization） → 准入控制（Admission Control） 三个阶段。准入控制器位于授权之后、对象持久化到 etcd 之前，是拦截和修改请求的最后一道防线。

  核心作用：准入控制器可以 验证（Validate） 请求是否符合集群策略，也可以 变更（Mutate） 请求内容（如注入 Sidecar、设置默认标签）。只有所有准入控制器都通过，请求才会被写入 etcd。

Kubernetes 内置了多种准入控制器（如 NamespaceLifecycle、LimitRanger、PodSecurity），但内置控制器的逻辑是固定的，无法满足动态策略需求。因此，Kubernetes 提供了 动态准入控制（Dynamic Admission Control） 机制，允许集群管理员通过 Webhook 扩展准入逻辑。

3.2 Mutating 与 Validating Webhook 对比

动态准入控制通过两种 Webhook 实现：MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook。两者在请求处理链中的执行顺序和职责不同：

特性	Mutating Webhook	Validating Webhook
执行顺序	先执行（在 Validating 之前）	后执行（在 Mutating 之后）
主要职责	修改（Mutate）请求对象，如注入 Sidecar、设置默认值、添加标签	验证（Validate）请求对象是否符合策略，如检查镜像来源、资源限制
响应行为	返回 `allowed: true` 并附带修改后的 JSON Patch	返回 `allowed: true/false`，拒绝时附带错误信息
幂等性要求	必须幂等（多次调用结果一致），避免重复修改	无幂等性要求，但需保证验证逻辑正确
典型场景	自动注入 Istio Sidecar、设置 Pod 安全上下文默认值	检查镜像是否来自可信仓库、禁止特权容器

设计原则：先 Mutate 再 Validate 的顺序是经过深思熟虑的。Mutating Webhook 先修改对象，使对象进入“最终状态”，然后 Validating Webhook 再对这个最终状态进行验证。这样可以避免 Validating Webhook 验证一个“未完成”的对象，导致误判。

3.3 Webhook 配置与注册机制

在 Kubernetes 中，Webhook 的注册通过两个 API 资源完成：MutatingWebhookConfiguration 和 ValidatingWebhookConfiguration。集群管理员创建这些资源后，API Server 会自动将匹配的请求发送到指定的 Webhook 服务。

3.3.1 Webhook 配置核心字段

一个典型的 Webhook 配置包含以下关键字段：

字段路径	说明	示例值
`clientConfig.url`	Webhook 服务的 HTTPS 地址	`https://kyverno-svc.kyverno.svc:443/mutate`
`clientConfig.caBundle`	用于验证 Webhook 服务端证书的 CA 证书（Base64 编码）	`LS0tLS1CRUdJTiBDRV...==`
`rules`	匹配规则，定义哪些资源操作触发 Webhook	`apiGroups: [""], apiVersions: ["v1"], resources: ["pods"], operations: ["CREATE", "UPDATE"]`
`failurePolicy`	Webhook 不可用时的处理策略：`Fail` 或 `Ignore`	`Fail`
`sideEffects`	Webhook 是否有副作用：`None`、`NoneOnDryRun`	`None`
`timeoutSeconds`	Webhook 调用超时时间（1-30 秒）	`10`
`reinvocationPolicy`	（仅 Mutating）是否允许重新调用：`Never` 或 `IfNeeded`	`IfNeeded`

3.3.2 Kyverno 的 Webhook 注册机制

Kyverno 作为策略引擎，在启动时会自动创建和管理自己的 Webhook 配置。它通过 Leader Election 机制确保只有一个 Kyverno Pod 负责管理 Webhook 注册，避免多个 Pod 同时修改配置导致冲突。

Kyverno 的 Webhook 注册流程如下：

启动阶段：Kyverno Pod 启动后，通过 Leader Election 选举出 Leader。
生成配置：Leader 根据集群中定义的 ClusterPolicy 和 Policy 资源，自动生成对应的 MutatingWebhookConfiguration 和 ValidatingWebhookConfiguration。
动态更新：当策略被创建、更新或删除时，Kyverno 自动更新 Webhook 配置的 rules 字段，确保只匹配需要处理的资源。
证书管理：Kyverno 使用自签 CA 或用户提供的证书，自动管理 Webhook 的 TLS 证书，并通过 caBundle 字段注入到 Webhook 配置中。

注意：Kyverno 默认使用 failurePolicy: Fail，这意味着如果 Kyverno 服务不可用，所有匹配的 API 请求都会被拒绝。在生产环境中，建议为关键策略设置 failurePolicy: Ignore，或通过高可用部署（多副本）降低风险。

3.4 Webhook 通信安全与性能考量

Webhook 通信涉及 API Server 与 Webhook 服务之间的 HTTPS 调用，安全性和性能是架构设计的关键：

TLS 双向认证：API Server 作为客户端，需要验证 Webhook 服务端的证书（通过 caBundle）；Webhook 服务端也可以配置客户端证书认证，确保只有 API Server 可以调用。
超时控制：Webhook 调用有严格的超时限制（默认 10 秒，最大 30 秒）。超时后，API Server 根据 failurePolicy 决定是否允许请求通过。
请求体大小：Webhook 请求体包含完整的资源对象，对于大型资源（如包含大量数据的 ConfigMap），可能达到数 MB。建议在 Webhook 服务端设置合理的请求体大小限制。
幂等性与重试：Mutating Webhook 必须保证幂等性，因为 API Server 可能在网络故障时重试请求。Kyverno 通过 JSON Patch 的幂等操作来保证多次调用结果一致。

  性能优化提示：Webhook 的 rules 字段应尽量精确，避免匹配不必要的资源操作。例如，如果策略只关注 Pod 的 CREATE 操作，就不要匹配 UPDATE 或 DELETE，减少无效调用。Kyverno 会自动优化规则，但用户在设计策略时也应注意这一点。