keyfile 是 mongodb 副本集节点间通信的最低安全门槛，通过共享密钥实现 hmac 身份认证，需统一配置、严格权限（chmod 400）、绑定 clusterauthmode: keyfile，否则静默失效。
Keyfile 是 MongoDB 副本集节点间通信的最低安全门槛
不配置 Keyfile，副本集节点之间默认以明文交换心跳、oplog、配置变更等所有内部消息。攻击者只要能接入同一网络（比如云服务器 VPC 内网被横向渗透），就能伪造成员身份、劫持选举、甚至清空整个集群——这不是理论风险，而是 mongod 启动时未启用访问控制下的默认行为。
Keyfile 的本质是共享密钥认证：所有成员用同一个文件内容生成 HMAC 签名，验证彼此身份。它不依赖外部服务（如 LDAP）、不涉及证书链管理，是 MongoDB 官方推荐的最轻量、最可控的内部通信保护方式。
不设 Keyfile 就等于关闭副本集身份校验开关
即使你为应用用户配置了 SCRAM-SHA-256 认证、启用了 authorization: enabled，这些只约束客户端连接，对 rs.add()、replSetGetStatus、心跳包等内部通信完全无效。副本集协议层本身不校验调用方是不是合法成员，除非你显式开启 keyFile 或 x509。
-
keyFile必须在所有节点的mongod.conf中配置，且路径一致、权限严格（Linux 下必须chmod 400，否则启动失败） - 一旦启用
keyFile，所有节点必须重启；已有副本集无法热加载，否则新旧节点因认证不匹配直接失联 - Keyfile 文件内容不能含空格或换行，长度建议 6–1024 字节，可用
openssl rand -base64 756 > keyfile生成
为什么不用 x509 或 LDAP 替代 Keyfile？
不是不能用，而是没必要复杂化。x509 要求每个节点有独立证书+CA 链，部署/轮换成本高；LDAP 依赖外部服务可用性，且只管用户认证，不解决节点间通信签名问题。Keyfile 唯一目标就是让 replSetHeartbeat 请求带上可验证的签名，其他都是冗余。
注意：keyFile 和 clusterAuthMode 是绑定关系。必须同时设置：
security: keyFile: /etc/mongod/keyfile clusterAuthMode: keyFile
若漏掉 clusterAuthMode: keyFile，MongoDB 会忽略 keyFile 配置，静默退回到无认证模式——这个错误不会报错，只会让你以为“已经开了”，实际毫无防护。
Keyfile 生效后，常见故障点都在权限和一致性上
最常踩的坑不是加密逻辑，而是运维细节：
- 文件权限不对：
mongod进程用户（如mongod）必须有读取权，但其他用户不能读，否则启动报permissions on the keyfile are too open - 内容不一致：任意一个节点的 keyfile 文件内容与其他节点不同，该节点将反复尝试重连、日志刷满
no valid authentication mechanism - 忘记更新仲裁节点（arbiter）：仲裁节点也要配同样
keyFile，否则主节点拒绝其投票，导致选举卡住 - 备份恢复后没同步 keyfile：从快照恢复的节点若没同步 keyfile，会以“陌生成员”身份被踢出集群
Keyfile 不提供加密传输，只做身份认证；如果需要加密通信，得额外开启 TLS/SSL（net.ssl.mode: requireSSL），这是另一层事。别指望一个配置解决所有安全问题。
