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

ユーザー管理者を作成します。

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 ロールを付与しています。

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 ロールを付与しています。

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.

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 のインスタンスのみがレプリカセットに参加できます。

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

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

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

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

キーファイルを各レプリカセットにコピーします。

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

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

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 the mongod with security.transitionToAuth set to true 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.

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

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 the mongod with security.transitionToAuth set to true 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.

rs.stepDown()

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

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.

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

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.

rs.stepDown()

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

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.