MySQL Pod重启后权限丢失，根本原因是/var/lib/mysql未持久化导致初始化脚本重置系统库；必须挂载PV且reclaimPolicy不设为Delete，并确保initContainer仅首次运行。
MySQL Pod 重启后用户权限丢失怎么办
MySQL 在 K8S 中以 StatefulSet 方式部署时，若未持久化 mysql 系统库（尤其是 mysql.user、mysql.db 表），每次 Pod 重建或漂移都会重置为初始状态：匿名用户残留、root 允许远程登录、test 库开放——相当于裸奔启动。
根本原因不是权限“被删”，而是容器镜像内置的初始化逻辑（如 docker-entrypoint.sh）在 /var/lib/mysql 为空时自动执行 mysqld --initialize，重新生成默认账户体系。
- 必须将
/var/lib/mysql挂载到持久卷（PV），且该 PV 的reclaimPolicy不可设为Delete；否则 PVC 删除即数据清零 - 初始化脚本（如
initContainer或helm post-install）只应在首次启动时运行，后续启动需跳过；可通过检查mysql.user表行数或mysql.ibd文件时间戳判断是否已初始化 - 避免使用
mysql:latest镜像；不同版本初始化行为不一致（例如 MySQL 8.0+ 默认禁用root@%，而 5.7 仍开放）
StatefulSet 中如何安全分发数据库账号密码
K8S 原生 Secret 虽加密存储，但挂载为文件或环境变量后，任意容器内进程均可读取——包括被注入的恶意 sidecar。更危险的是，若应用通过 SELECT USER() 或日志打印连接信息，密码可能意外泄露。
真正安全的做法是剥离“密码分发”环节，改由应用在运行时动态获取凭据：
- 使用
mysql_native_password插件 +CREATE USER ... IDENTIFIED WITH mysql_native_password BY 'xxx'，而非依赖配置文件硬编码 - 借助外部凭据管理器（如 HashiCorp Vault、AWS Secrets Manager），应用启动时按需拉取，并立即丢弃内存中明文（不存入 env、不写入 configmap）
- 若必须用 K8S Secret，禁止以
envFrom全量注入；应仅挂载为只读文件（volumeMounts.readOnly: true），且路径权限设为0400
Pod 漂移后客户端连不上，是不是权限问题
90% 的情况不是权限问题，而是网络或 DNS 变更导致的连接失败。K8S Service 的 ClusterIP 不变，但若客户端直连 Pod IP（常见于开发误配或旧版连接串未切 Service），漂移后原 IP 失效，报错通常是 Connection refused 或超时，而非 Access denied。
排查顺序必须是：
- 确认客户端连接串指向的是
Service Name（如mysql-service.default.svc.cluster.local:3306），而非 Pod IP 或 NodePort - 检查 Service 的
selector是否匹配新 Pod 的 labels（尤其注意 StatefulSet 滚动更新时 label 可能未同步） - 验证新 Pod 的
mysql进程是否监听0.0.0.0:3306（非127.0.0.1:3306），可通过kubectl exec -it <pod> -- netstat -tlnp | grep :3306 - 只有排除网络层后，再查
SELECT User, Host FROM mysql.user，确认账号的Host字段匹配客户端来源（如'app'@'10.244.%'）
为什么用了最小权限，漂移后还是被扫出高危账号
因为加固操作没固化进生命周期。比如人工执行了 DROP USER ''@'%' 和 DELETE FROM mysql.db WHERE Db='test'，但这些变更写在容器临时文件系统里，Pod 重建即消失。真正的加固点只有两个位置：
-
初始化 SQL 脚本：通过
initContainer或 ConfigMap 挂载到/docker-entrypoint-initdb.d/，确保每次冷启动都重放（注意脚本名需以.sql结尾且按字典序执行） -
MySQL 配置项：在
my.cnf中设置skip-show-databases、local_infile=OFF、secure_file_priv=/tmp，这些是进程级开关，不受数据目录影响 - 别信 “加固一次永久生效” —— StatefulSet 的本质是“可重复创建”，所有安全状态必须可声明式重建
最易被忽略的一点：K8S 的 PodSecurityPolicy（或新版 PodSecurity Admission）若未限制容器以 root 用户运行，攻击者一旦突破应用层，就能直接 exec 进容器篡改 /etc/my.cnf 或替换初始化脚本。
