Built-In Roles
在本页面
MongoDB 通过role-based authorization授予对数据和命令的访问权限，并提供内置角色，这些角色提供数据库系统中通常需要的不同访问级别。您还可以创建user-defined roles。
角色授予特权以对定义的resources执行actions集。给定角色适用于在其上定义了该角色的数据库，并且可以授予访问权限，直至达到粒度的收集级别。
MongoDB 的每个内置角色在角色级别的数据库中对所有* non *系统集合的访问权限在数据库级别定义，而在所有system collections的集合级别定义访问权限。
MongoDB 在每个数据库上提供内置的database user和database administration角色。 MongoDB 仅在admin数据库上提供所有其他内置角色。
本节介绍每个内置角色的特权。您还可以通过发出rolesInfo命令并将showPrivileges和showBuiltinRoles字段都设置为true来随时查看内置角色的特权。
数据库用户角色
每个数据库都包含以下 Client 端角色：
read- 提供读取所有* non *系统集合以及以下系统集合上的数据的能力：system.indexes，system.js和system.namespaces集合。该角色通过授予以下actions来提供读取访问权限：
readWrite
数据库 Management 角色
每个数据库都包含以下数据库 Management 角色：
dbAdmin- 在数据库的system.indexes，system.namespaces和system.profile集合上提供以下actions：
在版本 2.6.4 中进行了更改：dbAdmin为system.profile集合添加了createCollection。以前的版本在system.profile集合中只有dropCollection。
对所有* non 系统集合提供以下操作。该角色不*包括对非系统集合的完全读取访问权限：
dbOwneruserAdmin- 提供创建和修改数据库角色和用户的功能。在数据库上具有此角色的用户可以为该数据库的任何用户(包括他们自己)分配任何角色或特权。
userAdmin角色显式提供以下操作：
Warning
重要的是要了解授予userAdmin角色的安全隐患：具有此角色的数据库用户可以向自己分配该数据库的任何特权。在admin数据库上授予userAdmin角色具有进一步的安全隐患，因为这间接提供了对群集的superuser访问。使用admin范围，具有userAdmin角色的用户可以授予群集范围内的角色或特权，包括userAdminAnyDatabase。
群集 Management 角色
admin数据库包括以下角色，用于 Management 整个系统，而不仅仅是一个数据库。这些角色包括但不限于replica set和sharded clusterManagement 职能。
clusterAdmin- 提供最大的群集 Management 访问。该角色结合了clusterManager，clusterMonitor和hostManager角色授予的特权。此外，该角色提供dropDatabase动作。
clusterManager- 在版本 3.4 中更改。
提供对集群的 Management 和监视操作。具有此角色的用户可以访问分别用于分片和复制的config和local数据库。
在整个群集上提供以下操作：
listSessions(3.6 版中的新功能)
对集群中的所有数据库执行以下操作：
在config数据库上，提供以下特权：
在local数据库上，提供以下特权：
| Resource | Actions |
|---|---|
local数据库中的所有集合 |
enableSharding |
insert moveChunk remove splitChunk splitVector update |
|
| system.replset collection | collStats dbHash dbStats find killCursors listCollections listIndexes planCacheRead |
clusterMonitor- 在版本 3.4 中更改。
提供对监视工具(例如MongoDB 云 Management 器和Ops Manager监视代理程序)的只读访问权限。
在整个群集上提供以下操作：
listSessions(3.6 版中的新功能)
对集群中的所有数据库执行以下操作：
useUUID(3.6 版中的新功能)
对集群中的所有system.profile集合提供find操作。
在config数据库上，提供以下特权：
在local数据库上，提供以下特权：
| Resource | Actions |
|---|---|
local数据库中的所有集合 |
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- 提供监视和 Management 服务器的功能。
在整个群集上提供以下操作：
diagLoggingkillAnyCursor(版本 3.6.3 中的新增功能)
killAnySession(3.6 版中的新功能)
对集群中的所有数据库执行以下操作：
备份和还原角色
admin数据库包括以下角色，用于备份和还原数据：
backup- 在版本 3.4 中更改。
提供备份数据所需的最小特权。该角色提供足够的特权来使用MongoDB 云 Management 器备份代理，Ops Manager备份代理，或使用mongodump备份整个mongod实例。
在admin数据库中的mms.backup集合上和config数据库中的settings集合上提供insert和update操作。
在anyResource上，提供
listDatabases action
listCollections action
listIndexes action
在整个cluster上，提供
针对以下内容提供find操作：
集群中的所有非系统集合，包括
config和local数据库中的集合群集中的以下系统集合：system.indexes，system.namespaces，system.js和system.profile
2.6 之前的 MongoDB 版本中的旧
system.users集合
对config.settings集合提供insert和update动作。
在版本 3.2.1 中进行了更改：backup角色提供了额外的特权来备份使用database profiling运行时存在的system.profile集合。以前，用户需要对此集合具有额外的read访问权限。
restore- 在版本 3.6 中更改：在非系统集合上提供convertToCapped。
提供必要的特权，以从备份中还原数据如果数据不包含system.profile收集数据，并且您在不使用--oplogReplay选项的情况下运行mongorestore。
如果备份数据包含system.profile收集数据，或者您使用--oplogReplay运行，则需要其他特权：
system.profile |
如果备份数据包含system.profile集合数据，并且目标数据库不包含system.profile集合，则mongorestore会尝试创建该集合，即使该程序实际上并未还原system.profile文档。因此，用户需要其他特权才能对数据库的system.profile集合执行createCollection和convertToCapped操作。 |
内置角色dbAdmin和dbAdminAnyDatabase均提供其他特权。
| --oplogReplay |要与--oplogReplay一起运行，请创建在anyResource上具有anyAction的user-defined role。
仅向必须使用--oplogReplay运行mongorestore的用户授予权限。
在整个群集上提供以下操作：
对所有* non *系统集合提供以下操作：
对system.js集合提供以下操作：
对anyResource提供以下操作：
对集群中的所有system.namespaces集合提供find操作。
对config和local数据库上的所有非系统集合提供以下操作：
在admin.system.version上提供以下操作
对admin.system.roles提供以下操作
对admin.system.users和旧版system.users集合提供以下操作：
尽管restore可以使用常规修改操作来修改admin.system.users集合中的文档，但是仅使用用户 Management 方法可以修改这些数据。
All-Database Roles
在版本 3.4 中更改。
以下角色仅对admin数据库上的用户可用。这些角色提供的特权适用于除local和config之外的所有数据库上的system.*集合以外的所有集合：
readAnyDatabase- 在
local和config之外的所有数据库上提供与read相同的只读特权。 readAnyDatabase还在群集上提供listDatabases特权操作。
- 在
在版本 3.4 中更改：readAnyDatabase不再适用于local和config数据库。要在local和config上提供读取特权，请在admin数据库上创建一个用户，在local和config数据库上具有read角色。
另请参见clusterManager和clusterMonitor角色以访问config和local数据库。
readWriteAnyDatabase- 在
local和config之外的所有数据库上提供与readWrite相同的读写特权。 readWriteAnyDatabase还在群集上提供listDatabases特权操作。
- 在
在版本 3.4 中更改：readWriteAnyDatabase不再适用于local和config数据库。要在local和config上提供读取和写入特权，请在admin数据库上创建一个用户，在local和config数据库上具有readWrite角色。
另请参见clusterManager和clusterMonitor角色以访问config和local数据库。
userAdminAnyDatabase- 在除
local和config之外的所有数据库上，提供与userAdmin相同的用户 Management 操作访问权限。 userAdminAnyDatabase还对群集提供以下特权操作：
- 在除
该角色还对admin数据库上的system.users和system.roles集合以及 2.6 之前的 MongoDB 版本的旧system.users集合提供以下特权操作：
在版本 2.6.4 中进行了更改：userAdminAnyDatabase在admin.system.users和admin.system.roles集合上添加了以下特权操作：
userAdminAnyDatabase角色不限制用户可以授予的特权。结果，userAdminAnyDatabase用户可以授予自己超出当前权限的特权，甚至可以授予自己“所有特权”，即使该角色并未明确授权用户 Management 之外的特权。这个角色实际上是 MongoDB 系统superuser。
在版本 3.4 中进行了更改：userAdminAnyDatabase不再适用于local和config数据库。
另请参见clusterManager和clusterMonitor角色以访问config和local数据库。
dbAdminAnyDatabase- 在除
local和config之外的所有数据库上，提供与dbAdmin相同的数据库 Management 操作访问权限。 dbAdminAnyDatabase还在群集上提供listDatabases特权操作。
- 在除
在版本 3.4 中更改：dbAdminAnyDatabase不再适用于local和config数据库。要在local和config上提供dbAdmin特权，请在admin数据库上创建一个用户，在local和config数据库上具有dbAdmin角色。
另请参见clusterManager和clusterMonitor角色以访问config和local数据库。
Superuser Roles
多个角色提供间接或直接的系统范围的超级用户访问。
以下角色提供了在任何数据库上分配任何用户任何特权的能力，这意味着具有这些角色之一的用户可以在任何数据库上“自己分配”任何特权：
范围为
admin数据库的dbOwner角色范围为
admin数据库的userAdmin角色userAdminAnyDatabase role
以下角色提供对所有资源的完整特权：
root- 提供对readWriteAnyDatabase，dbAdminAnyDatabase，userAdminAnyDatabase，clusterAdmin角色，restore和backup角色组合的操作和所有资源的访问。
在版本 3.4 中进行了更改：root角色包括backup角色的特权。
在版本 3.0.7 中进行了更改：root对system.集合具有validate操作。以前，root不包括对以system.前缀(system.indexes和system.namespaces除外)开头的集合的任何访问。
Internal Role
__system- MongoDB 将此角色分配给代表群集成员的用户对象，例如副本集成员和mongos实例。该角色使它的所有者有权对数据库中的任何对象执行任何操作。
**除非特殊情况，否则请勿将此角色分配给代表应用程序或人工 Management 员的用户对象。
如果您需要访问所有资源上的所有操作，例如运行applyOps命令，请不要分配此角色。而是在anyResource上授予anyAction的创建用户定义的角色并确保只有需要访问这些操作的用户才具有此访问权限。