📚 课程目录第1章课程导论

1. 课程导论：Secrets 轮换的挑战与自动化必要性

在云原生生产环境中，Secrets（数据库密码、API 令牌、TLS 证书、服务账号密钥）是攻击者的首要目标。手动轮换不仅效率低下，而且极易导致配置漂移、服务中断或凭据泄露。本课程将系统讲解如何利用 Kubernetes 控制平面（API Server + Admission Webhook）构建声明式、无中断的 Secrets 自动轮换策略。

1.1 传统 Secrets 轮换的四大痛点

痛点	典型表现	风险等级
手动操作频繁	运维人员 SSH 登录节点，手动更新 Secret 对象并重启 Pod	高
依赖外部工具链	使用 Jenkins 定时任务 + kubectl patch，缺乏一致性校验	中
Pod 重启风暴	轮换后强制滚动更新所有关联 Deployment，导致服务抖动	高
审计与回滚缺失	无法追溯谁在何时轮换了哪个 Secret，失败后难以恢复	高

  关键洞察： 上述痛点的根源在于轮换逻辑游离于 Kubernetes 控制平面之外。将轮换策略嵌入 Admission Webhook，可以实现“声明式期望状态 → 控制面自动调和”的闭环。

1.2 为什么需要控制平面驱动？

Kubernetes 控制平面天然具备事件驱动、声明式调和与可扩展准入控制能力。通过 MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook，我们可以在 Secret 创建/更新时自动注入轮换逻辑，无需修改用户工作负载定义。

无侵入性： 开发人员只需声明 secrets.rotation/auto=true 标签，Webhook 自动处理轮换策略。
一致性保障： 所有 Secret 变更都经过同一套策略引擎，避免配置漂移。
可审计： 轮换事件自动记录到 Kubernetes Event 和审计日志。

1.3 自动化轮换的核心收益

维度	手动轮换	控制平面驱动自动轮换
轮换周期	数小时～数天	分钟级（可配置 TTL）
Pod 影响	全量重启	原地更新或 Sidecar 热加载
错误率	> 5%	< 0.1%
审计追溯	依赖外部日志	内置 Kubernetes Event

1.4 课程知识图谱

本课程将围绕以下技术栈展开，最终交付一个生产可用的准入控制轮换框架：

Webhook 基础： MutatingWebhookConfiguration 与 ValidatingWebhookConfiguration 的声明式配置。
策略引擎设计： 基于 Rego（OPA）或 Go 模板的轮换规则定义。
Secrets 版本管理： 使用 secrets.rotation/version 注解实现平滑迁移。
Pod 原地更新： 结合 kubectl rollout restart 或 Sidecar 热加载。
故障回滚： 自动保留前一个版本的 Secret 快照。

学习路径提示： 本课程假设你已熟悉 Kubernetes 基本资源（Secret、Pod、Deployment）和 kubectl 操作。如果你对 Admission Webhook 概念不熟，建议先阅读 Kubernetes 官方文档“动态准入控制”章节。

1.5 自动化轮换的适用场景

数据库凭据： 每 24 小时自动轮换 MySQL/PostgreSQL 密码，避免长期凭据泄露。
云服务 API 令牌： AWS/GCP/Azure 服务账号密钥按策略自动轮换，并同步到 Kubernetes Secret。
TLS 证书： 集成 cert-manager，在证书到期前自动轮换并更新 Ingress 引用。
服务间 mTLS： 基于 SPIFFE 的身份证书自动轮换，无需重启 Sidecar。

1.6 课程交付物预览

完成本课程后，你将获得：

交付物	说明
Webhook 部署 Helm Chart	包含 MutatingWebhookConfiguration、ValidatingWebhookConfiguration、Service、Deployment
策略引擎 Go 源码	基于 Kubernetes client-go 的 Webhook Server，支持热加载策略规则
轮换策略 YAML 示例	涵盖数据库密码、API 令牌、TLS 证书的轮换规则定义
端到端测试脚本	使用 Kind 集群模拟轮换全流程，验证 Pod 无中断更新

注意： 本课程不覆盖 Secret 加密存储（如 KMS、Vault 集成），这些属于数据平面安全范畴。我们聚焦于控制平面的轮换策略编排。