升级到 SCRAM

在本页面

Overview

从 3.0 版开始,MongoDB 包括对盐分挑战响应认证机制(SCRAM)的支持,它更改了 MongoDB 使用和存储用户凭据的方式。

如果您是从没有任何用户的新 3.0 部署开始,或者是从没有用户的 2.6 数据库升级,那么 不需要将身份验证架构升级到 SCRAM 。所有新创建的用户将具有正确的 SCRAM 格式。

对于具有现有 MongoDB 质询和响应(MONGODB-CR)用户数据模型的 3.0 部署,以下过程将身份验证架构升级到 SCRAM。

Recommendation

与以前的默认身份验证机制 MongoDB 质询和响应(MONGODB-CR)相比,SCRAM 表示安全性得到了显着提高。有关使用 SCRAM 优于 MONGODB-CR 的优势,请参见SCRAM Advantages

从 MongoDB 3.6 开始,不建议使用 MONGODB-CR 身份验证机制。

强烈建议您从 MONGODB-CR 身份验证架构升级到 SCRAM。

现有的 2.6 用户凭据

以下信息详细说明了用于 MongoDB 3.0 部署的身份验证机制,该机制包含 MONGODB-CR 用户凭据;也就是说,在升级身份验证架构之前。

如果您从具有现有用户身份验证数据的 2.6 版升级到 MongoDB 3.0(或针对 2.6 数据文件运行 MongoDB 3.0 二进制文件):

MongoDB Users 凭证存储在 3.0 中 Behavior
现有的挑战响应用户 MONGODB-CR credentials 对于不支持 MongoDB 3.0 功能的较旧版本的驱动程序,您将 continue 使用 MONGODB-CR。


对于支持 MongoDB 3.0 功能(请参阅驱动程序兼容性更改)的驱动程序,默认行为是在身份验证期间将凭据临时转换为 SCRAM。此临时转换不会影响凭据的存储方式。如果选择使用MONGODB-CR,则必须显式指定MONGODB-CR作为身份验证机制。
|新的挑战响应用户| MONGODB-CR 凭据|对于不支持 MongoDB 3.0 功能的较旧版本的驱动程序,您将 continue 使用 MONGODB-CR。
对于支持 MongoDB 3.0 功能(请参阅驱动程序兼容性更改)的驱动程序,默认行为是在身份验证期间将凭据临时转换为 SCRAM。此临时转换不会影响凭据的存储方式。如果选择使用MONGODB-CR,则必须显式指定MONGODB-CR作为身份验证机制。

如果通过导入 2.6 用户身份验证数据来填充 MongoDB 3.0 用户数据:

MongoDB Users 凭证存储在 3.0 中 Behavior
现有的挑战响应用户 MONGODB-CR credentials 对于不支持 MongoDB 3.0 功能的较旧版本的驱动程序,您将 continue 使用 MONGODB-CR。


对于支持 MongoDB 3.0 功能(请参阅驱动程序兼容性更改)的驱动程序,默认行为是在身份验证期间将凭据临时转换为 SCRAM。此临时转换不会影响凭据的存储方式。如果选择使用MONGODB-CR,则必须显式指定MONGODB-CR作为身份验证机制。
|新的挑战响应用户| SCRAM 凭证|需要支持 MongoDB 3.0 功能的驱动程序(请参阅驱动程序兼容性更改)。只能使用 SCRAM。

Considerations

Backwards Incompatibility

升级到 SCRAM 的过程**丢弃 2.6 使用的MONGODB-CR凭据。因此,该过程是“不可逆的”,缺少从备份还原的过程。

该过程还将禁用MONGODB-CR作为身份验证机制。

Requirements

要升级身份验证模型,您必须在admin数据库中具有角色userAdminAnyDatabase的用户。

Timing

由于升级用户身份验证模型后降级更加困难,因此,一旦将 MongoDB 二进制文件升级到版本 3.0,请在执行此过程之前将 MongoDB 部署运行一两天。

这使 3.0 有一些时间可以“老化”,并降低了在用户特权模型升级后发生降级的可能性。用户身份验证和访问控制将 continue 像 2.6 中那样工作。

如果您决定立即升级用户身份验证模型,而不是 await 建议的“预烧”期,则对于分片群集,必须在分片群集升级后至少 await10 秒钟,以运行 authentication upgrade 命令。

Replica Sets

对于副本集,只需在primary上运行升级过程,因为更改将自动复制到辅助副本。

Sharded Clusters

对于分片群集,请连接到一个mongos实例,然后运行升级过程以升级群集的身份验证数据。默认情况下,该过程还将升级分片的身份验证数据。

要覆盖此行为,请使用upgradeShards: false选项运行authSchemaUpgrade。如果选择覆盖,则必须先在mongos上运行升级过程,然后在每个分片的primary成员上运行该过程。

对于分片群集,请不要对config servers直接运行升级过程。而是使用一个mongos实例执行升级过程,以与配置数据库进行交互。

Upgrade Drivers

您必须将将连接到已升级的数据库实例的应用程序使用的所有驱动程序升级到支持 SCRAM 的版本。支持 SCRAM 的最低驱动程序版本为:

Driver Language Version
C 1.1.0
C++ 1.0.0
C# 1.10
Java 2.13
Node.js 1.4.29
Perl 1.0.0
PHP ext-mongo 1.6, ext-mongodb 1.0
Python 2.8
Motor 0.4
Ruby 1.12
Scala 2.8.0

有关下载升级驱动程序的链接,请参见MongoDB 驱动程序页面

Prerequisites

在升级身份验证模型之前,您应该先将 MongoDB 二进制文件升级到 3.0。对于分片群集,请确保所有群集组件均为 3.0.

将 2.6 MONGODB-CR 用户凭证升级到 SCRAM 用户凭证

Warning

升级到 SCRAM 的过程**丢弃 2.6 使用的MONGODB-CR凭据。因此,该过程是“不可逆的”,缺少从备份还原的过程。

该过程还将禁用MONGODB-CR作为身份验证机制。

Important

要使用 SCRAM,如果当前驱动程序版本不支持 SCRAM,则必须进行驱动程序升级。有关详情,请参见所需的驱动程序版本

连接到 MongoDB 实例。

以角色userAdminAnyDatabase的身份使用admin数据库用户连接并验证单个部署的mongod实例,副本集的主mongod或分片群集的mongos并对其进行身份验证。

升级身份验证架构。

admin数据库中使用authSchemaUpgrade命令通过mongo Shell 更新用户数据。

运行 authSchemaUpgrade 命令。

db.adminCommand({authSchemaUpgrade: 1});

如果发生错误,您可以安全地重新运行authSchemaUpgrade命令。

分片群集 authSchemaUpgrade 注意事项。

对于没有 分片本地用户的分片群集,默认情况下,authSchemaUpgrade也会升级分片的授权数据,从而完成升级。

但是,您可以通过在命令中包含upgradeShards: false来覆盖此行为,如以下示例所示:

db.adminCommand(
   {authSchemaUpgrade: 1, upgradeShards: false }
);

如果您覆盖默认行为,或者您的群集具有分片本地用户,则在mongos实例上运行authSchemaUpgrade后,您需要为每个分片连接到主数据库,并在mongos上升级后重复升级过程。

Result

完成此过程之后,数据库中的所有用户都将拥有 SCRAM 凭据,并且任何随后创建的用户也将拥有这种类型的凭据。

首页