kubernetes secret 本身不加密，base64 仅为编码；真正安全依赖 rbac 权限控制、secret 挂载为文件（非环境变量）、go 程序读取时字段级解密及外部密钥管理（如 vault）等组合策略。
Kubernetes Secret 本身不加密，Base64 编码不是加密，只是编码；真正安全靠的是权限控制 + 挂载方式 + Go 程序读取逻辑的组合。
Secret 创建时别用 --from-literal 存密码明文
直接 kubectl create secret generic app-sec --from-literal=password=abc123 会让密码以 Base64 形式存进 etcd——任何有 get secrets 权限的人都能 kubectl get secret app-sec -o yaml 解出明文。这不是加密，是“贴便利贴”。
正确做法是：本地先生成敏感文件，再从文件创建：
-
echo -n "P@ssw0rd!2026" > ./secrets/db/password（注意-n） kubectl create secret generic db-secret --from-file=./secrets/db/password- Secret 的 key 就是
password，value 是文件内容的 Base64 编码
这样至少避免密码在命令行历史、shell 日志或审计日志中裸奔。
挂载为文件而非环境变量，Go 用 os.ReadFile 读取
用 envFrom 或 secretKeyRef 注入环境变量，等于把密钥塞进进程的 /proc/[pid]/environ，ps aux、容器 env 命令、甚至崩溃 dump 都可能泄露。
应改为挂载为只读文件：
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- Deployment 中配置：
volumeMounts挂载到/etc/secrets/db/password - 对应
volumes引用db-secret，defaultMode: 0440（仅 owner/group 可读） - Go 代码里用
os.ReadFile("/etc/secrets/db/password")，不要用os.Getenv
本地开发时，保持路径一致（如 ./secrets/db/password），由 make secrets 生成，且该目录加进 .gitignore。
Go 解密逻辑必须自己写，viper 不支持运行时字段解密
Secret 挂载的是明文（只是 Base64 编码），如果你真需要加密存储（比如防止运维误看或镜像层残留），得在 Go 侧做字段级解密：
- 配置文件（如 YAML）里保留
database.password: "AES-GCM:xxx..."这种标记值，而不是直接放明文 - 解析后用
mapstructure.Decode转成map[string]interface{}，递归遍历 key 名是否匹配password、token等敏感名 - 命中后调用自定义解密函数：
aes.NewCipher+cipher.NewGCM，nonce 必须是随机 12 字节，密文格式为nonce + ciphertext + authTag - 密钥严禁硬编码：从
os.LookupEnv("KEY_PATH")加载文件，或对接 Vault/KMS
viper.Unmarshal 无法在反序列化过程中插入解密逻辑，强行改结构体字段也绕不开内存暴露风险——所以字段级解密必须在解析后、使用前完成。
别忽略权限和日志侧信道
即使 Secret 挂载和解密都对了，两个低级但致命的坑常被跳过：
- 挂载目录权限没设：
securityContext.fsGroup: 2001和defaultMode: 0440必须配对，否则容器内任意用户都能cat /etc/secrets/... - 日志打印长度或类型信息：
log.Printf("pwd len: %d", len(b))或slog.String("pwd_type", "aes-gcm")可能构成侧信道，帮助攻击者推断密文长度或加密方式 - 解密失败统一返回
http.StatusBadRequest，不区分是密钥错、nonce 错还是数据损坏，避免信息泄露
真正的安全不在“能不能跑通”，而在“有没有人能从日志、进程、镜像、etcd、权限松动里捞出密码”——每一步都要问一句：这东西如果落到不该看的人手里，会暴露什么？
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
