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

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 当成高风险资产管理集群安全才有基础。