Docs 菜单
Docs 主页
/
MongoDB Manual
/ / /

自管理部署中的内置角色

在此页面上

  • MongoDB Atlas 内置角色
  • 自托管部署内置角色
  • 数据库用户角色
  • 数据库管理角色
  • 集群管理角色
  • 备份和恢复角色
  • 全数据库角色
  • 超级用户角色
  • 内部角色

MongoDB通过基于角色的授权授予对数据和命令的访问权限,并提供内置角色来提供数据库系统通常所需的不同访问权限级别。 您还可以创建用户定义的角色。

角色授予在定义的资源上执行一系列动作的特权。给定角色适用于定义它的数据库,并且可以授予集合粒度级别的访问权限。

系统集合包括以下位置的集合:

  • <database>.system.* namespace

  • local.replset.* 副本集命名空间

有关详细信息,请参阅系统集合。

非系统集合是指不在上一个列表中的命名空间中的集合。

MongoDB 的每个内置角色都在数据库级别为该角色数据库中的所有系统集合定义访问权限,并在集合级别为所有系统集合定义访问权限。

本节描述了每个内置角色的特权。您还可以随时执行 rolesInfo 命令(将 showPrivilegesshowBuiltinRoles 字段设置为 true),查看内置角色的特权。

MongoDB Atlas 部署具有与自托管部署不同的内置角色。请参阅以下资源以了解更多信息:

  • MongoDB Atlas 内置角色

  • 自托管部署内置角色

有关MongoDB Atlas中托管的部署的内置数据库用户角色,请参阅Altas 内置角色和权限。

您可以在MongoDB Atlas用户界面中创建数据库用户并分配内置角色。 要学习;了解更多信息,请参阅添加数据库用户。

MongoDB 为自托管部署提供以下内置角色:

每个数据库都包含以下客户端角色:

read

提供在所有系统集合和 system.js 集合上读取数据的能力。

注意

该角色不提供直接访问 system.namespaces 集合的权限。

该角色通过批准以下动作来提供读取访问权限:

如果用户没有 listDatabases 特权操作,则用户可运行 listDatabases 命令以返回该用户拥有特权的数据库列表(包括用户对特定集合具有特权的数据库),前提是该命令未指定 authorizedDatabases 选项或该选项设置为 true

readWrite

提供 read 角色的所有权限,以及在所有系统集合和 system.js 集合上修改数据的能力。

该角色对这些集合执行以下动作的权限:

每个数据库都包含以下数据库管理角色:

dbAdmin

提供执行管理任务的能力,例如架构相关任务、索引和收集统计信息。该角色不授予用户和角色管理特权。

具体而言,该角色提供以下特权:

Resource
允许的动作
所有系统集合(即数据库资源)
dbOwner

数据库所有者可以对数据库执行任何管理操作。此角色结合了 readWritedbAdminuserAdmin 角色授予的权限。

userAdmin

提供在当前数据库上创建和修改角色和用户的能力。由于 userAdmin 角色允许用户向任何用户(包括自己)授予任何特权,因此该角色还间接提供对数据库或(如果作用域为 admin 数据库)集群的超级用户访问权限。

userAdmin 角色显式提供以下操作:

警告

了解授予 userAdmin 角色带来的安全隐患非常重要:拥有该数据库角色的用户可以为自己分配针对该数据库的任何特权。针对 admin 数据库授予 userAdmin 角色会带来进一步的安全隐患,因为这会间接提供对集群的超级用户访问权限。凭借 admin 作用域,拥有 userAdmin 角色的用户可以授予集群范围的角色或特权,包括 userAdminAnyDatabase

admin 数据库包括以下角色,用于管理整个系统而不仅仅是单个数据库。这些角色包括但不限于副本集分片集群管理功能。

clusterAdmin

提供最大的集群管理访问权限。此角色结合了 clusterManagerclusterMonitorhostManager 角色授予的特权。该角色还提供 dropDatabase 操作。

clusterManager

提供对集群的管理和监视动作。具有此角色的用户可以访问 configlocal 数据库,这两个数据库分别用于分片和复制。

config 数据库中,允许以下动作:

local 数据库中,允许以下动作:

clusterMonitor

提供对监控工具(例如 MongoDB Cloud ManagerOps Manager监控代理)的只读访问权限。

允许对整个集群执行以下动作:

允许对集群中的所有数据库执行以下动作:

允许对集群中的所有 system.profile 集合执行 find 动作。

config 数据库中,允许以下动作:

local 数据库中,允许以下动作:

enableSharding

提供为集合启用分片和修改现有分片键的能力。

提供在所有非系统集合上进行如下操作的权限:

hostManager

提供监控和管理服务器的能力。

对于整个集群,提供执行以下动作的权限:

针对集群中的所有数据库,提供执行以下动作的权限:

admin 数据库包括用于备份和恢复数据的以下角色:

backup

