内置角色
MongoDB 通过 role-based authorization授予对数据和命令的访问权限，并提供内置角色来提供数据库系统中通常需要的不同级别的访问权限。您还可以创建user-defined roles。
角色授予对定义的resources执行一组actions的权限。给定的角色适用于定义它的数据库，并且可以授予访问权限到粒度的集合级别。
MongoDB 的每个内置角色都定义了角色数据库中所有 非系统集合在数据库级别的访问权限，以及所有system collections在集合级别的访问权限。
MongoDB 提供了内置的database user和 database administration每个数据库上的角色 。MongoDB 仅在admin数据库上提供所有其他内置角色 。
本节介绍每个内置角色的权限。 您还可以随时查看内置角色的权限，方法是发出 rolesInfo 命令并将 showPrivileges 和 showBuiltinRoles 字段都设置为 true。
数据库用户角色
每个数据库都包含以下客户端角色：
read提供读取所有非系统集合和
system.js集合上的数据的能力。[NOTE]
从 MongoDB 4.2 开始，角色不再提供
system.namespaces直接访问集合的权限。自 MongoDB 3.0 以来，不推荐直接访问集合。在早期版本中，该角色提供了上述对system.namespaces集合的特权操作，从而允许直接访问。该角色通过授予以下操作来提供读取访问权限：
如果用户没有
listDatabases权限操作，用户可以运行该listDatabases命令以返回用户具有权限的数据库列表（包括用户对特定集合具有权限的数据库）如果该命令运行时authorizedDatabases未指定或设置到true。readWrite提供所有特权
read角色加上修改所有非系统集合和system.js集合上的数据的能力。该角色对这些集合提供以下操作：
数据库管理角色
每个数据库都包含以下数据库管理角色：
dbAdmin提供执行管理任务的能力，例如与架构相关的任务、索引和收集统计信息。此角色不授予用户和角色管理权限。
具体来说，该角色提供以下权限：资源允许的操作
Resource：
system.profilePermitted Actions:
changeStreamcollStatsconvertToCappedcreateCollectiondbHash-
[NOTE]
除此以外
从版本 4.2 开始，MongoDB 删除了
system.indexes和system.namespaces集合。 因此，dbAdmin角色不再提供访问这些集合的权限。 自 MongoDB 3.0 以来，不推荐直接访问这些集合。在早期版本中，
dbAdmin角色在system.indexes和system.namespaces集合上提供上述特权操作（dropCollection和createCollection除外），从而允许直接访问system.indexes和system.namespaces集合。
Resource：All non-system collections (i.e. database resource)
Permitted Actions：
-
对于这些集合，
dbAdmin不包括完全读取访问权限（即查找）。
dbOwneruserAdmin提供在当前数据库上创建和修改角色和用户的能力。自从
userAdmin角色允许用户将任何权限授予任何用户，包括他们自己，该角色还间接提供超级用户 访问数据库，或者，如果范围是admin数据库，则访问集群。这userAdmin角色明确提供以下操作：changeCustomDatachangePasswordcreateRolecreateUserdropRoledropUsergrantRolerevokeRolesetAuthenticationRestrictionviewRoleviewUser
[WARNING]
了解授予
userAdmin角色的安全隐患很重要：具有数据库此角色的用户可以为自己分配对该数据库的任何特权。 在 admin 数据库上授予userAdmin角色具有进一步的安全隐患，因为这间接提供了对集群的超级用户访问权限。 在管理范围内，具有userAdmin角色的用户可以授予集群范围的角色或权限，包括userAdminAnyDatabase。
集群管理角色
该admin数据库包括以下用于管理整个系统的角色，而不仅仅是一个数据库。这些角色包括但不限于副本集和分片集群管理功能。
clusterAdmin提供最大的集群管理访问。该角色结合了由
clusterManager,clusterMonitor， 和hostManager角色。此外，角色提供dropDatabase操作。clusterManager提供对集群的管理和监控操作。具有此角色的用户可以访问
config和local数据库，它们分别用于分片和复制。Resource：clusterhttps://www.mongodb.com/docs/manual/reference/resource-document/#std-label-resource-specific-db)
Actions：
addShardappendOplogNoteapplicationMessagecleanupOrphanedflushRouterConfiggetDefaultRWConcern(New in version 4.4)listSessionslistShardsremoveShardreplSetConfigurereplSetGetConfigreplSetGetStatusreplSetStateChangeresyncsetDefaultRWConcern(New in version 4.4)setFeatureCompatibilityVersionsetFreeMonitoring
Resource：All databases
Actions：
clearJumboFlag(New in 4.2.3)enableShardingrefineCollectionShardKey(New in 4.4)moveChunksplitVector
clusterManagerconfig为和local数据库提供额外的权限 。在
config数据库上，允许执行以下操作：Resource：All non-system collections in the
configdatabasehttps://www.mongodb.com/docs/manual/reference/resource-document/#std-label-resource-specific-db)Actions：
collStatsdbHashdbStatsenableShardingfindinsertkillCursorslistCollectionslistIndexesmoveChunkplanCacheReadremovesplitVectorupdate
Resource：
system.jshttps://www.mongodb.com/docs/manual/reference/resource-document/#std-label-resource-specific-db)Actions：
-
[NOTE]
除此以外
从版本 4.2 开始，MongoDB 删除了
system.indexes和system.namespaces集合。 因此，dbAdmin角色不再提供访问这些集合的权限。 自 MongoDB 3.0 以来，不推荐直接访问这些集合。在早期版本中，
dbAdmin角色在system.indexes和system.namespaces集合上提供上述特权操作（dropCollection和createCollection除外），从而允许直接访问system.indexes和system.namespaces集合。
在
local数据库上，允许执行以下操作：Resource：All non-system collections in the
localdatabaseActions：
Resource：
system.replsetcollectionActions：
clusterMonitor提供对监控工具的只读访问，例如MongoDB 云管理器 和运营经理监控代理。允许对整个集群执行以下操作：
checkFreeMonitoringStatusconnPoolStatsgetCmdLineOptsgetDefaultRWConcern(New in version 4.4)getLoggetParametergetShardMaphostInfoinproglistDatabaseslistSessionslistShardsnetstatreplSetGetConfigreplSetGetStatusserverStatussetFreeMonitoringshardingStatetop
对集群中的所有数据库执行以下操作：
允许对集群中的
find所有system.profile集合执行操作。在
config数据库上，允许执行以下操作：Resource：All non-system collections in the
configdatabasehttps://www.mongodb.com/docs/manual/reference/resource-document/#std-label-resource-specific-db)Actions：
Resource：
system.jscollectionActions：
[NOTE]
除此以外
从版本 4.2 开始，MongoDB 删除了
system.indexes和system.namespaces集合。 因此，dbAdmin角色不再提供访问这些集合的权限。 自 MongoDB 3.0 以来，不推荐直接访问这些集合。在早期版本中，
dbAdmin角色在system.indexes和system.namespaces集合上提供上述特权操作（dropCollection和createCollection除外），从而允许直接访问system.indexes和system.namespaces集合。在
local数据库上，允许执行以下操作：Resource：All non-system collections in the
localdatabaseActions：
Resource：
system.jscollectionActions：
从版本 4.2 开始，MongoDB 删除了
system.indexes和system.namespaces集合。 因此，dbAdmin角色不再提供访问这些集合的权限。 自 MongoDB 3.0 以来，不推荐直接访问这些集合。在早期版本中，
dbAdmin角色在system.indexes和system.namespaces集合上提供上述特权操作（dropCollection和createCollection除外），从而允许直接访问system.indexes和system.namespaces集合。Resource：
system.replset,Actions：
findhostManager提供监视和管理服务器的能力。在整个集群上，提供以下操作：
applicationMessagecloseAllDatabasesconnPoolSyncflushRouterConfigfsyncinvalidateUserCachekillAnyCursorkillAnySessionkilloplogRotateoidResetresyncrotateCertificates(New in version 5.0)setParametershutdowntouchunlock
Changed in version 4.4 :从 4.4 版本开始，
hostManager不再提供cpuProfiler对集群的权限操作。在集群中的所有数据库上，提供以下操作：
备份和恢复角色
admin数据库包括以下用于备份和恢复数据的角色：
backup提供备份数据所需的最低权限。 此角色提供足够的权限来使用MongoDB Cloud Manager备份代理， Ops Manager备份代理，或者使用
mongodump来备份整个mongod实例。提供对管理数据库中的
mms.backup集合和配置数据库中的设置集合的insert和update操作。在
anyResource上，提供listDatabasesactionlistCollectionsactionlistIndexesaction
在整个cluster上，提供了
appendOplogNotegetParameterlistDatabasesserverStatus(Starting in MongoDB 4.2)setUserWriteBlockMode(Starting in MongoDB 6.0)
提供对以下内容的查找操作：
all non-system collections in the cluster, including those in the
configandlocaldatabasesThe following system collections in the cluster:
system.js, andsystem.profileThe
admin.system.usersandadmin.system.rolescollectionsThe
config.settingscollectionLegacy
system.userscollections from versions of MongoDB prior to 2.6
提供对
config.settings集合的插入和更新操作。backup角色提供额外的权限来备份运行database profiling时存在的system.profile集合。restore提供
convertToCapped非系统集合。如果数据不包括
system.profile集合数据并且您在不使用--oplogReplay选项的情况下运行mongorestore，则提供从备份恢复数据所需的权限。如果备份数据包括
system.profile集合数据或者您使用--oplogReplay运行，您需要额外的权限：system.profile如果备份数据包含
system.profile集合数据，而目标数据库不包含system.profile集合，mongorestore尝试创建集合，即使该程序实际上并未恢复system.profile文档。因此，用户需要额外的权限才能 对数据库的集合执行createCollection和convertToCapped操作。system.profile两个内置角色
dbAdmin和dbAdminAnyDatabase提供额外的特权。--oplogReplay运行
--oplogReplay，创建 具有 on的用户定义角色。anyActionanyResource仅授予必须运行的用户
mongorestore和--oplogReplay.
在整个集群上提供以下操作：
对所有非系统集合提供以下操作：
bypassDocumentValidationchangeCustomDatachangePasswordcollModconvertToCappedcreateCollectioncreateIndexcreateRolecreateUserdropCollectiondropRoledropUsergrantRoleinsertrevokeRoleviewRoleviewUser
提供以下system.js收集操作：
在 上提供以下操作anyResource：
config对和local数据库上的所有非系统集合提供以下操作 ：
提供以下操作admin.system.version
提供以下操作admin.system.roles
提供对admin.system.users 遗留system.users集合的以下操作：
bypassDocumentValidationcollModcreateCollectioncreateIndexdropCollectionfindinsertremoveupdate
虽然，restoreadmin.system.users包括使用正常修改操作修改集合中文档的能力，仅使用用户管理方法修改这些数据 。
在整个集群上，提供以下操作：
bypassWriteBlockingMode（盯着 MongoDB 6.0）setUserWriteBlockMode（从 MongoDB 6.0 开始）
[NOTE]
除此以外
从版本 4.2 开始，MongoDB 删除了
system.indexes和system.namespaces集合。 因此，dbAdmin角色不再提供访问这些集合的权限。 自 MongoDB 3.0 以来，不推荐直接访问这些集合。在早期版本中，
dbAdmin角色在system.indexes和system.namespaces集合上提供上述特权操作（dropCollection和createCollection除外），从而允许直接访问system.indexes和system.namespaces集合。
全数据库角色
以下角色在admin数据库上可用，并提供适用于除local和 之外的所有数据库的特权config：
readAnyDatabase提供与
readlocal在除和之外的所有数据库上config。该角色还提供listDatabases对整个集群的操作。另见clusterManager和clusterMonitor访问config和local数据库的角色。readWriteAnyDatabase提供与以下相同的特权
readWritelocal在除和之外的所有数据库上config。该角色还提供：listDatabases对整个集群的操作compactStructuredEncryptionData行动_
另见
clusterManager和clusterMonitor访问config和local数据库的角色。userAdminAnyDatabase提供与用户管理操作相同的访问权限
userAdminlocal在除和 之外的所有数据库上config。userAdminAnyDatabase还在集群上提供以下特权操作：该角色在
admin数据库的system.users和system.roles集合以及 2.6 之前的 MongoDB 版本的遗留system.users集合上提供以下特权操作：这
userAdminAnyDatabase角色不限制用户可以授予的权限。因此，userAdminAnyDatabase用户可以授予自己超过当前权限的权限，甚至可以授予自己所有权限，即使该角色没有明确授权超出用户管理的权限。这个角色实际上是一个 MongoDB 系统超级用户。另见
clusterManager和clusterMonitor访问config和local数据库的角色。dbAdminAnyDatabase在除
local和config之外的所有数据库上提供与dbAdmin相同的权限。 该角色还提供对整个集群的listDatabases操作。另请参阅
clusterManager和clusterMonitor访问config和local数据库的角色。从 MongoDB 5.0 开始，
dbAdminAnyDatabase包括 applyOps特权操作。
超级用户角色
多个角色提供间接或直接的系统级超级用户访问权限。
以下角色提供了为任何用户分配对任何数据库的任何权限的能力，这意味着具有这些角色之一的用户可以 为自己分配对任何数据库的任何权限：
dbOwner角色，当范围限定为admin数据库时userAdmin角色，当范围限定为admin数据库时userAdminAnyDatabase角色
以下角色提供对所有资源的完全权限：
root提供对以下角色组合的操作和所有资源的访问权限：
还提供对
system.集合的validate特权操作。在6.0版中更改：
root角色包括config数据库中system.preimages集合的find和remove权限。
内部角色
__systemMongoDB 将此角色分配给代表集群成员的用户对象，例如副本集成员和
mongos实例。该角色授权其持有者对数据库中的任何对象执行任何操作。除非在特殊情况下，否则不要将此角色分配给代表应用程序或人工管理员的用户对象。如果您需要访问所有资源的所有操作，例如运行applyOps命令，请不要分配此角色。相反，创建一个用户定义的角色，授予anyAction并anyResource确保只有需要访问这些操作的用户才具有此访问权限。参见
原文 - Built-In Roles
译者：景圣