MongoDB 用户管理详解：admin 用户 vs 数据库用户

在 MongoDB 中，用户建在哪个库决定了它的作用范围和管理方式，这一点和 MySQL 很不一样，也是新手最容易绕进去的地方。本文讲清楚两种用户的区别、各自的使用场景、 完整的管理操作，以及连接时那个必须写对的 authSource。

零、先确认认证是开着的

MongoDB 默认不开认证。 没开的时候，你建的用户一个都不生效——任何人连上来 都是完全权限，db.createUser() 只是往集合里写了几行数据而已。

编辑 /etc/mongod.conf：

security:
  authorization: enabled

改完重启，之后所有操作都需要认证：

sudo systemctl restart mongod

顺序很重要：先在没开认证的状态下建好第一个管理员账号，再打开认证重启。 反过来的话，认证开着但一个用户都没有，你就把自己关在门外了 （只能用 --noauth 重启一次救回来）。

一、两种类型的用户

1. admin 数据库创建的用户（全局用户）

这种用户是在 admin 数据库中创建的，可以访问多个数据库，并对多个数据库赋予不同权限。

use admin

db.createUser({
  user: "adminUser",
  pwd: "secure123",
  roles: [
    { role: "readWrite", db: "sales" },
    { role: "read", db: "analytics" }
  ]
})

特点

• 用户信息存储在 admin 库；
• 可以管理和访问多个数据库；
• 适合平台管理员、系统服务等集中权限场景。

使用场景

• 运维或 DevOps 脚本；
• 应用需要访问多个数据库；
• 多库统一管理权限。

2. 普通数据库创建的用户（局部用户）

这种用户只能在某一个数据库中创建，默认仅能访问该数据库。

use appdb

db.createUser({
  user: "appUser",
  pwd: "pass123",
  roles: [ { role: "readWrite", db: "appdb" } ]
})

特点

• 用户信息只存在于当前库；
• 默认只能访问当前数据库；
• 隔离性好，更安全。

使用场景

• Web 应用访问自己的数据；
• 每个业务数据库独立授权；
• 多租户系统中的租户隔离。

二、常见用户管理操作

创建用户

db.createUser({
  user: "user1",
  pwd: "123456",
  roles: [ { role: "readWrite", db: "mydb" } ]
})

修改用户密码

db.updateUser("user1", { pwd: "newpass" })

要在用户所属数据库执行。

追加权限

要在这个用户所在的库里执行——用户建在 admin 就 use admin， 建在 appdb 就 use appdb。跑错库会报 User 'user1' not found：

db.grantRolesToUser("user1", [
  { role: "read", db: "logdb" }
])

撤销某个权限

db.revokeRolesFromUser("user1", [
  { role: "read", db: "logdb" }
])

删除用户

db.dropUser("user1")

查看用户与权限

db.getUsers()
db.getUser("user1")

三、连接时的 authSource

这是实际用起来最容易卡住的一个点。认证在哪个库做，和你要访问哪个库，是两件事。

用户建在 admin 里、要访问 sales，连接串必须告诉 MongoDB 去 admin 认证：

mongodb://adminUser:secure123@127.0.0.1:27017/sales?authSource=admin

不写 authSource，驱动默认拿路径上那个库（这里是 sales）当认证库， 于是去 sales 里找 adminUser——找不到，报

Authentication failed.

密码明明是对的，但错误信息只说认证失败，很容易往密码上找原因。

四、不能直接修改用户名

MongoDB 不支持改用户名，推荐做法：

1. 创建新用户；
2. 复制权限；
3. 删除旧用户。

db.createUser({
  user: "newUser",
  pwd: "abc123",
  roles: [ { role: "readWrite", db: "mydb" } ]
})

db.dropUser("oldUser")

五、最佳实践建议

• 管理类账号建在 admin，应用账号建在自己的业务库里；
• 一个应用一个账号，不要几个站共用一个——出事时你没法知道是谁泄的， 改密码也会波及所有人；
• 只给需要的权限：只读的业务给 read，别顺手给 readWrite；
• 例子里的 secure123、123456 只是占位，真实密码用随机串， 并且不要写进代码仓库。

MongoDB 的用户管理不只关系数据安全，也决定了系统好不好维护。分清 admin 用户和 局部用户各自的位置，再把 authSource 写对，权限模型就清晰了。

数据库账号该怎么按站拆分、怎么限制来源 IP，MySQL 那边的思路是相通的， 可以接着看 MySQL 用户最佳实践。