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

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

プライマリに接続して、 userAdminAnyDatabaseロールを持つユーザーを作成します。 userAdminAnyDatabaseロールは、配置内の任意のデータベースでのユーザー作成へのアクセスを許可します。

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

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

この手順の完了時に、レプリカセット内のユーザーを管理するすべてのクライアントは、このユーザーまたは同様の権限を持つユーザーとして認証する必要があります。

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

クラスター管理者の作成

プライマリに接続して、 clusterAdminロールを持つユーザーを作成します。 clusterAdminロールは、レプリカセットの構成などのレプリケーション操作へのアクセスを許可します。

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

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

この手順の完了時に、レプリカセットを管理または維持するすべてのクライアントは、このユーザーまたは同様の権限を持つユーザーとして認証される必要があります。

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

クライアント アプリケーションのユーザーを作成します。

ユーザーを作成して、クライアント アプリケーションがレプリカセットに接続して交流できるようにします。 このチュートリアルの完了時に、クライアントはレプリカセットに接続するために構成されたユーザーとして認証する必要があります。

読み取り専用ユーザーや読み取り/書込みユーザーの作成に使用する基本的な組み込みロールについては、「データベースユーザーのロール」を参照してください。

以下では、 fooデータベースに対して読み取りと書込み権限を持つユーザーが作成されます。

fooデータベースにreadWriteロールを持つユーザーを作成します。

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

このユーザーとして認証するクライアントは、 fooデータベースに対して読み取り操作および書込み操作を実行できます。 レプリカセットへの認証済み接続の作成の詳細については、「自己管理型配置でユーザーを認証する」を参照してください。

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

クライアント アプリケーションの更新

手順のこの時点では、レプリカセットは認証を強制しません。 ただし、クライアント アプリケーションは引き続き認証情報を指定してレプリカセットに接続できます。

構成されたユーザーを使用してレプリカセットで認証するように、クライアント アプリケーションを更新します。 認証された接続には、ユーザー名、パスワード、および認証データベースが必要です。 「自己管理型配置でユーザーを認証する 」を参照してください。

たとえば、次の例ではmongoReplという名前のレプリカセットに接続し、ユーザーjoeとして認証します。

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

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

アプリケーションで MongoDB ドライバーを使用する場合は、認証された接続の作成手順について、関連するドライバーのドキュメント を参照してください。

このチュートリアルを完了すると、レプリカセットは認証されていないクライアント接続を拒否します。 この手順を実行することで、移行の前後でクライアントがレプリカセットに接続できるようになります。

キーファイルを作成します。

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

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

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

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

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

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

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

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

レプリカセットの各セカンダリまたはアービタをtransitionToAuth で再起動します。

構成に含まれるレプリカセット内の各セカンダリノードまたはアービタノードを再起動します。

• security.transitionToAuth設定。 mongodsecurity.transitionToAuthを に設定してtrue を起動すると、 インスタンスは過渡状態になり、認証された接続と非認証の接続の両方を受け入れ、作成できます。

• 内部認証メカニズム（例: security.keyFile 。

レプリカセット内の大多数のノードがオンラインのままになるようにするには、一度に各ノードを 1 つずつ再起動する必要があります。

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

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

--configを起動するときに、構成ファイルへのパスを指定してmongod オプションを指定します。

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

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

あるいは、同等のmongodコマンドライン オプション（例: {--transitionToAuth--keyFilemongod の起動時に と ）が加わります。オプションの完全なリストについては、 mongodリファレンス ページを参照してください。

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

この手順の最後に、すべてのセカンダリとアービタが起動して実行され、 security.transitionToAuthがtrueに設定されます。

レプリカセットのプライマリ メンバーを降格し、--transitionToAuth で再起動します。

レプリカセット内のプライマリノードを降格し、 構成を含む ノードを再起動します。

• security.transitionToAuth設定。 mongodsecurity.transitionToAuthを に設定してtrue を起動すると、 インスタンスは過渡状態になり、認証された接続と非認証の接続の両方を受け入れ、作成できます。

• 内部認証メカニズム（例: security.keyFile 。

rs.stepDown()

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

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

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

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

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

あるいは、同等のmongodコマンドライン オプション（例: {--transitionToAuth--keyFilemongod の起動時に と ）が加わります。オプションの完全なリストについては、 mongodリファレンス ページを参照してください。

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

この手順の最後には、レプリカセットのすべてのノードは起動して実行され、 security.transitionToAuthはtrueに、 security.keyFileはキーファイル パスに設定されます。

を使用せずにセカンダリとアービタを再起動--transitionToAuth

レプリカセット内の各セカンダリノードまたはアービタ ノードを再起動し、再起動時にsecurity.transitionToAuthオプションを削除します。 レプリカセット内の大多数のノードがオンラインのままになるように、これを一度に 1 つずつ行う必要があります。

レプリカセット ノードの過半数が同時にオフラインになると、レプリカセットは読み取り専用モードになることがありGo 。

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

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

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

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

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

を起動するときに、同等のmongod mongodオプションを使用することもできます。オプションの完全なリストについては、 mongodリファレンス ページを参照してください。

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

この手順の最後で、すべてのセカンダリとアービタが起動して実行され、 内部認証 が構成された状態で、かつ が ない状態security.transitionToAuth で実行されている必要があります。クライアントは、構成されたクライアント認証メカニズムを使用して、これらのmongodインスタンスにのみ接続できます。

--transitionToAuthなしでプライマリレプリカセットを降格して再起動します。

レプリカセット内のプライマリメンバーを降格し、 security.transitionToAuthオプションを使用せずに再起動します。

rs.stepDown()

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

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

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

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

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

mongod を起動するときに同等のmongodオプションを使用することもできます。 オプションの完全なリストについては、 mongodリファレンス ページを参照してください。

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

この手順の最後には、レプリカセットのすべてのノードが起動され、認証が強制された状態で実行されている必要があります。 クライアントは、構成されたクライアント認証メカニズムを使用して、これらのmongodインスタンスにのみ接続できます。