内置角色¶
On this page
MongoDB 通过 role-based authorization 来保证数据和命令的访问权限，并且提供了内置的角色，能够提供一个数据库系统中普遍需要的不同级别的访问权限。您可以通过 user-defined roles 进行额外添加。
一个角色赋予了一系列 actions 在 resources 上的权限。
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:
- read¶
Provides the ability to read data on all non-system collections and on the following system collections: system.indexes, system.js, and system.namespaces collections. The role provides read access by granting the following actions:
Database Administration Roles¶
Every database includes the following database administration roles:
- dbAdmin¶
Provides the following actions on the database’s system.indexes, system.namespaces, and system.profile collections:
- collStats
- dbHash
- dbStats
- find
- killCursors
- listIndexes
- listCollections
- dropCollection and createCollection on system.profile only
在 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:
- 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. This role also indirectly provides superuser access to either the database or, if scoped to the admin database, the cluster. The userAdmin role allows users to grant any user any privilege, including themselves.
The userAdmin role explicitly provides the following actions:
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¶
在 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:
- addShard
- appendOplogNote
- applicationMessage
- cleanupOrphaned
- flushRouterConfig
- listShards
- removeShard
- replSetConfigure
- replSetGetConfig
- replSetGetStatus
- replSetStateChange
- resync
Provides the following actions on all databases in the cluster:
On the config database, provides the following privileges:
Resource Actions All collections in the config database system.namespaces collectionsOn the local database, provides the following privileges:
Resource Actions All collections in the local database system.replset collection
- clusterMonitor¶
在 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:
- connPoolStats
- getCmdLineOpts
- getLog
- getParameter
- getShardMap
- hostInfo
- inprog
- listDatabases
- listShards
- netstat
- replSetGetConfig
- replSetGetStatus
- serverStatus
- shardingState
- top
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:
Resource Actions All collections in the config database On the local database, provides the following privileges:
Resource Actions All collections in the local database system.replset,find
- hostManager¶
Provides the ability to monitor and manage servers.
Provides the following actions on the cluster as a whole:
- applicationMessage
- closeAllDatabases
- connPoolSync
- cpuProfiler
- diagLogging
- flushRouterConfig
- fsync
- invalidateUserCache
- killop
- logRotate
- resync
- setParameter
- shutdown
- touch
- unlock
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¶
在 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
- listDatabases action
- listCollections action
- listIndexes action
On the cluster as a whole, provides the
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.indexes, system.namespaces, 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 insert and update action on the config.settings collection.
在 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¶
在 3.4 版更改.
Provides privileges needed to restore data from backups that do not include system.profile collection data. This role is sufficient when restoring data with mongorestore without the --oplogReplay option.
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.
The built-in roles dbAdmin and dbAdminAnyDatabase provide the additional privileges.
If running mongorestore with --oplogReplay, the restore role is insufficient to replay the oplog. To replay the oplog, create a user-defined role that has anyAction on anyResource and 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:
- bypassDocumentValidation
- changeCustomData
- changePassword
- collMod
- createCollection
- createIndex
- createRole
- createUser
- dropCollection
- dropRole
- dropUser
- grantRole
- insert
- revokeRole
- viewRole
- viewUser
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:
- 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.
All-Database Roles¶
在 3.4 版更改.
The admin database provides the following roles that apply to but the local and config databases in a mongod instance and are roughly equivalent to their single-database equivalents:
- readAnyDatabase¶
Provides the same read-only permissions as read, except it applies to it applies to all but the local and config databases in the cluster. The role also provides the listDatabases action on the cluster as a whole.
在 3.4 版更改: Prior to 3.4, readAnyDatabase includes local and config databases. To provide read privileges on the local database, create a user in the admin database with read role in the local database. See also clusterManager and clusterMonitor role for access to the config and local databases.
- readWriteAnyDatabase¶
Provides the same read and write permissions as readWrite, except it applies to all but the local and config databases in the cluster. The role also provides the listDatabases action on the cluster as a whole.
在 3.4 版更改: Prior to 3.4, readWriteAnyDatabase includes local and config databases. To provide readWrite privileges on the local database, create a user in the admin database with readWrite role in the local database. See also clusterManager and clusterMonitor role for access to the config and local databases.
- userAdminAnyDatabase¶
Provides the same access to user administration operations as userAdmin, except it applies to all but the local and config databases in the cluster. The role also provides the following actions on the cluster as a whole:
The role also provides the following actions on the admin.system.users and admin.system.roles collections on the admin database, and on legacy system.users collections from versions of MongoDB prior to 2.6:
在 2.6.4 版更改: userAdminAnyDatabase added the following permissions on the admin.system.users and admin.system.roles collections:
The userAdminAnyDatabase role does not restrict the permissions 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.
在 3.4 版更改: Prior to 3.4, userAdminAnyDatabase includes local and config databases.
- dbAdminAnyDatabase¶
Provides the same access to database administration operations as dbAdmin, except it applies to all but the local and config databases in the cluster. The role also provides the listDatabases action on the cluster as a whole.
在 3.4 版更改: Prior to 3.4, dbAdminAnyDatabase includes local and config databases. To provide dbAdmin privileges on the local database, create a user in the admin database with dbAdmin role in the local database. See also clusterManager and clusterMonitor role 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 readWriteAnyDatabase, dbAdminAnyDatabase, userAdminAnyDatabase, clusterAdmin roles, restore, and backup roles combined.
在 3.4 版更改: The root role includes privileges from the backup role.
在 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.