1. 课程导论：云原生 Secrets 管理面临的挑战与合规重要性概述
在云原生架构中，Secrets（如数据库密码、API 令牌、TLS 私钥、云服务凭证）是应用运行时的核心敏感资产。传统静态凭证管理方式在容器化、动态编排和微服务环境下暴露出严重的安全缺口。本章将系统梳理 Secrets 管理面临的核心挑战，并阐明合规驱动的轮换策略为何成为准入评审的关键环节。
1.1 云原生 Secrets 管理的四大核心挑战
Kubernetes 等编排平台虽然提供了原生的 Secret 资源对象，但默认行为存在显著风险。以下表格对比了传统环境与云原生环境下的凭证管理差异：
| 维度 | 传统环境 | 云原生环境 |
|---|---|---|
| 生命周期 | 静态、长周期（数月/年） | 动态、短周期（分钟/小时/天） |
| 存储方式 | 配置文件、环境变量、硬编码 | etcd（Base64 编码）、外部 Secret Store |
| 访问主体 | 固定 IP、物理机、VM | Pod、ServiceAccount、Sidecar、Init 容器 |
| 轮换频率 | 手动、事件驱动 | 自动、策略驱动、准入控制 |
| 审计能力 | 弱、依赖系统日志 | 强、可集成 OPA/Kyverno 策略引擎 |
基于上述差异，云原生 Secrets 管理面临以下四大挑战：
- 静态凭证泄露面扩大：Pod 间网络通信、Sidecar 注入、ConfigMap 挂载等场景使凭证暴露路径激增。Base64 编码并非加密，etcd 中存储的 Secret 若未启用加密静态存储，极易被横向移动攻击窃取。
- 轮换缺乏自动化与一致性：手动轮换在多集群、多命名空间环境下几乎不可行。轮换窗口不一致会导致服务中断或凭证失效风暴。
- 准入控制缺失：默认 Kubernetes 不强制校验 Secret 的创建来源、加密状态或轮换策略。恶意或错误配置的 Secret 可直接进入集群。
- 合规审计碎片化：SOC 2、PCI DSS、HIPAA 等标准要求凭证定期轮换与访问审计，但原生 API 缺乏细粒度的轮换时间戳和策略绑定记录。
关键洞察： 根据 2024 年《云原生安全报告》，超过 60% 的容器环境泄露事件与硬编码或未轮换的 Secrets 直接相关。准入策略评审是阻断此类风险的第一道防线。
1.2 合规重要性：从“可选”到“强制”
全球监管框架对凭证生命周期管理提出了明确要求。以下表格列出主要合规标准与 Secrets 轮换相关的核心条款：
| 合规标准 | 相关条款 | 轮换要求 |
|---|---|---|
| PCI DSS v4.0 | 要求 8.3.1 | 每 90 天轮换一次认证凭证；首次使用前必须轮换默认凭证 |
| SOC 2 | CC6.1 / CC6.6 | 实施自动化凭证管理；定期审查并轮换共享凭证 |
| HIPAA | §164.312(a)(1) | 唯一用户标识与自动过期机制；紧急访问程序需包含凭证轮换 |
| ISO 27001 | A.9.2.4 / A.9.4.3 | 密码与密钥的定期变更策略；特权访问凭证的强制轮换 |
| NIST SP 800-53 | IA-5 / SC-12 | 凭证生命周期管理；加密密钥的定期轮换与撤销机制 |
合规驱动的轮换策略不再是“最佳实践”，而是准入评审的硬性准入条件。未通过轮换策略校验的 Secret 资源应被准入控制器（如 OPA Gatekeeper、Kyverno）直接拒绝。
1.3 云原生 Secrets 轮换准入策略架构
下图展示了从 Secret 创建到准入评审、轮换执行与审计的完整架构关系：
1.4 准入策略评审的核心目标
本课程聚焦于在 CI/CD 流水线 和 Kubernetes 准入阶段 建立可编程的 Secrets 轮换策略。评审的核心目标包括：
- 强制轮换周期：通过 OPA Rego 或 Kyverno 策略定义最大 Secret 存活时间（如 72 小时），超期自动拒绝或触发轮换。
- 加密状态校验：确保所有 Secret 在 etcd 中启用 AES-256 或 KMS 加密，拒绝未加密的 Secret 资源。
- 来源绑定：校验 Secret 是否来自受信任的外部 Secret Store（如 HashiCorp Vault、AWS Secrets Manager），禁止直接创建静态 Secret。
- 轮换历史可审计：要求每个 Secret 携带
last-rotation-timestamp注解，准入控制器校验时间差。
实践建议： 在集群中部署 Kyverno 并启用
validate-secret-rotation 策略，结合 MutatingAdmissionWebhook 自动注入轮换注解。这是实现“评审即防御”的最快路径。