2. Kyverno 基础架构：组件、工作流程与策略引擎原理

理解 Kyverno 的基础架构是编写精准策略的前提。本章将拆解 Kyverno 的核心组件、准入控制器的完整工作流程，以及策略引擎如何评估和生成策略结果。掌握这些底层机制，能帮助你在面对复杂的安全基线场景时，快速定位策略失败原因并优化规则。

2.1 Kyverno 核心组件

Kyverno 以 Kubernetes 原生方式部署，主要包含以下三个关键组件，它们协同完成策略的加载、监听与执行。

2.2 准入控制器工作流程

当用户通过 kubectl apply 或 API 调用创建/更新资源时，Kyverno 的准入流程按以下步骤执行：

1. API Server 接收请求：请求进入 Kubernetes API Server 的准入控制链。
2. MutatingWebhookConfiguration 触发：Kyverno 注册的变更 Webhook 被调用，请求被转发至 Kyverno Admission Service。
3. 策略匹配与变量注入：Kyverno 根据资源类型、标签、命名空间等匹配策略；若策略包含 preconditions，则先评估条件是否满足。
4. 执行 mutate 规则：对匹配的资源进行 JSON 补丁操作（如自动添加安全上下文、只读根文件系统等）。
5. ValidatingWebhookConfiguration 触发：变更完成后，验证 Webhook 被调用，再次将请求转发至 Kyverno。
6. 执行 validate 规则：策略引擎对资源进行模式匹配或条件判断，生成 pass / fail 结果。
7. 返回准入响应：Kyverno 将 AdmissionResponse 返回给 API Server，允许或拒绝资源创建/更新。

2.3 策略引擎原理

Kyverno 的策略引擎并非简单的规则匹配，它包含一套完整的评估生命周期。理解引擎的内部机制，有助于编写更高效、更精确的安全策略。

2.3.1 策略评估生命周期

• 加载阶段：Kyverno 启动时从集群中加载所有 ClusterPolicy 和 Policy 资源，构建策略索引。
• 匹配阶段：根据准入请求中的资源类型（Kind）、API 版本、命名空间、标签选择器（match / exclude）进行第一层过滤。
• 预处理阶段：解析策略中的 preconditions，使用 JMESPath 表达式从资源对象中提取字段，判断是否满足前置条件。
• 执行阶段：按规则类型（mutate / validate / generate）执行具体逻辑。对于 validate 规则，支持 pattern（模式匹配）、anyPattern（任一模式）、deny（条件拒绝）三种模式。
• 结果聚合阶段：将多条规则的评估结果聚合为最终的 AdmissionResponse。若任一 validate 规则失败，则整个请求被拒绝。

2.3.2 规则类型对比

2.4 策略引擎的变量与上下文

Kyverno 策略引擎在评估时，会构建一个丰富的上下文对象，供 JMESPath 表达式引用。以下是安全基线策略中最常用的上下文变量：

• request.object：正在被创建或更新的资源对象。
• request.oldObject：更新操作前的资源对象（用于检测变更）。
• request.namespace：资源所属的命名空间。
• request.userInfo：发起请求的用户信息（用于 RBAC 审计）。
• images：解析后的容器镜像列表，包含 registry、repository、tag 和 digest。

2.5 安全基线水位下的架构要点总结

• 组件冗余：Admission Controller 建议至少 2 副本，避免单点故障导致集群不可用。
• Webhook 超时：Kubernetes 默认 Webhook 超时为 30 秒，复杂策略应优化 JMESPath 表达式，避免超时导致请求被拒绝。
• 策略顺序：mutate 规则先执行，可用于自动修复低风险配置；validate 规则后执行，用于拦截高风险变更。
• 审计模式：在安全基线水位上线初期，建议将 validate 规则设置为 audit 模式（不拒绝请求，仅记录报告），验证策略准确性后再切换为 enforce 模式。