MongoDB 4.2.8 用户和角色权限管理总结

说明

关于MongoDB的用户和角色权限的梳理一直不太清晰，仔细阅读了下官方文档，并对此做个总结。
默认情况下，MongoDB实例启动运行时是没有启用用户访问权限控制的，也就是说，在实例本机服务器上都可以随意登录实例进行各种操作，MongoDB不会对连接客户端进行用户验证，可以想象这是非常危险的。
其实，MongoDB在2.4的版本的时候就已经引入了橘色方面的介绍。详见链接 JavaScript Changes in MongoDB 2.4 。
本文就MongoDB用户的权限和角色管理进行测试，主要参考的是官方文档说明。
本机MongoDB数据库及操作系统版本：

启用访问控制

MongoDB使用的是基于角色的访问控制(Role-Based Access Control,RBAC)来管理用户对实例的访问。通过对用户授予一个或多个角色来控制用户访问数据库资源的权限和数据库操作的权限，在对用户分配角色之前，用户无法访问实例。MongoDB存储所有的用户信息在admin 数据库的集合system.users中，保存用户名、密码和数据库信息。创建管理用户的的步骤就是先第一次没有认证启动服务，创建管理账号，第二次才认证启动服务。
在实例启动时添加选项–auth或指定启动配置文件中添加选项auth=true。

角色

在MongoDB中通过角色对用户授予相应数据库资源的操作权限，每个角色当中的权限可以显式指定，也可以通过继承其他角色的权限，或者两都都存在的权限。

权限

权限由指定的数据库资源(resource)以及允许在指定资源上进行的操作(action)组成。

1. 资源(resource)包括：数据库、集合、部分集合和集群；
2. 操作(action)包括：对资源进行的增、删、改、查(CRUD)操作。
   在角色定义时可以包含一个或多个已存在的角色，新创建的角色会继承包含的角色所有的权限。在同一个数据库中，新创建角色可以继承其他角色的权限，在admin数据库中创建的角色可以继承在其它任意数据库中角色的权限。
   关于角色权限的查看，可以通过如下命令查询：

// 查询当前数据库中的角色权限
> db.runCommand({ rolesInfo: "" })
// 查询其它数据库中指定的角色权限
> db.runCommand({ rolesInfo: { role: "", db: "" } }
// 查询多个角色权限
> db.runCommand(
    {
        rolesInfo: [
            "",
            { role: "", db: "" },
            ...
        ]     
    }
)
// 查询所有角色权限(仅用户自定义角色)
> db.runCommand({ rolesInfo: 1 })
// 查询所有角色权限(包含内置角色)
> db.runCommand({ rolesInfo: 1, showBuiltinRoles: true })

例如：（图中数据库我暂时一个角色都没有创建过）

系统内置角色

MongoDB内部提供了一系列内置的角色，这些角色是为了完成一些基本的数据库操作。每个内置角色提供了用户在角色数据库内数据库级别所有非系统类集合的访问权限，也提供了对集合级别所有系统集合的访问权限。MongoDB在每个数据库上都提供内置的数据库用户角色和数据库管理角色，但只在admin数据库中提供其它的内置角色。
内置角色主要包括以下几个类别：

1. 数据库用户角色(Database User Roles)
2. 数据库管理角色(Database Administration Roles)
3. 集群管理角色(Cluster Administration Roles)
4. 备份和恢复角色(Backup and Restoration Roles)
5. 全数据库级角色(All-Database Roles)
6. 超级用户角色(Superuser Roles)
7. 内部角色(Internal Role)

数据库用户角色

• read
read角色包含读取所有非系统集合数据和订阅部分系统集合(system.indexes、system.js、system.namespaces)的权限。
该角色权限包含命令操作：changeStream、collStats、dbHash、dbStats、find、killCursors、listIndexes、listCollections。
• readWrite
readWrite角色包含read角色的权限同时增加了对非系统集合数据的修改权限，但只对系统集合system.js有修改权限。
该角色权限包含命令操作：collStats、convertToCapped、createCollection、dbHash、dbStats、dropCollection、createIndex、dropIndex、find、insert、killCursors、listIndexes、listCollections、remove、renameCollectionSameDB、update。
其他用户角色不显得那么重要，就不一一展开去聊了。这里整理了一张汇总的表格：

用户自定义角色

虽然MongoDB提供了一系列内置角色，但有时内置角色所包含的权限并不满足所有需求，所以MongoDB也提供了创建自定义角色的方法。当创建一个自定义角色时需要进入指定数据库进行操作，因为MongoDB通过数据库和角色名称对角色进行唯一标识。
除了在admin数据库中创建的角色之外，在其它数据库中创建的自定义角色包含的权限只适用于角色所在的数据库，并且只能继承同数据库其它角色的权限。在admin数据库中创建的自定义角色则不受此限制。
MongoDB将所有的角色信息存储在admin数据库的system.roles集合中，不建议直接访问此集合内容，而是通过角色管理命令来查看和编辑自定义角色。
用户具有创建自定义角色、查看自定义角色、更新自定义角色、添加角色权限、删除角色权限、添加角色集成的角色、删除角色继承的角色、删除自定义角色等操作权限。具体可以参考官方文档链接2。

用户

MongoDB是基于角色的访问控制，所以创建用户需要指定用户的角色，在创建用户之前需要满足：

1. 先在admin数据库中创建角色为userAdmin或userAdminAnyDatabase的用户作为管理用户的用户，姑且称之为管理员吧；
2. 启用访问控制，进行登录用户验证，这样创建用户才有意义。
   同样地，管理员具有操作用户的权限，如创建用户管理的用户、开启访问控制、用户管理用户验证、创建普通用户、查看用户信息、为用户添加角色、更新用户信息、为用户回收角色、更改用户密码、删除用户。具体可以参考官方文档链接3。
   

总结

对于基于角色的用户访问控制能够更为精细地控制访问用户的权限。在新的版本当中对于密码加密机制以及加密算法都做了很大的改进与提升，通过这次总结梳理可以给本文总结如下：

1. MongoDB中角色和用户是建立在数据库中的；
2. 在哪个数据库中创建用户就需要在哪个数据库中进行验证；
3. 为了更好对用户权限进行控制，最好为每个用户创建一个自定义角色。
   官方参考文档链接：1.https://docs.mongodb.com/manual/tutorial/enable-authentication/
   2.https://docs.mongodb.com/manual/reference/command/nav-role-management/
   3.https://docs.mongodb.com/manual/reference/command/nav-user-management/