自己管理型シャーディングされたクラスターをキーファイル認証に更新

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

キーファイル 認証では、シャーディングされたクラスター内の各mongodまたはmongosインスタンスは、配置内の他のノードを認証するための共有パスワードとしてキーファイルの内容を使用します。 正しいキーファイルを持つmongodまたはmongosインスタンスのみがシャーディングされたクラスターに参加できます。

キーの長さは 6 文字から 1024 文字の間で、base64 セット内の文字のみを含めることができます。 シャーディングされたクラスターのすべてのノードは、少なくとも 1 つの共通キーを共有する必要があります。

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

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

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

シャーディングされたクラスター内の各コンポーネントにキー ファイルをコピーします。

シャーディングされたクラスターのmongodまたはmongosコンポーネントをホストしているすべてのサーバーには、キーファイルのコピーが含まれている必要があります。

シャーディングされたクラスターをホストしている各サーバーにキー ファイルをコピーします。 mongodまたはmongosインスタンスを実行中のユーザーがファイルの所有者であり、キーファイルにアクセスできるようにしてください。

キーファイルを、 mongodまたはmongosインスタンスをホストしているハードウェアから簡単に切断できるストレージメディア（Windows ドライブやネットワーク接続ストレージデバイスなど）にキーファイルを保存しないでください。

バランサーを無効にします。

mongoshをmongosに接続します。

sh.stopBalancer()

移行が進行中の場合、バランサーがすぐに停止しないことがあります。 sh.stopBalancer()メソッドは、バランサーが停止するまで shell をブロックします。

MongoDB 4.2 以降では、 sh.stopBalancer()もシャーディングされたクラスターの自動分割を無効にします。

sh.getBalancerState()を使用して、バランサーが停止していることを確認します。

sh.getBalancerState()

シャーディングされたクラスター バランサーの動作を構成するチュートリアルについては、「 シャーディングされたクラスター バランサーの管理」を参照してください。

mongosシャーディングされたシャーディングされたクラスターのすべての インスタンスをシャットダウンします。

mongoshを各mongosに接続し、シャットダウンします。

adminデータベースでdb.shutdownServer()メソッドを使用して、 mongosを安全にシャットダウンします。

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

クラスター内のすべてのmongosインスタンスがオフラインになるまで繰り返します。

この手順が完了すると、クラスター内のすべてのmongosインスタンスがオフラインになります。

コンフィギュレーコンフィギュレーションサーバーのmongod インスタンスをシャットダウンします。

mongoshコンフィギュレーションサーバー配置内の各 にmongod を接続し、シャットダウンします。

レプリカセット コンフィギュレーションサーバー配置の場合は、最後にプライマリノードをシャットダウンします。

adminデータベースでdb.shutdownServer()メソッドを使用して、 mongodを安全にシャットダウンします。

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

すべてのコンフィギュレーションサーバーがオフラインになるまで繰り返します。

シャードレプリカセットmongod インスタンスをシャットダウンします。

シャード レプリカセットごとに、 mongoshをレプリカセット内の各mongodメンバーに接続し、シャットダウンします。 最後にプライマリノードをシャットダウンします。

adminデータベースでdb.shutdownServer()メソッドを使用して、 mongodを安全にシャットダウンします。

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

すべてのシャード レプリカセット内のすべてのmongodインスタンスがオフラインになるまで、各シャード レプリカセットに対してこの手順を繰り返します。

この手順が完了すると、シャーディングされたクラスター全体がオフラインになります。

コンフィギュレーションサーバーにアクセス制御を強制する

コンフィギュレーションサーバーのレプリカセットで各mongodを起動します。 keyFile設定を含めます。 keyFile設定では、自己管理型内部認証とメンバーシップ認証と自己管理型配置におけるロールベースのアクセス制御 の両方が強制されます。

mongod設定は、構成ファイルまたはコマンドラインで指定できます。

構成ファイル

構成ファイルを使用する場合、コンフィギュレーションサーバーのレプリカセットには、キーファイルのパスにsecurity.keyFileを設定し、 sharding.clusterRoleをconfigsvrに設定し、 replication.replSetNameにコンフィギュレーションサーバーのレプリカセットの名前を設定します。

security:
  keyFile: <path-to-keyfile>
sharding:
  clusterRole: configsvr
replication:
  replSetName: <setname>
storage:
   dbpath: <path>

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

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

mongod --config <path-to-config>

コマンドライン

コマンドライン パラメータを使用する場合は、コンフィギュレーションサーバーのレプリカセットの場合、 -keyFile 、 --configsvr 、 --replSetパラメータを使用してmongodを起動します。

mongod --keyFile <path-to-keyfile> --configsvr --replSet <setname> --dbpath <path>

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

コマンドライン オプションの詳細については、 mongodリファレンス ページを参照してください。

各ノードを再起動するときは、必ず元のレプリカセット名を使用してください。 レプリカセットの名前は変更できません。

シャーディングされたクラスター内の各シャードに対してアクセス制御を強制する。

keyFileパラメータを使用してmongodを実行すると、自己管理型配置で 自己管理型内部認証とメンバーシップ認証とロールベースのアクセス制御 の両方が強制されます。

構成ファイルまたはコマンドラインのいずれかを使用して、レプリカセット内の各mongodを起動します。

構成ファイル

構成ファイルを使用する場合は、 security.keyFileオプションをキーファイルのパスに設定し、 replication.replSetNameオプションをレプリカセットの元の名前に設定します。

