Built-In Roles

MongoDB grants access to data and commands through role-basedauthorization and provides built-in roles that provide the differentlevels of access commonly needed in a database system. You can additionallycreate user-defined roles.

A role grants privileges to perform sets of actions on defined resources. Agiven role applies to the database on which it is defined and can grant accessdown to a collection level of granularity.

Each of MongoDB’s built-in roles defines access at the database level for allnon-system collections in the role’s database and at the collection levelfor all system collections.

MongoDB provides the built-in database user anddatabase administration roles onevery database. MongoDB provides all other built-in roles only on theadmin database.

This section describes the privileges for each built-in role. You can alsoview the privileges for a built-in role at any time by issuing therolesInfo command with the showPrivileges andshowBuiltinRoles fields both set to true.

Database User Roles

Every database includes the following client roles:

The role provides read access by granting the following actions:

  • changeStream
  • collStats
  • dbHash
  • dbStats
  • find
  • killCursors
  • listIndexes
  • listCollections
  • For MongoDB 4.0.6+:
  • If the user does not have the listDatabasesprivilege action, users can run the listDatabasescommand to return a list of databases for which the user hasprivileges (including databases for which the user has privilegeson specific collections) if the command is run withauthorizedDatabases option unspecified or set to true.
  • For MongoDB 4.0.5:
  • If the user does not have the listDatabasesprivilege action, users can run the listDatabasescommand to return a list of databases for which the user has thefind action privilege if the command is run withauthorizedDatabases option unspecified or set to true.
  • For MongoDB 4.0.0-4.0.4:
  • If the user does not have the listDatabasesprivilege action, users can run the listDatabasescommand to return a list of databases for which the user has thefind action privilege.
  • readWrite
  • Provides all the privileges of the read role plus ability tomodify data on all non-system collections and the system.js collection.

The role provides the following actions on those collections:

Database Administration Roles

Every database includes the following database administration roles:

  • dbAdmin
  • Provides the ability to perform administrative tasks such asschema-related tasks, indexing, and gathering statistics. This roledoes not grant privileges for user and role management.

Provides the following actions on thedatabase’s system.indexes,system.namespaces, andsystem.profile collections:

Changed in version 2.6.4: dbAdmin added the createCollectionaction for the system.profilecollection. Previous versions only had thedropCollection action on the system.profile collection.

Provides the following actions on all non-systemcollections. This role does not include full read access on non-system collections:

  • dbOwner
  • The database owner can perform any administrative action on the database.This role combines the privileges granted by the readWrite,dbAdmin and userAdmin roles.
  • userAdmin
  • Provides the ability to create and modify roles and users on thecurrent database. Since the userAdmin role allowsusers to grant any privilege to any user, including themselves,the role also indirectly provides superuseraccess to either the database or, if scoped to the admindatabase, the cluster.

The userAdmin role explicitly provides the following actions:

Warning

It is important to understand the security implications of granting theuserAdmin role: a user with this role for a database canassign themselves any privilege on that database. Granting theuserAdmin role on the admin database has furthersecurity implications as this indirectly providessuperuser access to a cluster. With adminscope a user with the userAdmin role can grant cluster-wideroles or privileges including userAdminAnyDatabase.

Cluster Administration Roles

The admin database includes the following roles for administering thewhole system rather than just a single database. These roles include but arenot limited to replica set and sharded cluster administrativefunctions.

  • clusterManager

Changed in version 3.4.

Provides management and monitoring actions on the cluster. Auser with this role can access the config and localdatabases, which are used in sharding and replication,respectively.

Provides the following actions on the cluster as a whole:

ResourceActionsAll collections in the config database

collStats

dbHash

dbStats

enableSharding

find

insert

killCursors

listCollections

listIndexes

moveChunk

planCacheRead

remove

splitChunk

splitVector

update

system.indexes,

system.js,

system.namespaces collections

collStats

dbHash

dbStats

find

killCursors

listCollections

listIndexes

planCacheRead

On the local database, provides the following privileges:

ResourceActionsAll collections in the local database

  • clusterMonitor

Changed in version 3.4.

Provides read-only access to monitoring tools, such as the MongoDB Cloud Managerand Ops Manager monitoring agent.

Provides the following actions on the cluster as a whole:

On the config database, provides the following privileges:

ResourceActionsAll collections in the config database

collStats

dbHash

dbStats

find

getShardVersion

indexStats

killCursors

listCollections

listIndexes

planCacheRead

system.indexes,

system.js,

system.namespaces collections

collStats

dbHash

dbStats

find

killCursors

listCollections

listIndexes

planCacheRead

On the local database, provides the following privileges:

ResourceActionsAll collections in the local database

collStats

dbHash

dbStats

find

getShardVersion

indexStats

killCursors

listCollections

listIndexes

planCacheRead

system.indexes,

system.js,

