2. Kyverno 架构解析：组件架构、Webhook 工作原理、策略引擎执行流程与资源变化监听机制
Kyverno 作为云原生场景下专为 Kubernetes 设计的策略引擎，其架构设计紧密围绕 Kubernetes 原生的准入控制机制与声明式资源管理模型。理解其组件构成、Webhook 交互流程、策略评估引擎以及资源变化监听机制，是进行安全权限评审与策略调优的基础。本章将从这四个维度进行深度拆解。
2.1 Kyverno 组件架构
Kyverno 采用无额外存储后端的轻量架构，所有策略与配置均以标准的 Kubernetes CRD（Custom Resource Definition）形式存储于 etcd 中。其核心组件包括以下三个主要部分：
| 组件名称 | 部署形态 | 核心职责 |
|---|---|---|
| Kyverno Admission Controller | Deployment（通常 2 副本） | 处理 MutatingWebhookConfiguration 与 ValidatingWebhookConfiguration 回调；执行策略匹配与引擎调用；返回准入响应。 |
| Kyverno Cleanup Controller | Deployment（可选，1 副本） | 管理 CleanupPolicy 资源，按时间或条件清理集群中的过期资源。 |
| Kyverno Reports Controller | Deployment（1 副本） | 生成并维护 PolicyReport 与 ClusterPolicyReport，记录策略执行历史与合规状态。 |
架构要点： Kyverno 不依赖外部数据库或 Sidecar 组件。所有策略（Policy / ClusterPolicy）与绑定规则（PolicyBinding）均以 CRD 形式存在，天然具备 Kubernetes 原生的声明式管理与版本控制能力。
下图展示了 Kyverno 各组件的部署关系及其与 Kubernetes API Server 的交互边界：
2.2 Webhook 工作原理
Kyverno 通过注册 Kubernetes 的动态准入 Webhook 实现策略拦截。其工作流程严格遵循 Kubernetes 准入控制链的规范：
- Webhook 注册： Kyverno 启动时，向 API Server 注册
MutatingWebhookConfiguration与ValidatingWebhookConfiguration，声明需要拦截的资源类型（如 Pod、Deployment、Service 等）与操作（CREATE、UPDATE、DELETE）。 - 请求拦截： 当客户端（kubectl、控制器等）向 API Server 发送资源变更请求时，API Server 根据 Webhook 配置，将请求以
AdmissionReview对象的形式发送至 Kyverno 的 Service 端点。 - 并行处理： Kyverno 的 Admission Controller 接收请求后，并行执行所有匹配的策略。变更多个策略时，Kyverno 会合并所有 Mutation 补丁（JSON Patch），确保最终对象的完整性。
- 响应返回： Kyverno 将准入响应（允许/拒绝/补丁）封装为
AdmissionReview返回给 API Server。API Server 根据响应决定是否持久化资源对象。
关键安全考量： Webhook 的超时设置（默认 30 秒）与失败策略（
failurePolicy: Fail 或 Ignore）直接影响集群的可用性。在安全评审中，应检查关键策略是否设置为 failurePolicy: Fail，避免因 Kyverno 组件故障导致安全策略被绕过。
2.3 策略引擎执行流程
Kyverno 的策略引擎是核心决策单元，其执行流程可抽象为以下五个阶段：
| 阶段 | 输入 | 处理逻辑 | 输出 |
|---|---|---|---|
| 1. 策略匹配 | AdmissionReview + 集群中所有 Policy/ClusterPolicy | 根据资源类型（kind）、操作（operations）、命名空间（namespace）等标签选择器过滤策略 | 匹配的策略列表 |
| 2. 变量解析 | 匹配的策略规则 + 请求对象 + 集群上下文 | 解析策略中的 JMESPath 表达式、{{ request.object }}、{{ serviceAccountName }} 等变量 |
解析后的规则条件与补丁模板 |
| 3. 条件评估 | 解析后的规则条件 | 执行 anyPattern / allPattern 逻辑运算，检查资源字段是否符合预期 |
条件满足 / 不满足 |
| 4. 动作执行 | 条件评估结果 + 规则定义的动作 | 生成 JSON Patch（Mutating）或构造拒绝消息（Validating） | 补丁列表 / 拒绝原因 |
| 5. 审计与报告 | 执行结果 + 资源对象 | 异步生成 PolicyReport 记录，标记策略执行状态（PASS / FAIL / ERROR） | PolicyReport 资源 |
下图展示了策略引擎从接收到请求到生成响应的完整执行流水线：
2.4 资源变化监听机制
Kyverno 不仅通过 Webhook 被动响应资源变更，还通过 Kubernetes Informer 机制主动监听资源变化，以支持策略缓存更新、报告生成与清理策略触发。其监听机制包含以下三个层次：
- 策略资源监听： Kyverno 使用 Informer 监听
Policy与ClusterPolicyCRD 的变化。当策略被创建、更新或删除时，Admission Controller 会动态更新本地策略缓存，无需重启 Pod。 - Webhook 配置监听： Kyverno 监听
MutatingWebhookConfiguration与ValidatingWebhookConfiguration资源。当集群管理员手动修改 Webhook 配置时，Kyverno 会检测差异并尝试修复，确保 Webhook 配置与当前策略一致。 - 资源报告监听： Reports Controller 监听所有受策略影响的资源类型（如 Pod、Namespace 等），结合策略执行结果生成
PolicyReport。该报告支持离线审计与合规仪表盘展示。
安全评审提示： 资源变化监听机制依赖于 Kyverno 的 RBAC 权限。在安全评审中，必须检查 Kyverno 的 ClusterRole 是否遵循最小权限原则。例如，如果策略仅需要验证 Pod 的
securityContext，则不应授予对 Secrets 或 ConfigMaps 的 get / list / watch 权限。过度授权可能导致敏感信息通过策略日志或报告泄露。
下表总结了三种监听机制的关键差异：
| 监听类型 | 监听对象 | 触发动作 | 影响范围 |
|---|---|---|---|
| 策略监听 | Policy / ClusterPolicy | 更新本地策略缓存 | Admission Controller 策略匹配行为 |
| Webhook 配置监听 | MutatingWebhookConfiguration / ValidatingWebhookConfiguration | 修复 Webhook 配置与策略一致性 | API Server 的准入拦截行为 |
| 资源报告监听 | 受策略影响的资源类型 | 生成 / 更新 PolicyReport | 审计与合规状态 |