MongoDB部署副本集

首发于sf.gg. 原文翻译自 MongoDB 官方文档。我一直认为，与其从网上随便扒一些教程，不如认认真真阅读一遍官方的文档。

在副本集上实现访问控制依赖于以下配置：

• 副本集成员之间使用内部身份验证并且
• 副本集客户端与副本集之间使用基于角色的访问控制

在本教程中，副本集中的成员之间使用相同的内部身份验证机制和设置。

强制身份验证就是强制用户访问控制，如需使用客户端连接到此副本集需要使用一个账户，更多信息，参见访问控制

Cloud Manager 与 Ops Manager

如果你正在或者计划使用Cloud Manager 或者 Ops Manager，考虑使用内置的功能来部署一个副本集与强制执行的访问控制，

参阅Cloud Manager manual 或者Ops Manager manual中的 部署副本集 参阅Cloud Manager manual 或者Ops Manager manual 中关于MongoDB部署中的访问控制。

系统需求

操作系统

本教程主要使用mongod 进程，Windows用户应该使用mongod.exe代替。

密钥文件安全机制

密钥文件是最低限度的安全机制，最适合用于测试或开发环境。对于生产环境，我们建议使用x.509 证书。

访问控制

本教程仅在 admin 数据库创建最小数目的管理用户，对于用户身份验证，本教程使用了默认的SCRAM-SHA-1用户身份验证机制。挑战-相应安全机制最适用于开发或者测试环境，对于生产环境，我们推荐使用x.509 证书或者LDAP代理权威认证（仅MongoDB企业版提供）或者 Kerberos Authentication （仅MongoDB企业版提供） 有关创建用户特定的身份验证机制的详细信息，请参阅特定的身份验证机制页。

参阅 配置基于角色的访问控制 获取对于创建和管理用户的最佳实践。

部署一个新的、基于Keyfile实现访问控制的副本集

####1. 创建一个keyfile keyfile的内容被副本集中的成员用作共享密码，同一个副本集中的成员使用的keyfile的内容必须相同。 你可以使用任意方法生成keyfile，keyfile内容的长度在6到1024个字符之间。

注意：在UNIX平台上，keyfile的权限应该设置为组与其他没有任何权限，在Windows系统上对keyfile的权限没有检查。

下述操作展示了如何使用 openssl 获取一个复杂的、1024位的伪随机字符串作为keyfile的内容。然后使用 chmod 为keyfile更改权限为只有文件拥有者具有读权限。

openssl rand -base64 756 > <path-to-keyfile>
chmod 400 <path-to-keyfile>
复制代码

参阅keyfile 获取更多使用keyfile的需求和细节。

####2.把keyfile复制到副本集中的每一个成员当中。 复制keyfile到副本集中的每一台成员服务器上，使用相同的存放路径。

重要：不要使用网络共享地址或者可移动存储的地址比如USB驱动器来存放这个keyfile。

确保运行中的mongod可以访问到这个地址。

####3.为副本集中的每个成员启用访问控制。 带keyfile参数启动mongod可以同时强制开启内部身份验证和 基于角色的访问控制 。

对于副本集内的每一个mongod来讲，可以选择使用配置文件或者命令行启动。

重要：一个副本集初始化完成后你无法再更改副本集的名字，请在这个阶段选择一个合适的副本集的名字以避免后续的麻烦。

配置文件如果选择使用配置文件，就需要配置security.keyFile来指定keyfile的路径，并设置 replication.replSetName 选项来指定副本集的名字：

security:
 keyFile: <path-to-keyfile>
replication:
 replSetName: <replicaSetName>
复制代码

使用配置文件启动mongod:

mongod --config <path-to-config-file>
复制代码

关于配置文件的更多信息，参见配置文件选项

使用命令行如果使用命令行，启动mongod的时候加上 --keyFile 和 --replSet 参数:

mongod --keyFile <path-to-keyfile> --replSet <replicaSetName> 要获取启动参数的更多信息，参见mongod页面，包含了适合你部署的附加选项。

####4.通过本地接口连接到副本集中的成员 通过本地接口连接到 mongoshell来配置mongod实例，你必须在运行mongod实例的机器上运行mongoshell.本地接口仅在副本集还没有创建用户的时候可用，当第一个用户被创建，则本地接口会被关闭。 ####5.初始化副本集 可以使用rs.initiate()方法来初始化一个副本集，也可以使用副本集配置文档来初始化一个副本集，副本集配置文档包含：

• _id字段，_id字段必须与mongod的 **-- --replSet **一致。
• members 字段，members字段是一个数组，记录了副本集中的每一个成员。 查看副本集配置获取更多关于副本集配置文档的信息。 下面是一个使用 rs.initiate() 命令初始化具有三个成员的副本集实例的示例，请留意，副本集名称需要带引号：

rs.initiate(
  {
    _id : <replicaSetName>,
    members: [
      { _id : 0, host : "mongo1.example.net:27017" },
      { _id : 1, host : "mongo2.example.net:27017" },
      { _id : 2, host : "mongo3.example.net:27017" }
    ]
  }
 )
复制代码

re.initiate()方法会触发一个选举过程推举出一个成员为primary. 进行下一步之前，连接到primary，使用rs.status()方法查找primary。

6.创建用户管理员

重要：当你创建了第一个用户之后，localhost exception将不再可用。第一个用户必须有权限创建其他用户，比如userAdminAnyDatabase，这确保了在localhost exception关闭以后你能在副本集内增加更多用户。 至少需要一个用户具有权限创建其他用户，否则一旦localhostexception关闭你可能无法对用户新增或者修改权限，并因此无法进行必要的操作。

使用db.createUser()方法增加一个用户。该用户在 admin 数据库上至少是 userAdminAnyDatabase 角色。 你必须连接到 primary 主机上创建用户。 以下示例展示了如何在 admin 数据库上创建一个角色为userAdminAnyDatabase的用户fred.

重要：密码应该是随机设定的，具有一定长度和复杂度，能够确保系统安全，防止或延缓恶意访问。

admin = db.getSiblingDB("admin") admin.createUser(   {
    user: "fred",
    pwd: "changeme1",
    roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]   } )
复制代码

参阅数据库用户角色一章获取内置角色的完整列表和相关的数据库管理操作。

7.管理员身份验证

管理员身份需要到 admin 上验证 在mongo shell 中使用db.auth()方法进行验证。以下示例展示了如何验证 fred 为管理员：

db.getSiblingDB("admin").auth("fred", "changeme1" ) 或者连接到副本集中primary成员，重新打开一个mongo shell并使用 ** -u , -p ** 和** --authenticationDatabase**参数： mongo -u "fred" -p "changeme1" --authenticationDatabase "admin"

8.创建集群管理员（ clusterAdmin）

clusterAdmin角色被授权为可以访问集群操作，比如创建一个副本集。 创建一个集群管理员用户需要在 admin 数据库内指定一个用户为 clusterAdmin角色：

db.getSiblingDB("admin").createUser(   {
    "user" : "ravi",
    "pwd" : "changeme2",
    roles: [ { "role" : "clusterAdmin", "db" : "admin" } ]   } ) 
复制代码

9.创建额外的用户（可选）

创建用户来允许客户端（使用这些用户）连接到副本集实例，参阅数据库用户与角色一章，了解如何基于基本内置角色来创建具备只读权限和读写权限的用户。

你可能还需要额外的管理用户，请参阅用户一章获取更多信息。

X.509内部验证

更多关于X.509内部验证的信息，参阅 使用X.509证书验证成员资格 。 将keyfile内部验证升级到使用X.509内部验证，，请参阅此处。