system.namespaces collections

collStats

dbHash

dbStats

find

killCursors

listCollections

listIndexes

planCacheRead

system.replset,

system.profile,

find

  • hostManager
  • Provides the ability to monitor and manage servers.

Provides the following actions on the cluster as a whole:

Backup and Restoration Roles

The admin database includes the following roles for backing up andrestoring data:

Provides the insert and update actionson themms.backup collection in the admin database and on thesettings collection in the config database.

On anyResource, provides the

Changed in version 3.2.1: The backup role provides additional privileges to backup the system.profilecollection that exists when running with database profiling. Previously, users requiredread access on this collection.

  • restore

Changed in version 3.6: Provides convertToCapped on non-system collections.

Provides the necessary privileges to restore data from backups if the datadoes not include system.profile collectiondata and you run mongorestore without the —oplogReplay option.

If the backup data includes system.profile collection data or you run with—oplogReplay, you needadditional privileges:

system.profileIf the backup data includes system.profile collection data and the target databasedoes not contain the system.profilecollection, mongorestore attempts to create the collectioneven though the program does not actually restore system.profiledocuments. As such, the user requires additional privileges to performcreateCollection and convertToCappedactions on the system.profilecollection for a database.

Both the built-in roles dbAdmin anddbAdminAnyDatabase provide the additional privileges.—oplogReplayTo run with —oplogReplay, create a user-defined role that has anyAction onanyResource.

Grant only to users who must run mongorestorewith —oplogReplay.

Provides the following action on the cluster as a whole:

Provides the following actions on all non-system collections on theconfig and the local databases:

All-Database Roles

Changed in version 3.4.

The following roles are available on the admin database and provideprivileges which apply to all databases except local andconfig:

  • readAnyDatabase
  • Provides the same read-only privileges as read on all databasesexcept local and config. The role also provides thelistDatabases action on the cluster as a whole.

Changed in version 3.4: Prior to 3.4, readAnyDatabase includes local andconfig databases. To provide read privileges on thelocal database, create a user in the admin database withread role in the local database.

See also the clusterManager andclusterMonitor roles for access to the config andlocal databases.

  • readWriteAnyDatabase
  • Provides the same privileges as readWrite onall databases except local and config. The role alsoprovides the listDatabases action on the cluster as awhole.

Changed in version 3.4: Prior to 3.4, readWriteAnyDatabase includes localand config databases. To provide readWrite privileges onthe local database, create a user in the admin databasewith readWrite role in the local database.

See also the clusterManager andclusterMonitor roles for access to the config andlocal databases.

  • userAdminAnyDatabase
  • Provides the same access to user administration operations asuserAdmin on all databases except local andconfig.

userAdminAnyDatabase also provides thefollowing privilege actions on the cluster:

Changed in version 2.6.4: userAdminAnyDatabase added the following privilegeactions on the admin.system.users andadmin.system.roles collections:

The userAdminAnyDatabase role does not restrict the privilegesthat a user can grant. As a result, userAdminAnyDatabase userscan grant themselves privileges in excess of their currentprivileges and even can grant themselves all privileges, even though therole does not explicitly authorize privileges beyond user administration.This role is effectively a MongoDB system superuser.

Changed in version 3.4: userAdminAnyDatabase no longerapplies to the local and config databases.

See also the clusterManager andclusterMonitor roles for access to the config andlocal databases.

  • dbAdminAnyDatabase
  • Provides the same privileges as dbAdmin onall databases except local and config. The role alsoprovides the listDatabases action on the cluster asa whole.

Changed in version 3.4: Prior to 3.4, dbAdminAnyDatabase includes localand config databases. To provide dbAdmin privileges onthe local database, create a user in the admin databasewith dbAdmin role in the local database.

See also the clusterManager andclusterMonitor roles for access to the config andlocal databases.

Superuser Roles

Several roles provide either indirect or direct system-wide superuser access.

The following roles provide the ability to assign any user any privilege onany database, which means that users with one of these roles can assignthemselves any privilege on any database:

The following role provides full privileges on all resources:

Changed in version 3.4: The root role includes privileges from thebackup role.

Changed in version 3.0.7: The root has the validate privilegeaction on system. collections. Previously, rootdoes not include any access to collections that begin with thesystem. prefix other than system.indexes andsystem.namespaces.

The root role includes privileges from therestore role.

Internal Role

  • system[]($82c8802495885e14.md#system)
  • MongoDB assigns this role to user objects that represent cluster members,such as replica set members and mongos instances. The roleentitles its holder to take any action against any object in the database.

Do not assign this role to user objects representing applications orhuman administrators, other than in exceptional circumstances.

If you need access to all actions on all resources, for example torun applyOps commands, do not assign this role.Instead, create a user-defined role thatgrants anyAction on anyResource andensure that only the users who need access to these operations havethis access.