MongoDB通过基于角色的授权授予对数据和命令的访问权，并提供内置角色，这些角色提供数据库系统中通常需要的不同级别的访问。
角色授予对定义的资源执行一组操作的权限。给定的角色适用于其定义的数据库，并可以授予对集合粒度级别的访问权限。
MongoDB的每个内置角色都定义了对角色数据库中所有非系统集合在数据库级别的访问，以及对所有系统集合的访问。
MongoDB为每个数据库提供内置的数据库用户和数据库管理角色。MongoDB只在管理数据库上提供所有其他内置角色。
本节描述每个内置角色的权限。您还可以通过在RoSeFielo命令中发布SuffeleSes和SeaBuffTIN角色字段，并将其设置为true，从而查看内置角色的权限。（好像是3.6版本新改，目前我使用2.8版本可以通过db.getRole("role")查看角色，具体详细命令请查看MongoDB权限控制系统简介-常用操作中的查看角色字段内容。）
1、先介绍数据库用户角色
每个数据都包含以下客户端角色：
read
提供读取所有非系统集合和下列系统集合的数据的能力：system.index、system.js和system.namespace集合。该角色通过授予下列操作提供读取访问：
readWrite
提供Read角色的所有特权，以及修改所有非系统集合和system.js集合上的数据的能力。该角色对这些集合提供以下操作：
2、数据库管理员角色
每个数据库都包含以下数据库管理员角色
dbadmin
对数据库的system.index、system.namespace和system.profile集合提供以下操作：
dropCollection and createCollection on system.profile only
在2.6.4版本中更改：dbAdmin添加了System.profilec集合的createCollection。以前的版本只在system.profile集合上有了dropCollection。
对所有非系统集合提供下列操作。此角色不包括对非系统集合的完全读取访问：
dbOwner
数据库所有者可以在数据库上执行任何管理操作。此角色结合了ReadWrite、dbAdmin和userAdmin角色授予的特权。
userAdmin
提供为数据库创建和修改角色和用户的能力。在数据库中具有此角色的用户可以将任何角色或特权分配给该数据库的任何用户，包括他们自己。
【警告】理解授予在角色的安全性含义是很重要的：一个数据库中具有此角色的用户可以在该数据库上分配任何权限。授予admin数据库上的userAdmin角色会进一步影响安全性，因为这间接地提供了超级用户对集群的访问。使用admin范围，具有在角色的用户可以授予集群范围内的角色或权限，包括userAdminAnyDatabase。
3、集群管理员角色
管理数据库包括以下角色，用于管理整个系统，而不是只管理单个数据库。
这些角色包括但不限于副本集和分片群集管理功能。
clusteradmin
提供最大的集群管理访问权限。此角色组合了由clusterManager、clusterMonitor和hostManager角色授予的特权。此外该角色还提供了dropDatabase操作
clusterManager
在3.4+版本
提供集群上的管理和监视操作。具有此角色的用户可以访问分别用于切分和复制的config和local数据库。
在集群上提供的操作如下：
listSessions (New in version 3.6)
对集群中的所有数据库提供以下操作：
对config数据库，提供以下操作：
ResourceActions
All collections in the config databasecollStats
system.namespaces collections
在local 数据，提供以下操作：
ResourceActions
All collections in the local databaseenableSharding
system.replset collectioncollStats
clusterMonitor
在3.4+版本
提供对监视工具(如MongoDBCloudManager和Ops Manager监视代理)的只读访问。
在整个集群上提供以下操作：
listSessions (New in version 3.6)
在集群的所有数据库上，提供以下操作：
useUUID (New in version 3.6)
在集群中的所有system.profile集合中提供find操作
在config 数据库，提供以下权限：
ResourceActions
All collections in the config databasecollStats
system.namespaces collections
在local 数据库，提供以下权限：
ResourceActions
All collections in the local databasecollStats
system.namespaces collections
system.replset,
hostManager
提供监视和管理服务器的能力。
在整个集群，提供以下操作：
diagLogging
killAnySession (New in version 3.6)
在集群的所有数据库，提供以下操作：
4、备份和恢复角色
admin数据库包括以下用于备份和还原数据库角色：
backup
在3.4版本
提供备份数据所需的最低权限。这个角色提供了足够的特权来使用MongoDBCloudManager备份代理、Ops Manager备份代理，或者使用Monotump备份整个monhead实例。
在admin数据库中的mms.backup集合和config数据库中的设置集合上提供插入和更新操作。
在任意资源上提供：
listDatabases action
listCollections action
listIndexes action
在整个集群上，提供：
listDatabases action
listCollections action
listIndexes action
提供以下方面的find操作：
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
在config数据库的config.settings集合中提供插入和更新操作
在3.2.1版本中更改：备份角色提供了额外的特权来备份运行数据库配置文件时存在的system.profile集合。以前，用户需要对该集合进行额外的读取访问。
restore
在版本3.6中更改：提供非系统集合的转换映射。
提供从不包括System.profile集合数据的备份中还原数据所需的权限。如果没有-oplogReplay选项，使用mongoRestore还原数据时，此角色就足够了。
如果备份数据包括system.profile收集数据，而目标数据库不包含system.profile集合，则mongo还原尝试创建集合，即使程序实际上并不还原system.profile文档。因此，用户需要额外的特权才能在数据库的system.profile集合上执行createCollection和转换ToCaped操作。
内置角色dbAdmin和dbAdminAnyDatabase提供附加特权。
如果使用-oplogReplay运行MongoRestore，则还原角色不足以重放oplog。若要重播oplog，请创建一个用户定义的角色，该角色在anyResource上具有anyAction，并且只授予必须使用-oplogReplay运行mongo还原的用户。
在整个集群上提供以下操作：
对所有非系统集合提供下列操作：
在system.js集合提供以下操作：
在所有资源提供以下操作：
在集群的system.namespaces集合提供find操作
在conifg和local数据库的非系统集合提供以下操作：
在admin.system.version集合提供以下操作：
在admin.system.roles集合提供以下操作：
提供有关admin.system.users和旧的system.users集合以下操作：
尽管还原包含使用常规修改操作修改admin.system.usersCollection中的文档的能力，但只能使用用户管理方法修改这些数据。
5、所有数据库角色
在3.4版本
以下角色仅供管理数据库上的用户使用。这些角色提供的特权适用于系统以外的所有集合。*除本地和配置之外，所有数据库上的集合：
readAnyDatabase
除了local和config.readAnyDatabase之外，在所有数据库上提供相同的只读特权。readAnyDatabase还在集群上提供listDatabases特权操作。
在3.4版中更改：readAnyDatabase不再适用于本地和配置数据库。要在本地和配置上提供读取权限，请在admin数据库上创建一个用户，并在本地和配置数据库上创建read role。
readWriteAnyDatabase
在除local和config之外的所有数据库上提供与ReadWrite相同的读和写权限。readWriteAnyDatabase还在群集上提供listDatabases特权操作。
在3.4版中更改：readWriteAnyDatabase不再适用于本地和config数据库。若要在本地和配置上提供读和写权限，请在adminDatabase上创建一个用户，在本地和配置数据库上使用ReadWrite角色
userAdminAnyDatabase
除了local和config之外，在所有数据库上提供与userAdmin相同的对用户管理操作的访问。userAdminAnyDatabase还在集群上提供以下特权操作：
该角色还在admin数据库上的system.user和system.roles集合以及2.6之前MongoDB版本的遗留system.user集合上提供了以下特权操作：
在版本2.6.4中更改：userAdminAnyDatabase在admin.system.user和admin.system.Roles集合中添加了以下特权操作：
userAdminAnyDatabase角色不限制用户可以授予的特权。因此，userAdminAnyDatabase用户可以为自己授予超出当前权限的权限，甚至可以授予自己所有权限，即使角色没有显式授权用户管理之外的权限。这个角色实际上是MongoDB系统的超级用户。
在3.4版中更改：userAdminAnyDatabase不再适用于本地和config数据库。
dbAdminAnyDatabase
在除local和config之外的所有数据库上提供与dbAdmin相同的数据库管理操作访问权限。dbAdminAnyDatabase还在集群上提供listDatabases特权操作。
在3.4版中更改：dbAdminAnyDatabase不再适用于本地和config数据库。要在本地和配置上提供dbAdmin特权，请在admin数据库上创建一个用户，在本地和配置数据库上使用dbAdmin角色。
6、超级用户角色
几个角色提供了间接或直接的系统超级用户访问。
下面的角色提供了在任何数据库上分配任何用户特权的能力，这意味着具有这些角色之一的用户可以在任何数据库上分配自己的特权:
dbOwner role, when scoped to the admin database 当作用于 admin
userAdmin role, when scoped to the admin database 当作用域admin
userAdminAnyDatabase role
以下角色为所有资源提供了充分的特权：
root
提供对readWriteAnyDatabase、dbAdminAnyDatabase、userAdminAnyDatabase、clusterAdmin角色、restor和backup组合的操作和所有资源的访问。
在3.4版本中更改：root角色包含来自备份角色的权限。
在3.0.7版本中更改：root在system.集合上具有验证动作。以前，root不包括对从system.prefix开始的集合的任何访问。除了system.indexes和system.namespaces以外的前缀。
根角色包括还原角色的权限。
7、内部角色
__system
MongoDB将此角色分配给表示集群成员的用户对象，例如复制集成员和mongos实例。该角色使其持有者有权对数据库中的任何对象采取任何行动。
除了在特殊情况下，不要将此角色分配给表示应用程序或人工管理员的用户对象。
如果需要访问所有资源上的所有操作，例如要运行applyOps命令，请不要分配此角色。相反，创建一个用户定义的角色，授予anyResource上的anyAction，并确保只有需要访问这些操作的用户才有此权限。
网友评论