提供备份数据所需的最低特权。该角色提供足够的特权来使用 MongoDB Cloud Manager 备份代理、Ops Manager 备份代理,或使用 mongodump 备份整个 mongod 实例。

提供针对 config 数据库中 settings 集合的 insertupdate 动作。

anyResource 上,提供

在整个集群上,提供

针对以下内容提供执行 find 动作的权限:

提供在 config.settings 集合上进行 insertupdate 动作的权限。

backup 角色为运行数据库分析时存在的 system.profile 集合提供额外的备份特权。

restore

针对非系统集合,提供 convertToCapped 权限。

如果数据不包含 system.profile 集合数据且您在运行 mongorestore 时未使用 --oplogReplay 选项,那么请提供必要特权以便从备份中恢复数据。

如果备份数据包含 system.profile 集合数据,或者您使用 --oplogReplay 运行,将需要额外的权限:

system.profile

如果备份数据包含 system.profile 集合数据,而目标数据库不包含 system.profile 集合,那么即便程序实际上并未恢复 system.profile 中的文档,mongorestore 也会尝试创建该集合。因此,用户需要额外的特权才能对数据库的 system.profile 集合执行 createCollectionconvertToCapped 操作。

内置角色 dbAdmindbAdminAnyDatabase 均提供其他特权。

--oplogReplay

要使用 --oplogReplay 运行,请创建一个在 anyResource 上具有 anyAction用户定义的角色

仅授予必须使用 --oplogReplay 运行 mongorestore 的用户。

提供在整个集群上进行如下动作的权限:

提供在所有系统集合上进行如下动作的权限:

system.js 集合上提供以下动作权限:

提供在 anyResource 上执行以下动作的权限:

针对 configlocal 数据库上的所有非系统集合,提供执行以下动作的权限:

提供执行以下动作的权限 admin.system.version

提供执行以下动作的权限 admin.system.roles

针对 admin.system.users 和旧版 system.users 集合提供执行以下动作的权限:

尽管 restore 包括使用常规修改操作修改 admin.system.users 集合中的文档的功能,但只能使用用户管理方法修改这些数据。

<database>.system.views 集合上提供以下操作权限:

在整个集群上,提供执行以下动作的权限:

以下角色可用于 admin 数据库,并提供适用于除 localconfig 之外的所有数据库的特权。

readAnyDatabase

针对除 localconfig 之外的所有数据库,提供与 read 相同的只读权限。该角色还提供对整个集群执行 listDatabases 操作的权限。

另请参阅 clusterManagerclusterMonitor 角色以获取访问 configlocal 数据库的权限。

readWriteAnyDatabase

在除 localconfig 以外的所有数据库中提供与 readWrite 相同的权限。该角色还提供:

另请参阅 clusterManagerclusterMonitor 角色以获取访问 configlocal 数据库的权限。

userAdminAnyDatabase

针对除 localconfig 之外的所有数据库,提供与 userAdmin 相同的用户管理操作访问权限。

userAdminAnyDatabase 此外,还对集群提供执行以下动作的特权:

该角色对 admin 数据库上的 system.userssystem.roles 集合以及 2.6 之前 MongoDB 版本中的旧版 system.users 集合提供以下特权动作:

userAdminAnyDatabase 角色不限制用户能够授予的特权。因此,userAdminAnyDatabase 用户可以授予自己超出当前特权的特权,甚至可以授予自己所有特权,即使该角色没有显式授予用户管理以外的特权。这个角色实际上是 MongoDB 系统的超级用户

另请参阅 clusterManagerclusterMonitor 角色以获取访问 configlocal 数据库的权限。

dbAdminAnyDatabase

在除 localconfig 以外的所有数据库中提供与 dbAdmin 相同的权限。该角色还提供对整个集群执行 listDatabases 操作的权限。

另请参阅 clusterManagerclusterMonitor 角色以获取访问 configlocal 数据库的权限。

从 MongoDB 5.0 开始,dbAdminAnyDatabase 包含 applyOps 特权操作。

多个角色提供间接或直接的系统级超级用户访问权限。

以下角色能够为任何用户分配任何数据库的任何特权,这意味着具有这些角色的用户可以为自己分配任何数据库的任何特权:

以下角色提供对所有资源的完全特权:

root

提供对以下角色总共的操作和所有资源的访问权限:

还提供对 system. 集合执行 validate 动作的特权。

在 6.0 版本中更改root 角色包括对 config 数据库中 system.preimages 集合的 find remove 特权。

__system

MongoDB 将此角色分配给表示集群节点的用户对象,例如副本集节点和 mongos 实例。此角色授权其持有者对数据库中的任何对象执行任何动作的权限。

除特殊情况外,请勿将此角色分配给代表应用程序或人类管理员的用户对象。

如果您需要访问所有资源上的所有动作,例如运行 applyOps 命令,请勿分配此角色。您可以创建一个用户定义的角色,借此授予对 anyResource 执行 anyAction 的权限,并确保只有需要访问这些操作的用户才有此访问权限。

后退

基于角色的访问控制