Docs Menu

自己管理型レプリカセットをキーファイル認証に更新(ダウンタイムなし)

To secure against unauthorized access, enforce authentication for your deployments. Authentication for replica sets consists of internal authentication among the replica set members, and user access control for clients connecting to the replica set.

If your deployment does not currently enforce authentication, you can use the --transitionToAuth option to enforce authentication without downtime.

This tutorial uses the keyfile internal authentication mechanism for internal security, and SCRAM-based role-based access controls for client connections.

Cloud ManagerまたはMongoDB Ops Managerを使用して配置を管理している場合は、それぞれのCloud ManagerマニュアルまたはMongoDB Ops Managerマニュアルを参照して、認証を強制します。

This tutorial assumes that your replica set can elect a new primary after stepping down the existing primary replica set member. This requires:

A mongod running with --transitionToAuth accepts both authenticated and non-authenticated connections. Clients connected to the mongod during this transition state can perform read, write, and administrative operations on any database.

At the end of the following procedure, the replica set rejects any client attempting to make a non-authenticated connection. The procedure creates users for client applications to use when connecting to the replica set.

See ➤ Configure Role-Based Access Control for user creation and management best practices.

MongoDB バイナリ(mongodmongos)は、デフォルトで localhost にバインドされます。

重要

パスワードは、システムのセキュリティを確保し、悪意のあるアクセスを防止または遅延させるために、ランダムで長く、複雑なものにする必要があります。

重要

IP アドレスの変更による構成の更新を防ぐには、IP アドレスの代わりに DNS ホスト名を使用します。レプリカセット ノードまたはシャーディングされたクラスター ノードを設定するときは、IP アドレスではなく DNS ホスト名を使用することが特に重要です。

分裂されたネットワーク ホライズン全体でクラスターを構成するには、IP アドレスの代わりにホスト名を使用します。 MongoDB 5.0以降、IP アドレスのみが設定されているノードは起動時の検証に失敗し、起動しません。

1

Connect to the primary to create a user with userAdminAnyDatabase role. The userAdminAnyDatabase role grants access to user creation on any database in the deployment.

次の例では、ユーザー fred を作成し、admin データベースに対して userAdminAnyDatabase ロールを付与しています。

重要

パスワードは、システムのセキュリティを確保し、悪意のあるアクセスを防止または遅延させるために、ランダムで長く、複雑なものにする必要があります。

Tip

passwordPrompt() メソッドを様々なユーザー認証管理メソッドやコマンドと組み合わせて使用すると、メソッドやコマンドの呼び出しでパスワードを直接指定する代わりに、パスワードの入力を求めるプロンプトが表示されます。ただし、以前のバージョンの mongo シェルと同様に、パスワードを直接指定することもできます。

admin = db.getSiblingDB("admin")
admin.createUser(
{
user: "fred",
pwd: " passwordPrompt(), // or cleartext password
roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
}
)

At the completion of this procedure, any client that administers users in the replica set must authenticate as this user, or a user with similar permissions.

データベース管理操作に関連する組み込みロールの全リストは、「データベースユーザー ロール」を参照してください。

2

Connect to the primary to create a user with clusterAdmin role. The clusterAdmin role grants access to replication operations, such as configuring the replica set.

次の例では、ユーザー ravi を作成し、admin データベースに対して clusterAdmin ロールを付与しています。

重要

パスワードは、システムのセキュリティを確保し、悪意のあるアクセスを防止または遅延させるために、ランダムで長く、複雑なものにする必要があります。

Tip

passwordPrompt() メソッドを様々なユーザー認証管理メソッドやコマンドと組み合わせて使用すると、メソッドやコマンドの呼び出しでパスワードを直接指定する代わりに、パスワードの入力を求めるプロンプトが表示されます。ただし、以前のバージョンの mongo シェルと同様に、パスワードを直接指定することもできます。

db.getSiblingDB("admin").createUser(
{
"user" : "ravi",
"pwd" : passwordPrompt(), // or cleartext password
roles: [ { "role" : "clusterAdmin", "db" : "admin" } ]
}
)

At the completion of this procedure, any client that administrates or maintains the replica set must authenticate as this user, or a user with similar permissions.

レプリカセットの操作に関連する組み込みロールの完全なリストについては、「クラスター管理ロール」を参照してください。

3

Create users to allow client application to connect and interact with the replica set. At the completion of this tutorial, clients must authenticate as a configured user to connect to the replica set.

See Database User Roles for basic built-in roles to use in creating read-only and read-write users.

The following creates a user with read and write permissions on the foo database.

重要

