Built-In Roles

Database User Roles

Every database includes the following client roles:

read

Provides the ability to read data on all non-system collections and the system.js collection.

Note

Starting in MongoDB 4.2, the role no longer provides privileges to access the system.namespaces collection directly. Direct access to the collection has been deprecated since MongoDB 3.0.

In earlier versions, the role provided the aforementioned privilege actions on the system.namespaces collection, thereby allowing direct access.

The role provides read access by granting the following actions:

• changeStream

• collStats

• dbHash

• dbStats

• find

• killCursors

• listIndexes

• listCollections

If the user does not have the listDatabases privilege action, users can run the listDatabases command to return a list of databases for which the user has privileges (including databases for which the user has privileges on specific collections) if the command is run with authorizedDatabases option unspecified or set to true.

readWrite

Provides all the privileges of the read role plus ability to modify data on all non-system collections and the system.js collection.

The role provides the following actions on those collections:

• collStats

• convertToCapped

• createCollection

• dbHash

• dbStats

• dropCollection

• createIndex

• dropIndex

• find

• insert

• killCursors

• listIndexes

• listCollections

• remove

• renameCollectionSameDB

• update

Database Administration Roles

Every database includes the following database administration roles:

dbAdmin

Provides the ability to perform administrative tasks such as schema-related tasks, indexing, and gathering statistics. This role does not grant privileges for user and role management.

Specifically, the role provides the following privileges:

Resource	Permitted Actions
system.profile	changeStream collStats convertToCapped createCollection dbHash dbStats dropCollection find killCursors listCollections listIndexes planCacheRead Note Aside Starting in version 4.2, MongoDB removes the system.indexes and system.namespaces collections. As such, the dbAdmin role no longer provides privileges to access these collections. Direct access to these collections has been deprecated since MongoDB 3.0. In earlier versions, the dbAdmin role provides the aforementioned privilege actions (except dropCollection and createCollection) on system.indexes and system.namespaces collections, thereby allowing direct access to the system.indexes and system.namespaces collections.
All non-system collections (i.e. database resource)	bypassDocumentValidation collMod collStats compact convertToCapped createCollection createIndex dbStats dropCollection dropDatabase dropIndex enableProfiler listCollections listIndexes planCacheIndexFilter planCacheRead planCacheWrite reIndex renameCollectionSameDB storageDetails validate For these collections, dbAdmin does not include full read access (i.e. find).

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 the current database. Since the userAdmin role allows users to grant any privilege to any user, including themselves, the role also indirectly provides superuser access to either the database or, if scoped to the admin database, the cluster.

The userAdmin role explicitly provides the following actions:

• changeCustomData

• changePassword

• createRole

• createUser

• dropRole

• dropUser

• grantRole

• revokeRole

• setAuthenticationRestriction

• viewRole

• viewUser

Warning

It is important to understand the security implications of granting the userAdmin role: a user with this role for a database can assign themselves any privilege on that database. Granting the userAdmin role on the admin database has further security implications as this indirectly provides superuser access to a cluster. With admin scope a user with the userAdmin role can grant cluster-wide roles or privileges including userAdminAnyDatabase.

Cluster Administration Roles

The admin database includes the following roles for administering the whole system rather than just a single database. These roles include but are not limited to replica set and sharded cluster administrative functions.

clusterAdmin

Provides the greatest cluster-management access. This role combines the privileges granted by the clusterManager, clusterMonitor, and hostManager roles. Additionally, the role provides the dropDatabase action.

clusterManager

Provides management and monitoring actions on the cluster. A user with this role can access the config and local databases, which are used in sharding and replication, respectively.

Resource	Actions
cluster	addShard appendOplogNote applicationMessage cleanupOrphaned flushRouterConfig getDefaultRWConcern (New in version 4.4) listSessions listShards removeShard replSetConfigure replSetGetConfig replSetGetStatus replSetStateChange resync setDefaultRWConcern (New in version 4.4) setFeatureCompatibilityVersion
All databases	clearJumboFlag (New in 4.2.3) enableSharding refineCollectionShardKey (New in 4.4) moveChunk splitVector clusterManager provides additional privileges for the config and local databases.

On the config database, permits the following actions:

Resource	Actions
All non-system collections in the config database	collStats dbHash dbStats enableSharding find insert killCursors listCollections listIndexes moveChunk planCacheRead remove splitVector update
system.js	collStats dbHash dbStats find killCursors listCollections listIndexes planCacheRead Note Aside Starting in version 4.2, MongoDB removes the system.indexes and system.namespaces collections. As such, the clusterManager role no longer provides privileges to access these collections. Direct access to these collections has been deprecated since MongoDB 3.0. In earlier versions, the clusterManager role provides the aforementioned privilege actions on the system.indexes and system.namespaces collections, thereby allowing direct access to the system.indexes and system.namespaces collections.

On the local database, permits the following actions:

Resource	Actions
All non-system collections in the local database	enableSharding insert moveChunk remove splitVector update
system.replset collection	collStats dbHash dbStats find killCursors listCollections listIndexes planCacheRead

clusterMonitor

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

Permits the following actions on the cluster as a whole:

connPoolStats getCmdLineOpts getDefaultRWConcern (New in version 4.4) getLog getParameter getShardMap hostInfo inprog listDatabases

listSessions listShards netstat replSetGetConfig replSetGetStatus serverStatus shardingState top

Permits the following actions on all databases in the cluster:

• collStats

• dbStats

• getShardVersion

• indexStats

• useUUID

Permits the find action on all system.profile collections in the cluster.

On the config database, permits the following actions:

Resource	Actions
All non-system collections in the config database	collStats dbHash dbStats find getShardVersion indexStats killCursors listCollections listIndexes planCacheRead
system.js collection	collStats dbHash dbStats find killCursors listCollections listIndexes planCacheRead Note Aside Starting in version 4.2, MongoDB removes the system.indexes and system.namespaces collections. As such, the clusterMonitor role no longer provides privileges to access these collections. Direct access to these collections has been deprecated since MongoDB 3.0. In earlier versions, the role provides the aforementioned privilege actions on the system.indexes and system.namespaces collections, thereby allowing direct access to the system.indexes and system.namespaces collections.

On the local database, permits the following actions:

Resource	Actions
All collections in the local database	collStats dbHash dbStats find getShardVersion indexStats killCursors listCollections listIndexes planCacheRead
system.js collection	collStats dbHash dbStats find killCursors listCollections listIndexes planCacheRead Starting in version 4.2, MongoDB removes the system.indexes and system.namespaces collections. As such, the clusterMonitor role no longer provides privileges to access these collections. Direct access to these collections has been deprecated since MongoDB 3.0. In earlier versions, the role provides the aforementioned privilege actions on the system.indexes and system.namespaces collections, thereby allowing direct access to the system.indexes and system.namespaces collections.
system.replset, system.profile,	find

hostManager

Provides the ability to monitor and manage servers.

On the cluster as a whole, provides the following actions:

applicationMessage closeAllDatabases connPoolSync flushRouterConfig fsync invalidateUserCache

killAnyCursor killAnySession killop logRotate oidReset

resync setParameter shutdown touch unlock

Changed in version 4.4: Starting in version 4.4, hostManager no longer provides the cpuProfiler privilege action on the cluster.

On all databases in the cluster, provides the following actions:

• killCursors

Backup and Restoration Roles

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

backup

Provides minimal privileges needed for backing up data. This role provides sufficient privileges to use the MongoDB Cloud Manager backup agent, Ops Manager backup agent, or to use mongodump to back up an entire mongod instance.

Provides the insert and update actions on the settings collection in the config database.

On anyResource, provides the

• listDatabases action

• listCollections action

• listIndexes action

On the cluster as a whole, provides the

• appendOplogNote

• getParameter

• listDatabases

• serverStatus (Starting in MongoDB 4.2)

Provides the find action on the following:

• all non-system collections in the cluster, including those in the config and local databases

• The following system collections in the cluster:

  system.js, and system.profile

• The admin.system.users and admin.system.roles collections

• The config.settings collection

• Legacy system.users collections from versions of MongoDB prior to 2.6

Provides the insert and update actions on the config.settings collection.

The backup role provides additional privileges to back up the system.profile collection that exists when running with database profiling.

restore

Provides convertToCapped on non-system collections.

Provides the necessary privileges to restore data from backups if the data does not include system.profile collection data and you run mongorestore without the --oplogReplay option.

