Kubernetes Secret用于保存密码、令牌、证书等敏感配置，但它不是完整的密钥管理系统。很多泄露事故并不是因为Secret机制本身失效，而是创建、分发、权限、日志、备份和轮换流程没有控制好。比如把Secret明文提交到Git，把读取Secret的权限授予过大范围，把敏感值注入环境变量后被日志打印，或者密钥长期不轮换。
更安全的Secret管理，应把Kubernetes对象、RBAC、外部密钥系统、审计和应用改造放在一起考虑。
先理解Secret的安全边界
Secret默认以Kubernetes API对象形式存在，内容经过Base64编码，但Base64不是加密。真正的保护依赖etcd加密、API访问控制、传输加密、节点权限、审计和平台流程。如果用户拥有读取某个命名空间Secret的权限，就可以获取其中内容。
因此，Secret安全的第一原则是减少可读范围。不要把Secret当作普通配置随意复制，也不要把多个应用共享的敏感信息放进同一个对象。更推荐按应用、环境和用途拆分，并让工作负载只读取自己需要的Secret。
创建和分发时避免明文扩散
不建议把包含真实敏感值的Secret YAML直接提交到代码仓库。即使仓库是私有的，也会增加泄露面和清理成本。常见做法包括：使用外部密钥管理系统保存真实密钥，由控制器同步到集群；在CI/CD中通过受控变量生成Secret，避免落盘到普通日志；对GitOps场景使用加密清单，并严格控制解密权限；区分开发、测试、生产密钥，禁止跨环境复用。
如果必须通过命令创建，应注意命令历史和终端日志。可以从文件读取，而不是把敏感值直接写在命令行参数中。
kubectl create secret generic app-db
--from-file=username=./username.txt
--from-file=password=./password.txt
-n <namespace>创建完成后，还应检查谁能读取它，而不只是确认对象存在。
RBAC要按读取行为设计
Secret泄露的常见原因之一是权限过大。很多团队为了方便，把命名空间管理员、自动化账号或调试账号授予了读取所有Secret的权限。短期看效率高，长期看任何账号泄露都会扩大影响。
建议遵循最小权限原则：普通应用ServiceAccount不应拥有列出整个命名空间Secret的权限；自动化账号只授予必要命名空间、必要资源和必要动作；避免给广泛用户组绑定包含 get、list、watch Secret的ClusterRole；对高敏感命名空间启用更严格审计和审批。
可以用以下命令检查权限：
kubectl auth can-i get secrets
--as system:serviceaccount:<namespace>:<serviceaccount>
-n <namespace>如果结果显示某个业务账号能读取不相关Secret，应立即收敛Role和RoleBinding。
环境变量和文件挂载怎么选
Secret可以作为环境变量注入，也可以以文件形式挂载。环境变量使用简单，但更容易被进程信息、错误日志、调试输出或崩溃报告暴露。文件挂载便于权限控制和轮换感知，也更适合证书、密钥文件等内容。
一般建议：短小且低频变更的配置可以谨慎使用环境变量；高敏感、需要轮换或文件格式明确的内容优先使用卷挂载。无论哪种方式，都要避免应用在启动日志中打印完整配置。
还要注意，Secret更新后，应用是否能自动感知取决于使用方式和应用实现。卷挂载的内容可能更新，但应用进程不一定重新读取；环境变量通常需要重启Pod才会变化。因此，Secret轮换必须和工作负载重载策略一起设计。
Secret轮换要有可验证流程
安全的Secret管理不能只关注创建，还要关注轮换。建议为数据库密码、API令牌、证书等关键Secret建立明确周期和事件触发机制。当人员离职、账号泄露、供应商变更或漏洞事件发生时，应能快速完成轮换。
一个可操作流程包括：生成新密钥、更新外部密钥源或Kubernetes Secret、触发工作负载滚动更新、验证业务连接、回收旧密钥、记录审计证据。对于支持双凭据的系统，可以先增加新凭据，再切换应用，最后删除旧凭据，减少中断风险。
平台侧可以提供标准化能力，例如自动注入Secret版本标识，检测Secret变更后触发Deployment重启，或通过外部密钥控制器统一同步和轮换。
与容器安全策略联动
Secret安全还需要和Pod安全、节点安全、日志治理联动。即使RBAC控制严格，如果容器以高权限运行、允许挂载宿主机路径、日志系统采集敏感文件，仍可能扩大泄露面。
建议同时检查：Pod是否需要特权模式；是否限制调试容器和临时容器权限；日志采集是否排除敏感路径；备份系统是否加密Secret数据；运维人员是否通过堡垒机和审计访问集群。Secret管理不是单点配置，而是贯穿应用交付和运维流程的安全控制。更多Kubernetes安全实践可以参考容器安全专题中的运行时加固与镜像治理内容。
常见问题
Kubernetes Secret是不是加密的？
Secret内容在清单中通常是Base64编码，这不是加密。集群可以配置etcd静态加密来保护落盘数据，API访问也依赖TLS和RBAC控制。判断Secret是否安全，不能只看对象类型，而要看etcd加密、访问权限、审计、备份、节点权限和使用方式是否完整配置。
应用读取Secret应该用环境变量还是文件？
两种方式都可用，但安全和轮换特性不同。环境变量接入简单，却更容易出现在调试信息和进程环境中，更新后通常需要重启Pod。文件挂载更适合证书和高敏感内容，也更容易配合权限和轮换机制。生产环境应根据敏感等级和应用重载能力选择，不应把所有Secret都默认注入环境变量。
能不能让开发人员直接查看生产Secret？
一般不建议。生产Secret应通过最小权限、审批和审计控制访问。开发人员可以拥有部署和排障所需的间接能力，但不应默认读取明文密钥。若确需临时查看，应走授权流程，限定时间、范围和原因，并在事后审计。更好的方式是提供密钥轮换、连接测试和故障诊断工具，减少直接暴露明文的需求。
转载请注明出处：https://www.cloudnative-tech.com/p/7469/
