核心分析¶

项目定位：Kyverno 以 Kubernetes 原生、声明式 policy-as-code 的方式，解决在集群中把安全、合规与运维规则以可审计、可自动化的形式施行的问题。

技术分析¶

• 实现思路：策略以 CRD（YAML）定义，运行在 admission webhook（实时 validate/mutate）与后台控制器（background scan/generate/cleanup）两端。
• 覆盖范围：既能在资源创建/更新时阻断或改写请求，也能对已存在资源做周期性评估与修复。
• 供应链能力：内置 verifyImage 支持镜像签名验证，与 Cosign/Sigstore 等集成，弥补镜像供应链校验缺口。

实用建议¶

1. 快速上手：使用 README 的 Quick Start 与内置策略库作为起点，将策略以 Git 管理并采用 GitOps 流程逐步推广。
2. 分阶段启用：先以 dry-run（审计模式）验证策略影响，再切换到阻断模式，避免误杀流量。
3. 范围限定：用 namespace/label selectors 精确控制策略作用域，降低误触风险。

注意事项：策略为集群级功能，需妥善配置 RBAC 与 webhook 高可用，避免因权限或 webhook 可用性影响集群操作。

总结：Kyverno 的核心价值在于把策略资源化并在 admission 与后台两端一致执行，从而为平台、安全与开发团队提供一套无需新语言、易纳入 GitOps 的集群治理方案。

核心分析¶

问题识别：为何把策略实现为 CRD 并使用 admission webhook + 控制器模式？

技术分析¶

• CRD 的作用：把策略当作 Kubernetes 资源存储，享受 API 版本化、审计日志、RBAC 与 kubectl 管理能力，从而把策略纳入集群运维常规。
• Admission 的优势：在对象创建/更新的关键路径上实现实时 validate/mutate，能够立即阻断不合规资源，减少事后补救成本。
• 控制器（后台）的作用：对历史资源做周期扫描、generate 或 cleanup，填补 admission 只影响新请求的空白。

架构优势¶

• 运维一致性：无需引入新 DSL，降低团队学习成本与运维复杂度。
• 双模互补：实时阻断 + 后台治理覆盖资源生命周期全链路。
• 可扩展性：基于 Kubernetes 控制循环模式，易于水平扩展与功能扩展（如镜像验证插件）。

实用建议¶

1. 利用 CRD 与 GitOps 同步策略定义，保持审计与回滚路径。
2. 为 webhook 配置高可用并监控延迟，避免将 API 请求时延引入关键路径。

注意事项：虽然架构天然贴合 Kubernetes，但依赖 API 服务器的可用性与权限配置，需在生产环境中做好 HA 与 RBAC 规划。

总结：CRD + admission + controller 的组合在可管理性、实时性与历史治理间取得平衡，是 Kyverno 成为 Kubernetes 原生策略引擎的关键设计选择。

核心分析¶

问题核心：verifyImage 能在多大程度上提升供应链安全？有哪些实务限制？

技术分析¶

• 有效能力：在 admission 阶段校验镜像签名（如 Cosign 格式）可以阻止未签名或签名与策略不匹配的镜像被创建为 Pod，从而减少运行时引入恶意或未审计镜像的风险。
• 后台补偿：结合后台扫描，可定期检查已运行容器是否仍满足签名策略，支持补救措施（如标记或驱逐）。
• 依赖项：需要可访问的签名元数据、验证密钥/公钥和对私有 registry 的正确配置。

实用建议¶

1. 在 CI/CD 中强制镜像签名并在 Kyverno 中设置匹配策略（签署者、签名时间等），形成上下游闭环。
2. 为私有 registry 与离线场景配置可信公钥或使用信任代理，并在后台开启定期扫描。
3. 通过 dry-run 验证对签名策略的影响，避免因签名缺失误阻生产部署。

注意事项：Kyverno 提供的是运行时/入库层的验证，不能替代完整的供应链流程（如构建环境硬化、密钥轮换、签名撤回管理等）。对离线镜像或不可访问签名存储的场景需要额外设计。

总结：verifyImage 是一层高效的运行时供应链保护，适用于已实现签名流程与密钥管理的组织；但对密钥、签名可达性与外部信任状态有实际依赖，需配合完整的签名与密钥管理策略使用。

核心分析¶

问题核心：复杂策略（mutate/generate/validate）如何设计才能既实现目标又不引入冲突或性能问题？

技术分析¶

• 冲突来源：
• mutate 改写可能改变 validate 判断结果；
• 多个 mutate 互相覆盖或重复生成相同资源；
• generate 触发额外对象的创建，可能再次触发策略引擎，形成循环。
• 性能考量：复杂匹配与大量变更会增加 webhook 延迟与控制器负载，影响 API 操作延迟。

设计原则与实践¶

1. 精确范围与选择器：用 namespace/label/annotation 精确控制目标对象，避免全局匹配。
2. 幂等与标记：mutations 和 generate 应设计为幂等操作，并通过 annotation 标记已处理对象以避免重复处理。
3. 避免依赖顺序的逻辑：尽量让单个策略自洽，若需顺序，明确记录并分阶段 rollout。
4. CI/测试覆盖：将策略与示例资源纳入 CI 测试，模拟常见变更并在 dry-run 模式下校验行为。
5. 监控与容量评估：在预生产压力测试 webhook 延迟与控制器 CPU/内存使用，设置报警阈值。

注意事项：在生产环境直接启用广泛的 mutate/generate 策略前，务必通过 dry-run、分批发布与回滚计划确保不会产生循环或大量误变更。

总结：通过范围限制、幂等设计、标记防重、CI 测试与运行时监控，能有效设计复杂策略并把冲突与性能风险降到可控水平。