整理MongoDB文档:身份验证

整理MongoDB文档:身份验证

个人博客，求关注。

文章概叙

本文主要讲MongoDB在单机状态下的账户配置。理解了MongoDB的语法，对于如何配置用户权限会知道怎么配置，但是请注意给谁配置什么权限才是最重要的。

最小权限原则

系统的每个程序或者用户应该使用完成工作所需的最小权限工作

在MongoDB中，最小权限原则指的用户的访问、操作权限应限制为仅执行日常授权活动绝对需要的那些资源。

如一个标准的开发者，你应该给予的是开发环境下的特定库的读写权限，甚至必要情况下给予admin的权限，以免影响到开发的进度。

但对一个生产环境的数据库，应该只给予开发者查看数据的权限，最好不要给予修改数据甚至是admin的权限，不然人家删库跑路，或者遇到新手修改了数据库结构导致线上爆炸，我想你可能过不了一个好年了。。。

MongoDB用户角色

在 MongoDB 中，用户角色用于控制用户对数据库和集合的访问权限。

在MongoDB中，访问权限并不是针对整个系统的，而是针对数据库的。也就是说你给一个开发者分配了一个账号，并不是说这个开发者可以直接登陆我们的DB，并且访问所有的DB，而是给这个开发者a库以及b库的权限，然后他可以在指定的两个库中进行操作，但是无法到c库中进行为所欲为的操作。

除了从数据库的层面进行管控，还对权限方面进行区分以及管控，如前面所提的，开发者在生产环境下，应该只对数据库有查看的权限，不应该对其有修改的权限，也就是说查看以及修改两者是分开的。

接下来用一两个例子，通过对MongoDB的语法来了解角色权限这一块。

内置角色

https://www.mongodb.com/docs/manual/reference/built-in-roles/

MongoDB为我们创建了一堆的角色，被称为内置角色。而每一个内置角色的权限都不相同，当前的版本是依据7.x，上述已经将文章的原链接放上去了，强烈建议大家去查看。

下面先列出所有的角色类别。

数据库用户角色

数据库用户角色拥有read 以及readWriter权限。

read 提供读取所有非系统集合上的数据的能力。即除了config、local、admin的表。

readWriter 提供在read的能力上外加修改所有非系统集合的能力。

数据库管理角色

数据库管理角色拥有dbAdmin, dbOwner, userAdmin权限。

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

userAdmin提供在当前数据库，即可以在当前的数据库中修改人员的权限。

dbOwner数据库所有者可以对数据库执行任何管理操作。此角色结合了由readWrite, dbAdmin和userAdmin角色。

群集管理角色

集群管理角色拥有clusterAdmin, clusterManager, clusterMonitor, hostManager的权限。

clusterManager提供对群集的管理和监视操作，一个具有此角色的用户可以访问和数据库，这些数据库用于分片和复制。

clusterMonitor提供对监视工具的只读访问权限。

hostManager提供监视和管理服务器的功能。

clusterAdmin提供最大的群集管理访问权限。此角色结合了 授予的特权clusterManager, clusterMonitor和hostManager角色。此外，该角色还提供dropDatabase行动。

备份和还原角色

备份和还原角色拥有backup、restore。

backup提供备份数据所需的最小权限。

restore提供从备份还原数据的权限。

全数据库角色

全数据库角色拥有readAnyDatabase, readWriteAnyDatabase, userAdminAnyDatabase, dbAdminAnyDatabase的权限。

readAnyDatabase提供除了admin, config, local库之外的所有数据库的读取权限。

readWriteAnyDatabase在readAnyDatabase的基础上,外加提供除了admin, config, local库之外的所有数据库的编辑权限。

userAdminAnyDatabase提供除了admin, config, local库之外的所有数据库的用户管理操作访问权限。

dbAdminAnyDatabase提供除了admin, config, local库之外的所有数据库的管理员管理操作访问权限。

超级用户角色

超级用户角色拥有root 权限。

root为角色提供为任何用户分配任何权限的功能、任何数据库，这意味着具有这些角色之一的用户可以为自己分配对任何数据库的任何特权。

内部角色

内部角色拥有的是__system权限，一般不会使用到，也超级不建议分配出去。所以不做介绍。

创建用户

当了解了MongoDB的各个角色后，我们就进入到创建角色的篇章，基于前面所提及的最小权限原则，我们创建一个root账号作为后门，以及创建一个在test的只读账号还有在test的读写账号做测试，首先我们需要进入到admin库中。

use admin

db
  .createUser({
    user: 'root',
    pwd: 'root',
    roles: ['root']
  })

创建完了root权限后，再创建两个上述的用户。

db.createUser(
  {
    user: "testRead",
    pwd: passwordPrompt(),
    roles: [{ role: "readWrite", db: "test" }]
  }
)

db.createUser(
  {
    user: "testReadWrite",
    pwd: passwordPrompt(),
    roles: [{ role: "readWrite", db: "test" }]
  }
)

使用passwordPrompt()来代替原本的文字输入，毕竟这样子毕竟正经点。

列出用户

当前创建了三个用户，但是在继续操作之前，我们需要将其打印出来，以防止你在测试的时候有问题，但是自己不知道，在admin的库下，输入下方的指令。

db
  .system
  .users
  .find(
    {},
    { "user": 1, "roles": 1 }
  )

此时可以看到，不小心将testRead的权限写错了，应该为read权限，所以后续我们要修改它，但是现在先记下来，不做任何改动。

启用访问控制

在MongoDB部署上启用访问控制会强制执行身份验证。启用访问控制后，用户需要标识自己的身份并且只能执行符合授予的权限的操作分配给其用户的角色。

启动访问控制的方式有两种。

一种在命令行中启，需要在命令行选项中增加 --auth：

mongod --auth --port 27017

第二种方式是使用配置文件启动MongoDB，在配置文件中增加security.authorization设置

security:
    authorization: enabled

由于本人喜欢用net start mongodb来启动单机服务，所以就直接使用第二种来启动账号验证了。

验证权限

现在我们重新启动，并且进入到服务中了，因此我们需要调用下面的方法来输入我们的账号密码，先拿个root账号试试

db.auth("root","root")

接着，我们想起了之前设置错误的账号–test库下面的testRead，此时，可以使用下面的语法进行更新(正常情况下，都是在admin账号下进行的操作，不会在未开启auth的时候进行修改，所以此时才进行修改，尽可能的模拟出开发环境

db
  .updateUse(
    "testRead",
    {
      roles: [
        { role: "read", db: "test" }]
    })

修改成功，接下来查看testRead账号是否只有权限查看test下的数据。当然了，修改密码，也是可以这么设置的，只是参数修改为password。

可以看到，当更改为了testRead账号之后，只能执行查看test库下的数据，无法进行任何的修改操作。

删除角色

对于角色的操作，有了增、改、查，那么就剩下删除的api了，而对于删除，我们需要使用到之前的root账号，并且在admin库下进行修改。
删除角色比较简单，需要注意的是在admin库中进行删除，并且需要有管理员权限。可以使用

db
  .system
  .users
  .remove({ "user": "testRead" })

至此，单机模式下的mongodb 账号验证就完成了，更多的是需要注意每一个role代表的是什么，如果无法满足角色要求，还有一个更加详细的自定义角色涉及到集合，但是很少用到，太细致的权限反而会加大开发成本，总不能每加一个集合，都要考虑分配给谁谁谁权限吧？

可视化工具中访问

mongodb://username:password@localhost:27017

mongodb://root:root@localhost:27017