MongoDB部署副本集

本页包含内容

• 概览
• 系统需求
• 部署一个基于Key文件实现访问控制的副本集
• x.509 内部身份验证

概述

首发于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 <username>, -p <password> 和--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内部验证，，请参阅此处。