Built-In Roles

On this page

MongoDB grants access to data and commands through role-based authorization and provides built-in roles that provide the different levels of access commonly needed in a database system. You can additionally create user-defined roles.

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

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

MongoDB provides the built-in database user and database administration roles on every database. MongoDB provides all other built-in roles only on the admin database.

This section describes the privileges for each built-in role. You can also view the privileges for a built-in role at any time by issuing the rolesInfo command with the showPrivileges and showBuiltinRoles fields both set to true .

Database User Roles

Every database includes the following client roles:

Database Administration Roles

Every database includes the following database administration roles:

Changed in version 2.6.4: dbAdmin added the createCollection for the system.profile collection. Previous versions only had the dropCollection on the system.profile collection.

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

The userAdmin role explicitly provides the following actions:

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

  • clusterManager

    • Changed in version 3.4.

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.

Provides the following actions on the cluster as a whole:

Provides the following actions on all databases in the cluster:

On the config database, provides the following privileges:

ResourceActions
All collections in the config databasecollStats
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:

ResourceActions
All collections in the local databaseenableSharding
insert
moveChunk
remove
splitChunk
splitVector
update
system.replset collectioncollStats
dbHash
dbStats
find
killCursors
listCollections
listIndexes
planCacheRead
  • clusterMonitor
    • Changed in version 3.4.

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

Provides the following actions on the cluster as a whole:

Provides the following actions on all databases in the cluster:

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

On the config database, provides the following privileges:

ResourceActions
All collections in the config databasecollStats
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:

ResourceActions
All collections in the local databasecollStats
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:

Provides the following actions on all databases in the cluster:

Backup and Restoration Roles

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

  • backup
    • Changed in version 3.4.

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 mms.backup collection in the admin database and on the settings collection in the config database.

On anyResource, provides the

On the cluster as a whole, provides the

Provides the find action on the following:

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

Changed in version 3.2.1: The backup role provides additional privileges to back up the system.profile collections that exist when running with database profiling. Previously, users required an additional read 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 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.profileIf 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.
--oplogReplayTo 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:

Provides the following actions on all non -system collections:

Provides the following actions on system.js collection:

Provides the following action on anyResource:

Provides the find action on all the system.namespaces collections in the cluster.

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

Provides the following actions on admin.system.version

Provides the following action on admin.system.roles

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

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.

All-Database Roles

Changed in version 3.4.

The following roles are available only to users on the admin database. These roles provide privileges which apply to all collections except system.* collections on all databases except local and config :

  • readAnyDatabase
    • Provides the same read-only privileges as read on all databases except local and config . readAnyDatabase also provides the listDatabases privilege action on the cluster.

Changed in version 3.4: readAnyDatabase no longer applies to the local and config databases. To provide read privileges on local and config , create a user on the admin database with the read role on the local and config databases.

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

Changed in version 3.4: readWriteAnyDatabase no longer applies to the local and config databases. To provide read and write privileges on local and config , create a user on the admin database with the readWrite role on the local and config databases.

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

The role also 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:

Changed in version 2.6.4: userAdminAnyDatabase added the following privilege actions on the admin.system.users and admin.system.roles collections:

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.

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

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

  • dbAdminAnyDatabase
    • Provides the same access to database administration operations as dbAdmin on all databases except local and config . dbAdminAnyDatabase also provides the listDatabases privilege action on the cluster.

Changed in version 3.4: dbAdminAnyDatabase no longer applies to the local and config databases. To provide dbAdmin privileges on local and config , create a user on the admin database with the dbAdmin role on the local and config databases.

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:

The following role provides full privileges on all resources:

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

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

The root role includes privileges from the restore role.

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.