MongoDB数据库用户存储位置选择及最佳实践咨询

Great question—user management in MongoDB is all about following the principle of least privilege and understanding how the database handles authentication across different contexts. Let’s break down your questions one by one:

Should you create users in their exclusive database instead of admin? #

Absolutely—this is actually a best practice for regular application users who only need access to a single database. Here’s why:

• Least privilege principle: By creating the user directly in their target database, you can restrict their permissions exclusively to that database. They won’t have any access to admin or other databases by default, which reduces your system’s attack surface.
• Clearer management: Keeping users tied to the database they interact with makes it easier to track permissions and clean up unused accounts later, since you don’t have to sift through a single admin collection for all users.

When you create a user in a non-admin database, MongoDB stores their credentials in that database’s system.users collection, and their roles are scoped to that database (unless explicitly granted cross-db permissions, which you should avoid for regular users).

Admin Database vs. Local Database: Where to put users? #

Admin Database #

The admin database is reserved for specific use cases:

• Cluster-level administrative users: Users who need permissions like clusterAdmin (managing replica sets/shards), userAdminAnyDatabase (creating users across all databases), or backup (performing cluster-wide backups).
• Cross-database users: If a user needs access to multiple databases, creating them in admin makes sense (since you can grant roles for multiple databases from this central location).

By default, MongoDB uses the admin database for authentication if you don’t specify a database when connecting (e.g., mongosh -u myuser -p without --authenticationDatabase).

Local Database #

Never create users in the local database—here’s the critical reason:
The local database is node-specific. Its data is not replicated to other nodes in a replica set, and it doesn’t participate in sharding. If you create a user here, only the single node you created them on will recognize their credentials. If your replica set fails over to another node, or you’re working with a sharded cluster, that user will no longer be able to authenticate. The local database is only for storing node-local metadata (like replica set configuration) — never user accounts.

Example Commands #

Creating a User in Their Exclusive Database #

// Switch to the target database
use my_app_db

// Create a user with read/write access only to this database
db.createUser({
  user: "app_service_user",
  pwd: "your_strong_password_here",
  roles: [
    { role: "readWrite", db: "my_app_db" }
  ]
})

Creating an Admin User in the Admin Database #

use admin

// Create a cluster-level admin with user management permissions
db.createUser({
  user: "cluster_manager",
  pwd: "super_secure_admin_password",
  roles: [
    "clusterAdmin",
    "userAdminAnyDatabase"
  ]
})

Quick Summary #

• Regular app users: Create directly in their target database (follows the least privilege principle).
• Admin/cluster users: Create in admin for global/cluster-wide permissions.
• Local database: Avoid storing users here entirely—reserved for node-local metadata only.

内容的提问来源于stack exchange，提问作者mortb