MongoDB要求keyFile权限严格为400，Kubernetes挂载Secret时必须设defaultMode: 256（八进制400），且需确保挂载路径与security.keyFile一致、目录可访问、属主正确，否则启动失败。
直接挂载安全认证配置的关键是：不能把 keyFile 或 mongod.conf 硬编码进镜像，必须通过 Kubernetes 原生方式（Secret + ConfigMap）挂载到容器指定路径，且权限必须严格控制。
如何用 Secret 挂载 keyFile 并确保权限正确
MongoDB 要求 keyFile 在容器内权限为 400（仅所有者可读），否则启动失败并报错 keyfile permissions are too open。Kubernetes 默认挂载的文件权限是 644，必须显式设置 mode。
- 先 base64 编码你的密钥文件：
openssl rand -base64 768 > mongodb.key && kubectl create secret generic mongodb-key --from-file=mongodb.key - 在 Pod 或 StatefulSet 的
volumes中引用该 Secret，并指定defaultMode: 256（即八进制400） -
volumeMounts中的path必须与配置中security.keyFile的值完全一致，例如/data/key/mongodb.key - 不要用
subPath挂载单个文件——它会忽略defaultMode，导致权限错误
ConfigMap 挂载 mongod.conf 的常见陷阱
配置文件挂载后 MongoDB 启动报 Failed to parse config file，大概率是 YAML 转义或缩进问题。Kubernetes ConfigMap 的 data 字段不自动处理缩进，原始配置格式必须保留。
- 用
cat > mongod.conf手动写入时，确保security.authorization: enabled和security.keyFile在同一层级，且冒号后有空格 - 挂载路径建议设为
/etc/mongod.conf，并在容器启动命令中显式指定--config /etc/mongod.conf，避免依赖默认路径 - 如果使用 Helm chart，检查 values.yaml 中是否覆盖了
security配置块——某些 chart 会默认关闭authorization，即使你挂了配置文件也无效
StatefulSet 中挂载顺序与初始化依赖
MongoDB 容器启动前，必须确保 keyFile 和 mongod.conf 已就绪，否则会因文件缺失反复 CrashLoopBackOff。
- 在
initContainers中不做文件校验——Kubernetes 挂载是原子操作，只要 Secret/ConfigMap 存在，挂载即完成 - 但需确认
volumeMounts的mountPath目录在容器内已存在（如/data/key），否则挂载失败；可在主容器command开头加mkdir -p /data/key /etc - 若使用 Operator（如 MongoDB Enterprise Kubernetes Operator），不要手动挂载
keyFile——Operator 会自动生成并管理 Secret，你只需在MongoDBCR 中启用spec.security.authentication.modes: ["SCRAM"]或指定keyFile路径
最易被忽略的是挂载点目录权限：MongoDB 进程以非 root 用户（如 mongodb）运行，/data/key 目录本身必须对用户可读，否则即使文件权限是 400，也会因目录不可进入而报错 Permission denied。务必在容器启动命令中加 chown -R mongodb:mongodb /data/key。
