MongoDB 5.0+强制keyFile权限为400（-r--------），因600含写位存在密钥被篡改风险；chown可能重置权限，须先chmod 400再chown；K8s挂载需设defaultMode: 256且禁用subPath。
为什么chmod 600在MongoDB 5.0+里直接启动失败
MongoDB从5.0开始对keyFile执行硬性权限校验：只接受400（即-r--------），600（-rw-------）会被明确拒绝，并报错permissions on /path/to/keyfile are too open。这不是警告，是启动阶段直接退出。旧教程说“600就行”，那是4.2及以前的规则；2026年主流发行版默认装5.0+，沿用600只会卡在第一步。
400权限背后的安全逻辑是什么
keyFile本质是共享密钥，内容会被mongod进程读取后用于生成HMAC签名，验证节点间心跳、oplog拉取等所有内部通信。如果文件可写（如600含写位），攻击者一旦获得同用户权限，就能篡改密钥、伪造成员身份——这比“可读”风险高得多。MongoDB强制400，就是堵死“运行时被篡改”这一条路。它不关心你是否真会改，只按最小权限原则拒绝任何冗余位。
chown和chmod顺序搞反会导致权限“悄悄变回600”
在CentOS/RHEL等系统上，chown可能重置文件权限位。如果你先执行chown mongodb:mongodb /etc/mongod-keyfile，再chmod 400，看似操作了，但某些场景下chown会把权限还原为600（尤其当目标用户组有umask影响时）。结果就是日志报错、服务起不来，你还以为chmod生效了。
- 正确顺序：
chmod 400 /etc/mongod-keyfile && chown mongodb:mongodb /etc/mongod-keyfile - 验证命令：
ls -l /etc/mongod-keyfile输出必须是-r-------- 1 mongodb mongodb - 别跳过父目录检查：
mongodb用户必须对/etc有执行权（dr-xr-xr-x这类即可），否则连打开文件都失败
Kubernetes挂载Secret时defaultMode设成256才是关键
K8s默认挂载Secret权限是644，必须显式设defaultMode: 256（八进制400对应的十进制值）。用subPath挂单个文件会忽略defaultMode，导致权限仍是644——这是K8s中keyFile启动失败最隐蔽的原因之一。
- 创建Secret前先生成合规密钥：
openssl rand -base64 768 > mongodb.key - 挂载时必须用完整volume方式，不能
subPath；volumeMounts.path必须与配置中security.keyFile路径完全一致 - Pod内验证：
kubectl exec -it pod-name -- ls -l /data/key/mongodb.key，确认是-r--------
实际部署中最容易被忽略的，不是“要不要设400”，而是“设完之后有没有被chown或K8s挂载机制悄悄覆盖”。每次改完权限，务必用ls -l亲眼确认，而不是相信命令执行成功了。