security:
  keyFile: <path-to-keyfile>
replication:
  replSetName: <setname>
storage:
   dbPath: <path>

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

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

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

コマンドライン

コマンドラインmongod --keyFileパラメータを使用する場合は、 を起動し、 パラメータと--replSet パラメータを指定します。

mongod --keyfile <path-to-keyfile> --replSet <setname> --dbpath <path>

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

起動パラメータの詳細については、 mongodリファレンス ページを参照してください。

各ノードを再起動するときは、必ず元のレプリカセット名を使用してください。 レプリカセットの名前は変更できません。

クラスター内のすべてのシャードがオンラインになるまで、この手順を繰り返します。

シャード ローカル ユーザー管理者を作成します（任意）。

クラスター内の各シャード レプリカセットについて、 ローカルホスト インターフェースmongosh 経由で を プライマリ ノードに接続します。ローカルホスト mongoshmongodインターフェースを使用するには、ターゲット と同じマシンで を実行する必要があります。

adminデータベースでuserAdminAnyDatabaseロールを持つユーザーを作成します。 このユーザーは、必要に応じてシャード レプリカセットに追加のユーザーを作成できます。 このユーザーを作成すると、自己管理型配置の Localhost 例外も閉じられます。

次の例では、 adminデータベースにシャードローカル ユーザーfredを作成しています。

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

mongosサーバーにアクセス制御を強制します。

keyFileパラメータを使用してmongodを実行すると、自己管理型配置で 自己管理型内部認証とメンバーシップ認証とロールベースのアクセス制御 の両方が強制されます。

構成ファイルまたはコマンドラインのいずれかを使用して、レプリカセット内の各mongosを起動します。

構成ファイル

構成ファイルを使用する場合は、 security.keyFileをキーファイルのパスに設定し、 sharding.configDBをレプリカセット名に設定し、レプリカセットの少なくとも 1 つのノードを<replSetName>/<host:port>形式で設定します。

security:
  keyFile: <path-to-keyfile>
sharding:
  configDB: <configReplSetName>/cfg1.example.net:27019,cfg2.example.net:27019,...

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

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

mongos --config <path-to-config-file>

コマンドライン

コマンドラインmongos --keyFile--configdbパラメータを使用する場合は、 を起動し、 パラメータと パラメータを指定します。

mongos --keyFile <path-to-keyfile> --configdb <configReplSetName>/cfg1.example.net:27019,cfg2.example.net:27019,...

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

この時点で、シャーディングされたクラスター全体はオンラインに戻り、指定されたキーファイルを使用して内部通信できるようになります。 ただし、 mongoshのような外部プログラムでは、クラスターへの読み取りまたは書き込みを行うために、正しくプロビジョニングされたユーザーを使用する必要があります。

mongosローカルホスト インターフェースを介して インスタンスに接続します。

mongosh をローカルホスト インターフェース経由で mongos インスタンスの 1 つに接続します。mongosh は mongos インスタンスと同じ物理マシン上で実行する必要があります。

配置用のユーザーが作成されていないため、ローカルホスト インターフェースのみ使用できます。最初のユーザーが作成された後に、 ローカルホスト インターフェースは閉じます。

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

db.createUser() メソッドを使用してユーザーを追加します。このユーザーには、admin データベース上で userAdminAnyDatabase 以上のロールを付与する必要があります。

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

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

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

ユーザー管理者として認証します。

ユーザー管理者として認証し、追加のユーザーを作成するには、次のようにしdb.auth() 。

db.getSiblingDB("admin").auth("fred", passwordPrompt()) // or cleartext password

パスワードの入力を求められたら、入力します。

または、 -u <username> 、 -p <password> 、 --authenticationDatabase "admin"パラメータを使用して、新しいmongoshセッションを対象レプリカセット ノードに接続します。 に接続するには 、 自己管理型配置で Localhost 例外 をmongos 使用する必要があります。

mongosh -u "fred" -p  --authenticationDatabase "admin"

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

クラスターマネジメントの管理ユーザーの作成

クラスター管理者ユーザーには、シャード ローカル クラスター管理者でclusterAdmin はなく 、シャーディングされたクラスターの ロールが付与されています。

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

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

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

クラスター管理者として認証します。

clusterAdmindb.auth()mongoshシャーディング操作を実行するには、username メソッドを使用してpassword ユーザーとして認証するか、 、 、 パラメーターを使用して新しい セッションを実行してauthenticationDatabase ユーザーとして認証します。

バランサーを起動します。

バランサーを起動します。

sh.startBalancer()

MongoDB 4.2 以降では、 sh.startBalancer()によるシャーディングされたクラスターの自動分割も有効になります。

sh.getBalancerState()を使用して、バランサーが起動したことを確認します。

シャーディングされたクラスター バランサーに関するチュートリアルについては、「 シャーディングされたクラスター バランサーの管理」を参照してください。

追加のユーザーを作成します（任意）。

ユーザーを作成して、クライアントがシャーディングされたクラスターに接続してアクセスできるようにします。 使用可能な組み込みロールについては、「 データベースユーザーのロール 」を参照してください。たとえば、 readやreadWriteなどです。 また、管理ユーザーを追加することもできます。 ユーザーの詳細については、「自己管理型配置のユーザー 」を参照してください。

追加のユーザーを作成するには、 userAdminAnyDatabaseまたはuserAdminロールを持つユーザーとして認証する必要があります。