1. 课程导论：平台门户与 Kyverno 回滚护栏的审计日志设计背景与目标
1.1 为什么需要“回滚护栏”？
在云原生平台门户中，用户通过自助式界面提交工作负载配置（Deployment、ConfigMap、Service 等）。一旦配置错误（如镜像拉取策略错误、资源限制遗漏、安全上下文缺失），可能导致服务中断或安全漏洞。传统做法依赖人工 Code Review，但面对每日数百次配置变更，纯人工审核无法覆盖所有风险。
Kyverno 作为 Kubernetes 原生的策略引擎，可以在 Admission Webhook 阶段拦截并校验资源请求。然而，策略引擎的“拦截”模式过于刚性——一旦策略误判或策略版本升级，可能阻塞正常发布流程。因此，业界引入 “回滚护栏” 机制：当 Kyverno 检测到高风险变更时，不直接拒绝，而是自动触发回滚至上一稳定版本，同时生成完整的审计日志，供平台门户展示和运维追溯。
核心观点： 回滚护栏不是“禁止变更”，而是“安全降级 + 可追溯”。审计日志是连接平台门户与 Kyverno 策略引擎的“黑匣子”，记录每一次拦截、放行、回滚的完整上下文。
1.2 平台门户与 Kyverno 的联动架构
下图展示了平台门户、Kyverno 策略引擎、审计日志服务三者之间的数据流与决策链路：
1.3 审计日志设计的核心目标
本课程设计的审计日志体系围绕以下 5 个目标 展开：
| 目标 | 描述 | 关键指标 |
|---|---|---|
| 1. 全量记录 | 捕获每一次 Kyverno 策略评估结果（通过/拒绝/警告）及对应的原始 AdmissionReview 请求 | 日志覆盖率 ≥ 99.99% |
| 2. 回滚溯源 | 记录回滚触发原因（策略名称、违规字段、用户身份）、回滚前后资源版本差异 | 回滚事件可追溯至具体策略规则 |
| 3. 平台联动 | 审计日志需以结构化格式（JSON/Protobuf）推送至平台门户的审计中心，支持实时搜索与告警 | 端到端延迟 ≤ 5 秒 |
| 4. 不可篡改 | 日志存储采用 Append-Only 模式，结合数字签名或区块链哈希链，防止事后篡改 | 完整性校验通过率 100% |
| 5. 低性能开销 | 审计日志采集对 API Server 和 Kyverno 的额外延迟 ≤ 2ms，不阻塞主流程 | P99 延迟 ≤ 2ms |
1.4 课程覆盖范围与学习路径
本课程共 30 章，分为 4 个阶段：
- 基础篇（第 1-8 章）： Kyverno 策略引擎原理、Admission Webhook 生命周期、审计日志基础模型。
- 设计篇（第 9-18 章）： 审计日志 Schema 设计、回滚护栏状态机、平台门户事件订阅接口、日志存储选型（Elasticsearch / ClickHouse / S3）。
- 实现篇（第 19-26 章）： Kyverno 自定义插件开发、审计日志 Sidecar 模式、回滚控制器实现、端到端集成测试。
- 运营篇（第 27-30 章）： 日志监控与告警、合规审计报告、灾难恢复演练、课程总结与最佳实践。
前置知识要求： 熟悉 Kubernetes 基本概念（Pod、Deployment、Admission Webhook）、了解 Kyverno 策略编写（ClusterPolicy / Policy）、具备基础的 Go 或 Python 开发能力。
1.5 关键术语表
| 术语 | 全称 / 解释 |
|---|---|
| Kyverno | Kubernetes 原生策略引擎，支持 Mutation 和 Validation 两种 Webhook 模式 |
| 回滚护栏 | 当策略引擎检测到高风险变更时，自动触发资源回滚至上一稳定版本的安全机制 |
| AdmissionReview | Kubernetes API Server 发送给 Webhook 的请求/响应结构体，包含资源对象完整信息 |
| 审计日志 | 记录系统操作事件的不可变日志流，用于安全审计、故障排查和合规报告 |
| 平台门户 | 面向开发者的自助式云原生管理界面，提供资源申请、策略查看、审计搜索等功能 |
注意： 本课程所有设计均基于 Kyverno v1.12+ 和 Kubernetes v1.28+。若使用更早版本，部分 API 字段（如
spec.rules.match 的表达式语法）可能不兼容，请参考官方迁移文档。