If the backup data includes system.profile collection data or you run with --oplogReplay, you need additional privileges:

system.profile

If the backup data includes system.profile collection data and the target database does not contain the system.profile collection, mongorestore attempts to create the collection even though the program does not actually restore system.profile documents. As such, the user requires additional privileges to perform createCollection and convertToCapped actions on the system.profile collection for a database. Both the built-in roles dbAdmin and dbAdminAnyDatabase provide the additional privileges.

--oplogReplay

To run with --oplogReplay, create a user-defined role that has anyAction on anyResource. Grant only to users who must run mongorestore with --oplogReplay.

Provides the following action on the cluster as a whole:

• getParameter

Provides the following actions on all non-system collections:

• bypassDocumentValidation

• changeCustomData

• changePassword

• collMod

• convertToCapped

• createCollection

• createIndex

• createRole

• createUser

• dropCollection

• dropRole

• dropUser

• grantRole

• insert

• revokeRole

• viewRole

• viewUser

Provides the following actions on system.js collection:

• bypassDocumentValidation

• collMod

• createCollection

• createIndex

• dropCollection

• insert

Provides the following action on anyResource:

• listCollections

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

• bypassDocumentValidation

• collMod

• createCollection

• createIndex

• dropCollection

• insert

Provides the following actions on admin.system.version

• bypassDocumentValidation

• collMod

• createCollection

• createIndex

• dropCollection

• find

• insert

Provides the following action on admin.system.roles

• createIndex

Provides the following actions on admin.system.users and legacy system.users collections:

• bypassDocumentValidation

• collMod

• createCollection

• createIndex

• dropCollection

• find

• insert

• remove

• update

Although, restore includes the ability to modify the documents in the admin.system.users collection using normal modification operations, only modify these data using the user management methods.

Note

Aside

Starting in version 4.2, MongoDB removes the system.namespaces collection. As such, the restore role no longer provides privileges to access these collections. Direct access to these collections has been deprecated since MongoDB 3.0.

In earlier versions, the restore role provides the aforementioned privilege actions on the system.namespaces collection, thereby allowing direct access to the collection.

All-Database Roles

The following roles are available on the admin database and provide privileges which apply to all databases except local and config:

readAnyDatabase

Provides the same read-only privileges as read on all databases except local and config. The role also provides the listDatabases action on the cluster as a whole.

See also the clusterManager and clusterMonitor roles for access to the config and local databases.

readWriteAnyDatabase

Provides the same privileges as readWrite on all databases except local and config. The role also provides the listDatabases action on the cluster as a whole.

See also the clusterManager and clusterMonitor roles for access to the config and local databases.

userAdminAnyDatabase

Provides the same access to user administration operations as userAdmin on all databases except local and config.

userAdminAnyDatabase also provides the following privilege actions on the cluster:

• authSchemaUpgrade

• invalidateUserCache

• listDatabases

The role provides the following privilege actions on the system.users and system.roles collections on the admin database, and on legacy system.users collections from versions of MongoDB prior to 2.6:

• collStats

• dbHash

• dbStats

• find

• killCursors

• planCacheRead

• createIndex

• dropIndex

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

See also the clusterManager and clusterMonitor roles for access to the config and local databases.

dbAdminAnyDatabase

Provides the same privileges as dbAdmin on all databases except local and config. The role also provides the listDatabases action on the cluster as a whole.

See also the clusterManager and clusterMonitor roles for access to the config and local 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 on any database, which means that users with one of these roles can assign themselves any privilege on any database:

• dbOwner role, when scoped to the admin database

• userAdmin role, when scoped to the admin database

• userAdminAnyDatabase role

The following role provides full privileges on all resources:

root

Provides access to the operations and all the resources of the following roles combined:

• readWriteAnyDatabase

• dbAdminAnyDatabase

• userAdminAnyDatabase

• clusterAdmin

• restore

• backup

Also provides the validate privilege action on system. collections.

Internal Role

__system

MongoDB assigns this role to user objects that represent cluster members, such as replica set members and mongos instances. The role entitles its holder to take any action against any object in the database.

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

If you need access to all actions on all resources, for example to run applyOps commands, do not assign this role. Instead, create a user-defined role that grants anyAction on anyResource and ensure that only the users who need access to these operations have this access.