kubernetes secret 的 data 字段必须 base64 编码，但 go 应用读取环境变量时已是解码后的明文，无需也不应再次 base64 解码；若误操作会导致 illegal base64 data 或空字符串错误。
Secret 必须 base64 编码，但 Go 应用里不能直接 decode
很多人以为把 username 和 password 写进 Secret YAML 里，Go 程序读环境变量就能用——其实不对。Kubernetes Secret 的 data 字段要求 base64 编码，但 Go 代码里拿到的环境变量已经是解码后的明文（Kube 自动做了），所以你不需要、也不该再调用 base64.StdEncoding.DecodeString()。
常见错误现象：illegal base64 data 或空字符串，往往是因为手动多解了一次。
- Secret YAML 中写的是
username: dXNlcg==，但你在 Go 里用os.Getenv("MYSQL_USER")拿到的就是"user" - 如果 Secret 用
stringData（非 base64），Kube 会自动编码；这时 Go 侧仍直接读环境变量即可 - 避免在 Secret YAML 里混用
data和stringData，容易导致字段覆盖或解析失败
envFrom + secretRef 是最简挂载方式，但有命名冲突风险
用 envFrom 可以把整个 Secret 当作环境变量批量注入，省得逐个写 env 条目。但要注意：Secret 里的 key 名会直接变成环境变量名，如果和容器内已有变量（比如 Go 运行时的 GOMAXPROCS）或 ConfigMap 里同名 key 冲突，后者会被覆盖，且无警告。
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- 推荐做法：Secret 中 key 全部大写加前缀，例如
DB_USERNAME、DB_PASSWORD - 不要依赖
envFrom注入PORT或HOME这类通用名，改用显式env定义更可控 - 验证是否注入成功：进 Pod 执行
env | grep DB_，别只看 YAML 是否写了
Go 代码里读 Secret 要做空值防护，Kubernetes 不保证变量“一定存在”
Kubernetes 不校验 Secret 是否真包含某个 key，也不校验 Pod 启动时 Secret 是否已存在。如果 Secret 尚未创建或 key 拼错，os.Getenv("MYSQL_PASSWORD") 返回空字符串，Go 程序可能静默连接失败，而不是 panic 报错。
- 必须在初始化数据库连接前检查关键变量：
if os.Getenv("MYSQL_PASSWORD") == "" { log.Fatal("missing MYSQL_PASSWORD") } - 不要用
os.LookupEnv判断是否存在就完事——它返回false时你也得 abort，否则后续逻辑大概率崩 - 敏感配置建议封装成结构体，在
init()或main()开头集中校验，别散落在各处
Secret 更新后，Pod 不会自动 reload，Go 应用得自己处理
修改 Secret 并 kubectl apply 后，已运行的 Pod 里的环境变量**不会更新**——除非你删掉 Pod 让 Deployment 重建它。这是最容易被忽略的点。
- 滚动更新需触发 Pod 重建：改
deployment.yaml的 annotation（比如加个时间戳），或直接kubectl rollout restart deploy/go-app - 如果应用需要热加载（比如长连接不中断），就得监听文件变化（Secret 挂载为 volume 时）或轮询 API，但复杂度陡增，多数场景不值得
- Secret 作为 volume 挂载时，内容会更新（文件被替换），但环境变量方式永远静态——选哪种取决于你的 reload 需求
