本文定位：面向需要在 Kubernetes 中管理数据库密码、证书、Token、API Key 等敏感信息的平台、安全和应用团队。
Secret管理不是把密码从 ConfigMap 换成 Secret 就结束了。Kubernetes Secret 默认提供对象化管理和基本编码能力，但它并不等于完整的密钥保险箱。真正的敏感信息保护，需要覆盖开发提交、镜像构建、CI/CD 变量、etcd 存储、Pod 挂载、运行时日志和泄露后的轮换响应。只盯着 Secret 对象本身，往往会漏掉更早或更晚的暴露点。
如果你的团队正在建立 Kubernetes 安全基线，可以先阅读 Kubernetes安全怎么做 了解权限、网络和运行时的整体框架；本文聚焦其中最容易被忽视、但影响面很大的 Kubernetes Secret 管理。
Secret 解决了什么，也没有解决什么
Kubernetes Secret 的基本作用，是把敏感数据作为独立 API 对象管理，并通过 Volume 或环境变量注入到 Pod 中。它比把密码写进镜像、Deployment YAML 或 ConfigMap 更可控，因为可以单独授权、单独更新，也能与平台的审计、准入和轮换流程结合。
但需要明确：Secret 数据通常是 base64 编码，不是天然加密。是否在 etcd 中静态加密、谁能 get/list/watch Secret、Secret 是否被写进日志、是否能被调试 Shell 读取，仍然取决于集群配置和使用方式。
Secret 管理至少要回答四个问题：
- 凭据从哪里来：人工录入、CI/CD 注入、外部密钥系统同步，还是动态签发。
- 谁可以读取：哪些用户、ServiceAccount、控制器和命名空间有访问权限。
- 怎样被使用：通过环境变量、Volume、CSI 驱动或应用侧拉取。
- 泄露后怎么办：如何发现、撤销、轮换、验证和复盘。
图1：敏感信息从开发交付到运行时的暴露面分层
第一条原则：不要让敏感信息进入代码和镜像
很多 Secret 泄露不是发生在集群里，而是发生在更早的开发和交付阶段。比如开发者把数据库密码提交到 Git，构建脚本把 Token 写进镜像层，CI 日志打印了环境变量，或者 Helm values 文件被上传到公共仓库。
开发和交付侧建议先做这些控制：
- 代码仓库扫描：对 Git 提交、Merge Request 和历史分支做密钥模式扫描，发现疑似凭据立即阻断或告警。
- 镜像构建隔离：不要把构建期密钥写入 Dockerfile、镜像层或最终镜像环境变量。
- CI/CD 变量分级：生产凭据与测试凭据隔离，只有必要流水线和必要人员可见。
- 模板默认安全：应用脚手架、Helm Chart 和部署模板不要要求用户手工粘贴明文密码。
这些措施看起来不属于 Kubernetes，但它们决定了 Secret 进入集群前是否已经失控。敏感信息一旦进入 Git 历史或镜像层，后续只在 Kubernetes 里“删除对象”并不能彻底消除风险。
第二条原则：用 RBAC 缩小 Secret 读取面
在 Kubernetes 里，能读取 Secret 的主体通常比团队预想得更多。某些控制器、运维账号、平台组件和业务 ServiceAccount 都可能因为权限绑定过宽而具备 get、list 或 watch Secret 的能力。
权限收敛可以按三步推进：
- 先盘点：列出所有能访问 secrets 资源的 Role、ClusterRole、RoleBinding 和 ClusterRoleBinding。
- 再分组：区分平台控制器、业务工作负载、运维人员和自动化流水线，不同角色使用不同权限边界。
- 最后收敛：业务 ServiceAccount 只读取自身命名空间内必需 Secret，避免通配资源和集群级读取权限。
如果平台涉及多团队、多集群或多租户场景，建议在平台规划阶段就把命名空间边界、角色边界和审计要求一起设计。关于平台分层和治理入口，可以结合 Kubernetes平台建设怎么规划 进一步梳理。
第三条原则：启用 etcd 静态加密并保护密钥材料
Secret 对象最终会存储在 etcd 中。如果没有启用静态加密，etcd 数据文件或备份一旦泄露，就可能暴露 Secret 内容。Kubernetes 支持通过 EncryptionConfiguration 对 Secret 等资源启用静态加密，但这只是链路的一部分。
启用静态加密时要同步检查：
- 加密范围：确认 secrets 资源被纳入加密配置，必要时评估 ConfigMap 等对象是否也包含敏感信息。
- 密钥管理：加密密钥本身不能随意放在不受控目录里，访问权限和备份策略要清晰。
- 轮换流程：加密配置更新后，需要按官方流程重新加密已有数据，并验证 API Server 和 etcd 状态。
- 备份保护：etcd 备份与快照同样需要加密、授权和保留周期管理。
静态加密不能替代 RBAC。它主要降低存储介质、备份文件和底层访问泄露风险；如果某个账号本来就能通过 API 读取 Secret，加密并不会阻止它看到解密后的内容。
第四条原则：根据场景选择原生 Secret、外部密钥系统或动态凭据
不是所有敏感信息都应该长期存放在 Kubernetes Secret 中。原生 Secret 适合低频变化、集群内使用、访问范围清晰的配置；如果组织已经有统一密钥管理系统，或需要集中审计、自动轮换和跨环境治理，可以考虑外部密钥方案；如果访问的是云资源或短期授权资源，则应优先考虑动态凭据或工作负载身份，减少长期密钥落盘。
图2：不同敏感信息场景下选择 Secret 使用方式的决策路径
| 场景 | 更适合的方式 | 关注点 |
|---|---|---|
| 应用启动读取数据库密码 | 原生 Secret 或外部同步后的 Secret | RBAC、挂载范围、轮换影响 |
| 多集群共享证书和 API Key | 外部密钥系统同步 | 同步延迟、审计、失败降级 |
| 临时访问云资源 | 动态凭据或身份联合 | 过期时间、刷新机制、最小权限 |
| 高敏感生产凭据 | 外部密钥系统 + 严格审计 | 审批、轮换、访问追踪 |
选择方案时不要只看工具能力
外部密钥系统能增强集中管理，但也会引入控制器权限、同步失败、网络依赖和运维复杂度。动态凭据能减少长期密钥，但要求应用和平台支持身份联动。原生 Secret 简单直接，但必须补齐加密、RBAC、审计和轮换。方案选择应围绕风险和运行能力，而不是为了引入某个工具而重构。
第五条原则：谨慎使用环境变量注入敏感信息
Secret 可以通过环境变量或 Volume 注入。环境变量使用方便，但也更容易在进程信息、错误日志、调试输出或崩溃转储中被暴露。Volume 挂载更适合证书和文件型凭据，也便于某些轮换场景，但应用需要按文件读取。
使用方式建议：
- 优先减少暴露：能用文件挂载的场景，不要默认全部放进环境变量。
- 限制调试入口：生产环境中的 exec、attach 和临时调试容器需要审批或审计。
- 避免日志输出：应用启动日志、配置打印和异常栈不要输出完整连接串、Token 或证书内容。
- 明确更新策略：环境变量通常需要重启 Pod 才能感知变化；Volume 更新也要确认应用是否会重新加载。
如果团队已经在做集群纳管或工具选型，也应把 Secret 可视化权限、审计和批量轮换能力纳入评估。相关维度可参考 集群管理工具怎么选 中的权限治理和多集群管理要求。
第六条原则：把泄露响应流程提前写清楚
Secret 泄露后，最怕的是团队不知道该撤销哪个凭据、重启哪些应用、验证哪些路径。应急流程必须在平时就准备好，而不是等告警出现后临时拼命令。
建议把响应流程拆成五步：
- 确认范围：识别泄露的 Secret 名称、命名空间、关联应用、外部系统和可能访问者。
- 临时止血：暂停相关凭据、收敛 RBAC、阻断异常来源，必要时临时下线高风险入口。
- 轮换凭据：在外部系统生成新凭据，更新 Kubernetes Secret，并触发应用滚动重启或重新加载。
- 验证恢复：确认应用可用、旧凭据不可用、异常访问停止。
- 复盘改进：更新扫描规则、准入策略、模板和权限边界，避免同类问题重复发生。
图3：Secret泄露防范在预防发现响应和改进阶段的控制矩阵
落地检查清单
上线或整改 Secret 管理能力时，建议逐项检查：
- 对象治理：Secret 命名、用途、owner、环境和过期时间是否清晰。
- 权限治理：是否存在业务账号跨 namespace list/watch secrets。
- 存储保护：etcd 是否对 Secret 启用静态加密，备份是否受控。
- 交付保护：Git、镜像、CI 日志中是否会出现明文凭据。
- 运行保护：是否避免不必要的环境变量注入，是否审计生产 exec 操作。
- 轮换能力：是否知道哪些应用依赖某个 Secret，轮换后如何重启或重新加载。
- 泄露响应：是否有凭据撤销、告警升级、影响面确认和复盘机制。
小结
Kubernetes Secret管理的重点，是把敏感信息看作一条贯穿开发、交付、存储、运行和应急响应的链路。原生 Secret 能提供基础对象管理，但仍要配合 RBAC、etcd 静态加密、审计日志、外部密钥系统和轮换流程。对于企业团队，最实用的路径是先清理代码和镜像中的明文凭据，再收敛 Secret 读取权限，随后补齐静态加密、使用方式规范和泄露响应闭环。这样才能把 Secret 从“能用”推进到“可控、可查、可恢复”。
FAQ
Kubernetes Secret 是加密的吗？
Secret 内容在清单中通常以 base64 表示，这不是加密。是否在 etcd 中加密，取决于集群是否配置了 EncryptionConfiguration 等静态加密能力。即使启用了存储加密，具备 API 读取权限的主体仍可能看到解密后的内容，所以 RBAC 和审计同样重要。
Secret 应该用环境变量还是 Volume 挂载？
没有绝对答案。环境变量简单，但更容易被日志、调试和进程信息暴露；Volume 更适合证书和文件型凭据，也更便于部分更新场景。生产环境建议优先评估暴露面和应用加载方式，不要默认把所有敏感信息放进环境变量。
是否必须引入外部密钥管理系统？
不一定。小规模或边界清晰的集群，可以先用原生 Secret、RBAC、etcd 加密和审计把基础能力做好。多集群、多团队、强审计或高频轮换场景，更适合评估外部密钥系统。引入前要确认同步失败、控制器权限和运维复杂度是否可控。
Secret 泄露后只删除 Kubernetes Secret 可以吗？
通常不够。Secret 只是凭据在集群内的一份载体，真正需要撤销的是外部系统中的密码、Token、证书或 API Key。正确做法是确认影响范围、撤销旧凭据、生成新凭据、更新 Secret、重启或重新加载应用，并验证旧凭据已经失效。
怎么发现谁读取过 Secret？
可以通过 Kubernetes 审计日志追踪对 secrets 资源的 get、list、watch 等请求，重点查看 user、verb、objectRef、namespace、sourceIPs 和 responseStatus 等字段。审计能力需要提前配置，事后再开启通常无法还原历史访问行为。
权威参考资料
- Kubernetes 官方文档：Secrets
- Kubernetes 官方文档：Encrypting Confidential Data at Rest
- Kubernetes 官方文档：Good practices for Kubernetes Secrets
- Kubernetes 官方文档：Using RBAC Authorization
