Secret 是唯一推荐方式，因 ConfigMap 明文存储且无访问控制，而 Secret 提供语义隔离、RBAC 权限管控和 etcd 敏感资源标记；环境变量引用需用 valueFrom.secretKeyRef，且 Secret 更新后必须滚动重启 Pod 才生效。

Secret 是唯一推荐方式，明文写进 Deployment 或 StatefulSet 的 env 字段（比如 MYSQL_ROOT_PASSWORD）属于高危操作，哪怕只在测试环境也不该容忍。

为什么不能用 ConfigMap 存密码

ConfigMap 本质是明文存储，kubectl get configmap -o yaml 直接可见全部内容；Secret 虽然底层仍是 base64 编码（非加密），但至少做了语义隔离：API Server 默认限制非授权用户读取 Secret 对象，etcd 中也单独标记为敏感资源，RBAC 策略可精细控制访问权限。

创建 Secret 的两种可靠方式

优先用命令行创建，避免手写 base64 出错：

Kubernetes Security Posture Scorecard

评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……

下载

• kubectl create secret generic mysql-secret --from-literal=root-password=MyP@ssw0rd123 --from-literal=replication-password=rep123 —— 多个键值一次生成，自动 base64 编码，最安全快捷
• 若必须用 YAML，务必用 echo -n 'xxx' | base64 生成值，-n 关键，否则换行符也会被编码导致密码错误
• 不要用在线 base64 工具或文本编辑器“复制粘贴”编码结果，不可控字符易引入空格或 BOM

Pod 中引用 Secret 的常见陷阱

环境变量和 volume 挂载行为差异大，选错会导致 MySQL 启动失败：

• 用环境变量时：env 下必须用 valueFrom.secretKeyRef，不是 valueFrom.configMapKeyRef；字段名必须完全匹配 Secret 的 data 键名（如 root-password）
• 用 volume 挂载时：secretName 必须与实际 Secret 名一致，挂载路径下文件名默认就是 data 的 key（如 /etc/mysql/secret/root-password），MySQL 镜像通常不直接读这些文件，需配合初始化脚本或 entrypoint 解析
• 官方 mysql:8 镜像只认 MYSQL_ROOT_PASSWORD 环境变量，不自动读 Secret 文件 —— 所以绝大多数场景下，环境变量方式更直接

Secret 类型选 Opaque 就够了

除非你明确需要 TLS 证书或 Docker Registry 凭据，否则一律用 type: Opaque（kubectl create secret generic 默认就是它）。其他类型有硬性约束：kubernetes.io/tls 必须含 tls.crt 和 tls.key；kubernetes.io/dockerconfigjson 格式不对会触发 ImagePullBackOff。混用类型等于自埋雷。

真正容易被忽略的是：Secret 创建后不会自动热更新到已运行的 Pod。修改 Secret 内容，必须滚动重启对应 Pod（比如删掉 Deployment 的 Pod 让控制器重建），否则容器里读到的还是旧值。这和 ConfigMap 的 subPath 挂载热更新机制完全不同。