パスワードは、システムのセキュリティを確保し、悪意のあるアクセスを防止または遅延させるために、ランダムで長く、複雑なものにする必要があります。

Create a user with the readWrite role in the foo database.

Tip

passwordPrompt() メソッドを様々なユーザー認証管理メソッドやコマンドと組み合わせて使用すると、メソッドやコマンドの呼び出しでパスワードを直接指定する代わりに、パスワードの入力を求めるプロンプトが表示されます。ただし、以前のバージョンの mongo シェルと同様に、パスワードを直接指定することもできます。

db.getSiblingDB("foo").createUser(
{
"user" : "joe",
"pwd" : passwordPrompt(), // or cleartext password
roles: [ { "role" : "readWrite", "db" : "foo" } ]
}
)

Clients authenticating as this user can perform read and write operations against the foo database. See 自己管理型配置でユーザーを認証する for more on creating an authenticated connection to the replica set.

ユーザーを追加する方法の詳細については、「ユーザーを追加する 」チュートリアルを参照してください。 新しいユーザーを追加するときは、セキュリティに関するベストプラクティスを考慮してください。

4

At this point in the procedure, the replica set does not enforce authentication. However, client applications can still specify auth credentials and connect to the replica set.

Update client applications to authenticate to the replica set using a configured user. Authenticated connections require a username, password, and the authentication database. See 自己管理型配置でユーザーを認証する.

For example, the following connects to a replica set named mongoRepl and authenticates as the user joe.

mongosh -u joe -password -authenticationDatabase foo --host mongoRepl/mongo1.example.net:27017, mongo2.example.net:27017, mongo3.example.net:27017

-pコマンドライン オプションにパスワードを指定しない場合、 mongoshはパスワードの入力を要求します。

If your application uses a MongoDB driver, see the associated driver documentation for instructions on creating an authenticated connection.

At the completion of this tutorial, the replica set rejects non-authenticated client connections. Performing this step now ensures clients can connect to the replica set before and after the transition.

5

キーファイル認証では、レプリカセット内の各 mongod インスタンスは、配置内の他のノードを認証するための共有パスワードとしてキーファイルの内容を使用します。正しいキーファイルを持つ mongod のインスタンスのみがレプリカセットに参加できます。

注意

内部メンバーシップ認証用のキーファイルでは、キーファイル内に複数のキーを含めるために YAML 形式が使用されます。YAML 形式は次のいずれかを受け入れます。

  • 1 つのキー文字列(以前のバージョンと同じ)

  • キー文字列のシーケンス

YAML 形式は、テキストファイル形式を使用する既存の単一のキー キーファイルと互換性があります。

キーの長さは 6 文字から 1024 文字の間で、base64 セット内の文字のみを含めることができます。レプリカセットのすべてのノードは、少なくとも 1 つの共通キーを共有する必要があります。

注意

UNIX システムでは、キーファイルにグループ権限またはワールド権限があってはなりません。Windows システムでは、キーファイルの権限はチェックされません。

キーファイルは、選択した任意の方法で生成できます。たとえば、次の操作では、openssl を使用して、共有パスワードとして使用する疑似ランダムの複雑な 1024 文字の文字列を生成します。次に、chmod を使用してファイル権限を変更し、ファイル所有者のみに読み取り権限を付与します。

openssl rand -base64 756 > <path-to-keyfile>
chmod 400 <path-to-keyfile>

キーファイルの使用に関する詳細と要件については、「キーファイル」を参照してください。

6

レプリカセットをホストしている各サーバーにキー ファイルをコピーします。mongod インスタンスを実行中のユーザーがファイルの所有者であり、キーファイルにアクセスできるようにしてください。

USB ドライブやネットワーク接続ストレージ デバイスなど、mongod インスタンスをホストしているハードウェアから簡単に取り外せるストレージ メディアにキーファイルを保存しないでください。

7

Restart each secondary or arbiter member in the replica set, including in the configuration:

You must restart each member one at a time to ensure a majority of members in the replica set remain online.

From a mongosh session that is connected to the secondary or arbiter, issue the db.shutdownServer() against the admin database.

admin = db.getSiblingDB("admin")
admin.shutdownServer()

Specify the following settings in your 構成ファイル.

mongodmongosは、デフォルトで localhost にバインドされます。 配置のノードが異なるホスト上で実行されている場合、またはリモート クライアントを配置に接続する場合は、 net.bindIp設定を指定する必要があります。

security:
keyFile: <path-to-keyfile>
transitionToAuth: true
replication:
replSetName: <replicaSetName>

Specify the --config option with the path to the configuration file when starting the mongod.

