4. 准入控制基础：Kubernetes准入控制器原理、AdmissionReview、Webhook配置、Kyverno作为动态准入控制器

Kubernetes 准入控制是集群安全与策略执行的“最后一公里”。任何对集群资源的创建、更新、删除操作，在通过认证与授权后，都必须经过准入控制器的审查。本章将深入剖析准入控制器的核心原理、AdmissionReview 请求/响应结构、Webhook 配置方式，并阐明 Kyverno 如何作为动态准入控制器运行。

4.1 Kubernetes 准入控制器原理

准入控制器是一段拦截 API Server 请求的代码，它在请求被持久化到 etcd 之前执行。根据作用阶段，准入控制器分为两类：

类型	执行时机	典型用途
Mutating（变更）	先于 Validating 执行	注入 Sidecar、设置默认值、修改资源字段
Validating（验证）	在 Mutating 之后、持久化之前	校验资源合规性、拒绝非法配置

整个请求生命周期如下：

1. 认证：验证请求者身份（证书、、用户名/密码）。
2. 授权：检查请求者是否拥有操作资源的权限（RBAC）。
3. 准入控制：依次执行所有配置的准入控制器插件（包括内置插件和 Webhook）。
4. 持久化：将最终资源对象写入 etcd。

4.2 AdmissionReview 请求与响应结构

Webhook 准入控制器通过 HTTP 回调与 API Server 通信，通信数据格式为 AdmissionReview。API Server 发送 AdmissionReview 请求，Webhook 服务返回 AdmissionReview 响应。

4.2.1 请求结构

{
  "apiVersion": "admission.k8s.io/v1",
  "kind": "AdmissionReview",
  "request": {
    "uid": "12345678-1234-1234-1234-123456789abc",
    "kind": {"group": "", "version": "v1", "kind": "Pod"},
    "resource": {"group": "", "version": "v1", "resource": "pods"},
    "namespace": "default",
    "operation": "CREATE",
    "userInfo": {"username": "admin", "uid": "user-uid", "groups": ["system:masters"]},
    "object": { ... },           // 请求的资源对象（完整 JSON）
    "oldObject": null,           // 仅 UPDATE/DELETE 时有值
    "dryRun": false
  }
}

字段	说明
uid	请求唯一标识，响应中必须原样返回
operation	操作类型：CREATE / UPDATE / DELETE / CONNECT
object	请求创建或更新后的资源对象
oldObject	更新或删除前的资源对象
dryRun	是否为干运行请求

4.2.2 响应结构

{
  "apiVersion": "admission.k8s.io/v1",
  "kind": "AdmissionReview",
  "response": {
    "uid": "12345678-1234-1234-1234-123456789abc",
    "allowed": true,
    "status": {"code": 200, "message": "允许通过"},
    "patch": "W3sib3AiOiAiYWRkIiwgInBhdGgiOiAiL3NwZWMvY29udGFpbmVycy8tIiwgInZhbHVlIjogeyJpbWFnZSI6ICJuZ2lueCJ9fV0=",
    "patchType": "JSONPatch"
  }
}

字段	说明
allowed	是否允许请求通过
status.code	HTTP 状态码，200 表示允许，403 表示拒绝
patch	Base64 编码的 JSON Patch（仅 Mutating Webhook）
patchType	补丁类型，目前仅支持 JSONPatch

4.3 Webhook 配置：ValidatingWebhookConfiguration 与 MutatingWebhookConfiguration

Kubernetes 通过两种资源对象来注册 Webhook 准入控制器：

• ValidatingWebhookConfiguration：注册验证性质的 Webhook。
• MutatingWebhookConfiguration：注册变更性质的 Webhook。

4.3.1 配置示例

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: "pod-validator.example.com"
webhooks:
- name: "pod-validator.example.com"
  clientConfig:
    service:
      namespace: "kyverno"
      name: "kyverno-svc"
      path: "/validate"
    caBundle: "LS0tLS1CRUdJTiBDRV...=="
  rules:
  - operations: ["CREATE", "UPDATE"]
    apiGroups: [""]
    apiVersions: ["v1"]
    resources: ["pods"]
  admissionReviewVersions: ["v1"]
  sideEffects: None
  timeoutSeconds: 10

配置字段	说明
clientConfig	Webhook 服务的访问地址（Service 或 URL）及 CA 证书
rules	匹配规则：操作类型、API 组、版本、资源
admissionReviewVersions	支持的 AdmissionReview 版本，推荐 v1
sideEffects	副作用声明：None、NoneOnDryRun 等
timeoutSeconds	超时时间，默认 30 秒，建议 ≤10 秒

4.4 Kyverno 作为动态准入控制器

Kyverno 是一个为 Kubernetes 设计的策略引擎，以动态准入控制器的方式运行。它通过注册一个 MutatingWebhookConfiguration 和一个 ValidatingWebhookConfiguration 来拦截所有匹配的资源请求。

4.4.1 Kyverno 的架构组件

4.4.2 Kyverno 的策略执行流程

1. 注册 Webhook：Kyverno 启动时自动创建 MutatingWebhookConfiguration 和 ValidatingWebhookConfiguration，指向自身的 Service。
2. 接收请求：API Server 将匹配规则的请求封装为 AdmissionReview，发送给 Kyverno Service。
3. 策略匹配：Kyverno 引擎根据请求的 kind、operation、namespace 等信息，匹配已定义的 ClusterPolicy 或 Policy。
4. 策略执行：执行匹配策略的 validate、mutate、generate 或 verifyImages 规则。
5. 返回响应：构造 AdmissionReview 响应，设置 allowed 和可选的 patch，返回给 API Server。

4.5 本章小结

知识点	核心要点
准入控制器分类	Mutating（变更）先执行，Validating（验证）后执行
AdmissionReview	请求包含 object/oldObject，响应必须返回 uid 和 allowed
Webhook 配置	ValidatingWebhookConfiguration / MutatingWebhookConfiguration，需配置 caBundle
Kyverno 角色	动态准入控制器，自动管理 Webhook 配置，通过策略规则实现准入控制