自己管理型レプリカセットをキーファイル認証に更新(ダウンタイムなし)
Overview
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を使用して配置を管理している場合は、それぞれの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 majority of voting replica set members available after stepping down the primary.
At least one secondary member that is not delayed, hidden, or Priority 0.
Transition State
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.
Client Access
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.
IP バインディング
Passwords
重要
パスワードは、システムのセキュリティを確保し、悪意のあるアクセスを防止または遅延させるために、ランダムで長く、複雑なものにする必要があります。
既存のレプリカセットに対するキーファイルアクセス制御の強制
重要
IP アドレスの変更による構成の更新を防ぐには、IP アドレスの代わりに DNS ホスト名を使用します。レプリカセット ノードまたはシャーディングされたクラスター ノードを設定するときは、IP アドレスではなく DNS ホスト名を使用することが特に重要です。
分裂されたネットワーク ホライズン全体でクラスターを構成するには、IP アドレスの代わりにホスト名を使用します。 MongoDB 5.0以降、IP アドレスのみが設定されているノードは起動時の検証に失敗し、起動しません。
ユーザー管理者を作成します。
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.
データベース管理操作に関連する組み込みロールの全リストは、「データベースユーザー ロール」を参照してください。
クラスター管理者の作成
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.
レプリカセットの操作に関連する組み込みロールの完全なリストについては、「クラスター管理ロール」を参照してください。
Create users for client applications.
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.
ユーザーを追加する方法の詳細については、「ユーザーを追加する 」チュートリアルを参照してください。 新しいユーザーを追加するときは、セキュリティに関するベストプラクティスを考慮してください。
Update Client Applications
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.
キーファイルを作成します。
キーファイル認証では、レプリカセット内の各 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>
キーファイルの使用に関する詳細と要件については、「キーファイル」を参照してください。
Restart each secondary or arbiter member of the replica set with transitionToAuth
.
Restart each secondary or arbiter member in the replica set, including in the configuration:
The
security.transitionToAuth
setting. Starting themongod
withsecurity.transitionToAuth
set totrue
places the instance in a transition state where it can accept and create both authenticated and non-authenticated connections.An internal authentication mechanism such as
security.keyFile
.
You must restart each member one at a time to ensure a majority of members in the replica set remain online.
Shut down the secondary or arbiter members.
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()
Restart the secondary or arbiter members with transitionToAuth
Specify the following settings in your 構成ファイル.
security.keyFile
, with the path to the keyfile.replication.replSetName
to the original replica set name.security.transitionToAuth
からtrue
。
mongod
とmongos
は、デフォルトで 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
.
Step down the primary member of the replica set and restart it with --transitionToAuth
.
Step down the primary member in the replica set and restart the member, including in its configuration:
The
security.transitionToAuth
setting. Starting themongod
withsecurity.transitionToAuth
set totrue
places the instance in a transition state where it can accept and create both authenticated and non-authenticated connections.An internal authentication mechanism such as
security.keyFile
.
Step down the primary replica set member
Connect to the primary using mongosh
and step down
the primary using the rs.stepDown()
method.
rs.stepDown()
Shut down the old primary
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 old primary with transitionToAuth
Specify the following settings in your 構成ファイル.
security.keyFile
, with the path to the keyfile.replication.replSetName
to the original replica set name.security.transitionToAuth
からtrue
。
構成に必要な追加オプションを含めます。 たとえば、リモート クライアントを使用して配置に接続する場合や、配置ノードを異なるホスト上で実行する場合は、 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.
Restart secondaries and arbiters without --transitionToAuth
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.
Shut down the secondary or arbiter members
接続 mongosh
to the secondary or arbiter, and
issue the db.shutdownServer()
on the admin
database.
admin = db.getSiblingDB("admin") admin.shutdownServer()
Restart the secondary or arbiter members without transitionToAuth
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 構成ファイル.
security.keyFile
, with the path to the keyfile.replication.replSetName
to the original replica set name.
構成に必要な追加オプションを含めます。 たとえば、リモート クライアントを使用して配置に接続する場合や、配置ノードを異なるホスト上で実行する場合は、 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.
Step down and restart the primary replica set member without --transitionToAuth
.
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.
Step down the primary replica set member
Connect to the primary using mongosh
and step down
the primary using the rs.stepDown()
method.
rs.stepDown()
Shut down the old primary
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 old primary without transitionToAuth
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
, with the path to the keyfile.replication.replSetName
to the original replica set name.
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 内部認証
X. を使用した内部認証の詳細については、「509 自己管理型MongoDBによるメンバーシップ認証に X. 証明書を使用 」を参照してください。509
鍵ファイルによる内部認証から X.509 内部認証にアップグレードするには、「 自己管理型MongoDB を鍵ファイル認証から X. 認証にアップグレードする509 」を参照してください。