mongod --config <path-to-config-file>

構成ファイルの詳細については、構成オプションを参照してください。

Alternatively, you can use the equivalent mongod command-line options (e.g. --transitionToAuth and --keyFile) when starting your mongod. See the mongod reference page for a complete list of options.

配置に応じて、追加の設定を含めます。

At the end of this step, all secondaries and arbiters should be up and running with security.transitionToAuth set to true.

8

Step down the primary member in the replica set and restart the member, including in its configuration:

Connect to the primary using mongosh and step down the primary using the rs.stepDown() method.

rs.stepDown()

Once the primary steps down and the replica set elects a new primary, shut down the old primary mongod.

From a mongosh session that is connected to the old primary, issue the db.shutdownServer() on the admin database.

admin = db.getSiblingDB("admin")
admin.shutdownServer()

Specify the following settings in your 構成ファイル.

構成に必要な追加オプションを含めます。 たとえば、リモート クライアントを使用して配置に接続する場合や、配置ノードを異なるホスト上で実行する場合は、 net.bindIp設定を指定します。

security:
keyFile: <path-to-keyfile>
transitionToAuth: true
replication:
replSetName: <replicaSetName>

Start the mongod using the configuration file.

mongod --config <path-to-config-file>

構成ファイルの詳細については、構成オプションを参照してください。

Alternatively, you can use the equivalent mongod command-line options (e.g. --transitionToAuth and --keyFile) when starting your mongod. See the mongod reference page for a complete list of options.

配置に応じて、追加の設定を含めます。

At the end of this step, all members of the replica set should be up and running with security.transitionToAuth set to true and security.keyFile set to the keyfile path.

9

Restart each secondary or arbiter member in the replica set, removing the security.transitionToAuth option on restart. You must do this one at a time to ensure a majority of members in the replica set remain online.

If the majority of replica set members are offline at the same time, the replica set may go into read-only mode.

接続 mongosh to the secondary or arbiter, and issue the db.shutdownServer() on the admin database.

admin = db.getSiblingDB("admin")
admin.shutdownServer()

Restart the mongod, this time without the security.transitionToAuth option but with internal authentication mechanism such as security.keyFile.

Specify the following settings in your 構成ファイル.

構成に必要な追加オプションを含めます。 たとえば、リモート クライアントを使用して配置に接続する場合や、配置ノードを異なるホスト上で実行する場合は、 net.bindIp設定を指定します。

security:
keyFile: <path-to-keyfile>
replication:
replSetName: <replicaSetName>

構成ファイルを使用して mongod を起動します。

mongod --config <path-to-config-file>

構成ファイルの詳細については、構成オプションを参照してください。

You can also use the equivalent mongod options when starting your mongod. See the mongod reference page for a complete list of options.

配置に応じて、追加の設定を含めます。

At the end of this step, all secondaries and arbiters should be up and running with internal authentication configured, but without security.transitionToAuth. Clients can only connect to these mongod instances by using the configured client authentication mechanism.

10

Step down the primary member in the replica set, then restart it without the security.transitionToAuth option.

重要

At the end of this step, clients not connecting with auth cannot connect to the replica set. Update clients to connect with authentication before completing this step to avoid loss of connectivity.

Connect to the primary using mongosh and step down the primary using the rs.stepDown() method.

rs.stepDown()

Once the primary steps down and the replica set elects a new primary, shut down the old primary mongod.

From a mongosh session that is connected to the old primary, issue the db.shutdownServer() on the admin database.

admin = db.getSiblingDB("admin")
admin.shutdownServer()

Restart the mongod, this time without the security.transitionToAuth option but with the internal authentication mechanism such as security.keyFile.

Specify the following settings in your 構成ファイル.

security:
keyFile: <path-to-keyfile>
replication:
replSetName: <replicaSetName>

構成ファイルを使用して mongod を起動します。

mongod --config <path-to-config-file>

構成ファイルの詳細については、構成オプションを参照してください。

You can also use the equivalent mongod options when starting your mongod. See the mongod reference page for a complete list of options.

配置に応じて、追加の設定を含めます。

At the end of this step, all members of the replica set should be up and running with authentication enforced. Clients can only connect to these mongod instances by using the configured client authentication mechanism.

X. を使用した内部認証の詳細については、「509 自己管理型MongoDBによるメンバーシップ認証に X. 証明書を使用 」を参照してください。509

鍵ファイルによる内部認証から X.509 内部認証にアップグレードするには、「 自己管理型MongoDB を鍵ファイル認証から X. 認証にアップグレードする509 」を参照してください。