开启集群内部认证是生产环境强制前提，keyFile为最轻量internal auth方式，需6–1024字节随机二进制数据、600权限，且mongos不支持该配置；启用后客户端须显式指定SCRAM-SHA-256及--authenticationDatabase admin。
开启集群内部认证不是“建议”，而是生产环境的强制前提——不配 keyFile，节点之间根本无法建立可信通信，所谓“恶意替换或加入”在未认证状态下是默认放行的。
为什么没开 internal auth 的集群等于裸奔
副本集或分片集群中，节点靠心跳和数据同步维持状态。但默认情况下，mongod 不校验对端身份：只要 IP 可达、端口开放、配置里写了对方 host，就接受连接并同步 oplog 或 chunk 数据。攻击者只要知道集群拓扑（比如从 config server 的 sh.status() 或日志里泄露的 host 列表），就能伪造一个节点加入——它不会被拒绝，反而可能被选为 primary，或参与数据分发。
- 副本集初始化时若未启用认证，
rs.add("evil:27017")会成功，且新节点立刻开始拉取全量数据 - 分片集群中，恶意节点伪装成 shard 向
mongos注册，sh.addShard()若未限制 IP 或未启用 TLS，也会接受 - config server 如果没认证，元数据可被任意写入，比如篡改
shards集合，把流量导向恶意节点
keyFile 是最轻量也最容易翻车的 internal auth 方式
keyFile 不是密码，也不是密钥交换协议，它只是让所有节点用同一份“暗号”证明自己属于同一个集群。但它极度敏感，稍有偏差就全盘失效：
- 必须在所有节点首次启动前写好，已运行过的节点加
keyFile会直接报Authentication failed，不是重启能解决的 - 文件内容必须是 6–1024 字节随机二进制数据，
openssl rand -base64 756 > /etc/mongod-keyfile是唯一推荐方式；echo "abc" > keyfile会因含换行和非二进制字符导致启动失败 - 权限必须为
600，chmod 600 /etc/mongod-keyfile缺一不可，否则日志只报Permissions on /path/to/keyfile are too open，无其他线索 -
mongos进程不能配security.keyFile，它的配置不支持该字段，加了会导致Failed to load configuration from file，实际是语法校验失败
开了 keyFile 之后，客户端连接反而连不上了
这是最常见的误判：以为 internal auth 和 client auth 是一回事。其实它们完全独立——keyFile 只管节点间通信，不影响你连数据库。但一旦开了 internal auth，mongosh 或应用连接时若仍用老方式，就会卡在“能连上但查不了数据”：
- 必须显式指定
authMechanism=SCRAM-SHA-256，不能依赖默认协商 - 必须带
--authenticationDatabase admin，否则即使用户名密码正确，也会提示not authorized on admin to execute command - 所有 shard 和 config server 都要单独创建管理员用户，
db.createUser({user:"admin", pwd:"...", roles:["root"]})；只在一个节点建，其他节点不认
真正容易被忽略的是：internal auth 一旦启用，就再没有“回退窗口”。你不能临时关掉它去调试某个节点——因为其他节点会立即拒绝与它通信。部署前必须确保 keyFile 分发、权限、配置路径、用户创建全部一次到位。
