Built-In Roles (original) (raw)

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.

System collections include those in:

For details, see System Collections.

Non-system collections are those not in namespaces in the previous list.

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.

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 therolesInfo command with the showPrivileges andshowBuiltinRoles fields both set to true.

Although database users in MongoDB Atlas have different built-in roles than self-hosted deployments, the built-in roles for each type of deployment are built from the same set of privilege actions.

For the built-in database user roles for deployments hosted in MongoDB Atlas, see Altas Built-In Roles and Privileges.

You can create database users and assign built-in roles in the MongoDB Atlas user interface. To learn more, see Add Database Users.

MongoDB provides the following built-in roles in self-hosted deployments:

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

The role does not provide privileges to directly access thesystem.namespaces collection directly.

The role provides read access by granting the following actions:

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 privileges (including databases for which the user has privileges on specific collections) if the command is run withauthorizedDatabases 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:

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:

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 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 can assign themselves any privilege on that database. Granting theuserAdmin role on the admin database has further security implications as this indirectly providessuperuser access to a cluster. With adminscope a user with the userAdmin role can grant cluster-wide roles or privileges including userAdminAnyDatabase.

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 localdatabases, which are used in sharding and replication, respectively. Additionally, the role provides thequerySettings action.

On the config database, permits the following actions:

On the local database, permits the following actions:

clusterMonitor

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

Permits the following actions on the cluster as a whole:

connPoolStatsgetCmdLineOptsgetDefaultRWConcerngetLoggetParametergetShardMaphostInfoinprog listDatabaseslistSessionslistShardsreplSetGetConfigreplSetGetStatusserverStatusshardingStatetop

Permits the following actions on all databases in the cluster:

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

On the config database, permits the following actions:

On the local database, permits the following actions:

directShardOperations

Starting in MongoDB 8.0, you can use thedirectShardOperations role to perform maintenance operations that require you to execute commands directly against a shard.

Warning

Running commands using the directShardOperations role can cause your cluster to stop working correctly and may cause data corruption. Only use the directShardOperations role for maintenance purposes or under the guidance of MongoDB support. Once you are done performing maintenance operations, stop using thedirectShardOperations role.

enableSharding

Provides the ability to enable sharding for a collection and modify existing shard keys.

Provides the following actions on all non-system collections:

hostManager

Provides the ability to monitor and manage servers.

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

applicationMessagecloseAllDatabasescompact (New in version 7.3)connPoolSyncflushRouterConfigfsync invalidateUserCachekillAnyCursorkillAnySessionkilloplogRotateoidReset resyncrotateCertificates (New in version 5.0)setParametershutdowntouchunlock

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

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 usemongodump to back up an entire mongod instance.

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

On anyResource, provides the

On the cluster as a whole, provides the

Provides the find action on the following:

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

The backup role provides additional privileges to back up the system.profilecollection 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:

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 following actions on all non-system collections on theconfig 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.usersand 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 theuser management methods.

Provides the following action on the .system.viewscollection:

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

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

readAnyDatabase

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

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

readWriteAnyDatabase

Provides the same privileges as readWrite on all databases except local and config. The role also provides:

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 the following privilege actions on the cluster:

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

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 andclusterMonitor roles for access to the config andlocal 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 andclusterMonitor roles for access to the config andlocal databases.

Starting in MongoDB 5.0, dbAdminAnyDatabase includes theapplyOps privilege action.

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:

root

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

Also provides the following privilege actions:

Changed in version 6.0: The root role includes find andremove privileges on the system.preimagescollection in the config database.

__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.