Kubernetes Secret 管理：能挂载不代表安全

一、Secret 不是天然安全

Kubernetes Secret 很常用，数据库密码、API Token、证书都可能放在里面。但名字叫 Secret，不代表它天然安全。默认情况下，Secret 只是做了编码存储，权限、加密、轮换和审计都需要额外设计。

生产集群里，Secret 管理的核心不是“能不能挂载到 Pod”，而是“谁能读、如何加密、何时轮换、泄露后怎么处理”。

二、先梳理 Secret 生命周期

flowchart TD A[密钥生成] --> B[写入 Secret] B --> C[Pod 使用] C --> D[轮换] D --> E[旧密钥废弃] B --> F[审计与告警]

密钥从生成到废弃都要有流程。很多问题不是 Secret 写错，而是旧密钥长期不废弃、测试密钥进入生产、开发人员拥有过大读取权限。

Secret 还要分类。数据库密码、第三方 Token、TLS 证书、签名私钥的保护等级不同，不能用同一套策略粗放管理。

三、RBAC 要严格限制读取

apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: secret-reader rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get"]

能读 Secret 的权限非常敏感。不要把list secrets随便给通用运维账号，更不要让应用服务账号读取整个命名空间的所有 Secret。

secret_policy: encrypt_at_rest: true require_rotation_days: 90 deny_list_all_secrets: true audit_read_events: true

如果集群支持 KMS 加密，应启用静态加密。对于高敏感密钥，可以考虑外部密钥管理系统和动态注入。

四、轮换要有应用配合

Secret 轮换不是改一行 YAML。应用是否能热加载，连接池是否需要重建，旧密钥是否有宽限期，都会影响发布方式。

轮换流程最好先在低风险服务演练。确认新旧密钥并存、Pod 重启、连接恢复和回滚路径都正常，再推广到核心服务。

Secret 使用方式也要被检查。通过环境变量注入很方便，但进程转储、调试页面或错误日志可能泄露；通过文件挂载便于轮换，但应用必须支持重新读取。选择哪种方式，要看应用框架和轮换要求。

secret_usage_check: avoid_logging_secret: true support_dual_credentials: true reload_without_redeploy: preferred detect_unused_secret: true

还要清理未使用 Secret。很多集群里残留着旧服务、旧环境、旧证书留下的 Secret，它们不再被使用，却仍然可能被读取。定期扫描挂载关系和访问记录，可以减少暴露面。

事故预案同样重要。一旦怀疑密钥泄露，要知道如何快速吊销、生成新密钥、批量重启相关 Pod，并确认旧密钥不再被接受。没有预案，Secret 管理只停留在平时规范。

五、总结

Kubernetes Secret 管理要覆盖权限、加密、审计、分类和轮换，不能只停留在挂载可用。

密钥泄露往往不是单点失误，而是生命周期缺失。把 Secret 当成高风险资产管理，集群安全才有基础。