序章

MongoDB は、 Mongo とも呼ばれ、多くの最新のWebアプリケーションで使用されているオープンソースのドキュメントデータベースです。 リレーショナルデータベースモデルに依存しないため、NoSQLデータベースに分類されます。 代わりに、動的スキーマを持つJSONのようなドキュメントを使用します。 つまり、リレーショナルデータベースとは異なり、MongoDBでは、データベースにデータを追加する前に事前定義されたスキーマは必要ありません。

レプリカセットまたはシャードデータベースアーキテクチャの場合のように、複数の分散MongoDBインスタンスを操作する場合は、それらの間の通信が安全であることを確認することが重要です。 これを行う1つの方法は、キーファイル認証を使用することです。 これには、基本的にクラスター内の各メンバーの共有パスワードとして機能する特別なファイルの作成が含まれます。

このチュートリアルでは、キーファイル認証を使用するように既存のレプリカセットを更新する方法の概要を説明します。 このガイドに含まれる手順により、レプリカセットにダウンタイムが発生しないようにすることもできるため、レプリカセット内のデータは、それにアクセスする必要のあるすべてのクライアントまたはアプリケーションで引き続き利用できます。

前提条件

このチュートリアルを完了するには、次のものが必要です。

  • それぞれがUbuntu20.04を実行している3台のサーバー。 これら3つのサーバーすべてに、管理者の非rootユーザーとUFWで構成されたファイアウォールが必要です。 これを設定するには、Ubuntu20.04の初期サーバー設定ガイドに従ってください。
  • 各UbuntuサーバーにインストールされたMongoDB。 Ubuntu 20.04 にMongoDBをインストールする方法に関するチュートリアルに従い、各サーバーで各手順を完了してください。
  • レプリカセットとして構成された3つのMongoDBインストールすべて。 Ubuntu 20.04 でMongoDBレプリカセットを構成する方法に関するこのチュートリアルに従って、これを設定してください。
  • サーバーごとに生成されたSSHキー。 さらに、各サーバーに他の2つのサーバーの公開鍵が追加されていることを確認する必要があります authorized_keys ファイル。 これは、各マシンがSSHを介して相互に通信できるようにするためです。これにより、ステップ2で各マシンにキーファイルを簡単に配布できるようになります。 これらを設定するには、 Ubuntu20.04でSSHキーを設定する方法に関するガイドに従ってください。

わかりやすくするために、このガイドでは、前提条件のレプリカセットのチュートリアルで確立された規則に従い、3つのサーバーを mongo0 、 mongo1 、およびmongo2と呼びます。 ]。 また、そのガイドのステップ1 を完了し、各サーバーを構成したことも前提としています。 hosts 次のホスト名が指定されたサーバーのIPアドレスに解決されるようにファイルします。

ホスト名 に解決します
mongo0.replset.member mongo0
mongo1.replset.member mongo1
mongo2.replset.member mongo2

このガイドには、これらのサーバーの1つだけでコマンドを実行したり、ファイルを更新したりする必要があるインスタンスがいくつかあります。 このような場合、このガイドではデフォルトで例で mongo0 を使用し、次のようにコマンドまたはファイルの変更を青い背景で表示することでこれを示します。

  1.

複数サーバーで実行する必要のあるコマンドまたはファイルの変更は、次のような標準の灰色の背景になります。

  1.

キーファイル認証について

MongoDBでは、キーファイル認証は、データベースシステムのデフォルトの認証メカニズムである Salted Challenge Response Authentication Mechanism（SCRAM）に依存しています。 SCRAMには、MongoDBがユーザー名、パスワード、認証データベースの組み合わせに対してユーザーから提示されたクレデンシャルを読み取り、検証することが含まれます。これらはすべて、特定のMongoDBインスタンスによって認識されます。 これは、データベースに接続するときにパスワードを提供するユーザーを認証するために使用されるのと同じメカニズムです。

キーファイル認証では、キーファイルはクラスター内の各メンバーの共有パスワードとして機能します。 キーファイルには、6〜1024文字が含まれている必要があります。 キーファイルにはbase64セットの文字のみを含めることができ、MongoDBはキーを読み取るときに空白文字を削除することに注意してください。 Mongoのバージョン4.2以降、キーファイルはYAML形式を使用しており、1つのキーファイルで複数のキーを共有できます。

警告：コミュニティバージョンのMongoDBには、データベースを安全に保つのに役立つ2つの認証方法、キーファイル認証とx.509認証が付属しています。 レプリケーションを使用する本番環境のデプロイメントでは、 MongoDBドキュメントはx.509認証の使用を推奨し、キーファイルを「テストまたは開発環境に最適な」「最低限のセキュリティ形式」として説明しています。

x.509証明書を取得して構成するプロセスには、ケースバイケースで行う必要のあるいくつかの警告と決定が伴います。つまり、この手順はDigitalOceanチュートリアルの範囲を超えています。 実稼働環境でレプリカセットを使用することを計画している場合は、x.509認証に関する公式MongoDBドキュメントを確認することを強くお勧めします。

レプリカセットをテストまたは開発に使用することを計画している場合は、このチュートリアルに従って、クラスターにセキュリティのレイヤーを追加できます。

ステップ1—ユーザー管理者を作成する

MongoDBで認証を有効にすると、レプリカセットのロールベースのアクセス制御も有効になります。 MongoDBのドキュメントによると：

MongoDBは、役割ベースのアクセス制御（RBAC）を使用して、MongoDBシステムへのアクセスを管理します。 ユーザーには、データベースのリソースと操作へのユーザーのアクセスを決定する1つ以上の役割が付与されます。

MongoDBインスタンスでアクセス制御が有効になっている場合、有効なMongoDBユーザーとして認証されていない限り、システム上のどのリソースにもアクセスできないことを意味します。 それでも、特定のリソースにアクセスするには、適切な権限を持つユーザーとして認証する必要があります。

キーファイル認証（およびその結果としてアクセス制御）を有効にする前にMongoDBシステムのユーザーを作成しない場合、レプリカセットからロックアウトされることはありません。 セットへの認証に使用できるMongoDBユーザーを作成し、必要に応じて、Mongoのlocalhost例外を介して他のユーザーを作成できます。 これは、MongoDBがアクセス制御を有効にしているが、ユーザーが不足している構成に対して行う特別な例外です。 この例外では、 localhost のデータベースに接続して、 admin データベース。

ただし、認証を有効にした後でローカルホストの例外に依存してMongoDBユーザーを作成すると、レプリカはユーザーを作成するまで接続を認証できないため、レプリカセットにダウンタイムが発生します。 この手順では、前にユーザーを作成して認証を有効にし、レプリカセットが引き続き使用可能であることを確認する方法の概要を説明します。 このユーザーには、データベース上に他のユーザーを作成するためのアクセス許可があり、将来必要なアクセス許可を持つ他のユーザーを自由に作成できます。 MongoDBでは、このような権限を持つユーザーはユーザー管理者と呼ばれます。

まず、レプリカセットのプライマリメンバーに接続します。 メンバーのどれがプライマリであるかわからない場合は、を実行できます rs.status() それを識別する方法。

次を実行します mongo レプリカセットでMongoDBインスタンスをホストしているUbuntuサーバーのbashプロンプトからのコマンド。 このコマンドの --eval オプションは mongo 実行時に表示されるシェルインターフェイス環境を開かない操作 mongo 単独で、代わりに一重引用符で囲まれたコマンドまたはメソッドを実行します。 --eval 口論：

  1. mongo --eval 'rs.status()'

rs.status() 多くの情報を返しますが、出力の関連部分は "members" : 配列。 MongoDBのコンテキストでは、配列は1対の角かっこ（[ と ]).

の中に "members": 配列には多数のドキュメントがあり、各ドキュメントにはレプリカセットのメンバーの1つに関する情報が含まれています。 これらの各メンバー文書内で、 "stateStr" 分野。 そのメンバー "stateStr" 値は "PRIMARY" レプリカセットのプライマリメンバーです。 次の例は、mongo0がプライマリである状況を示しています。

Output
. . .
    "members" : [
        {
            "_id" : 0,
            "name" : "mongo0.replset.member:27017",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",
. . .
        },
. . .

どのレプリカセットメンバーがプライマリであるかがわかったら、そのインスタンスをホストしているサーバーにSSHで接続します。 デモンストレーションの目的で、このガイドでは、mongo0がプライマリである例を引き続き使用します。

  1. ssh sammy@mongo0_ip_address

サーバーにログインした後、を開いてMongoDBに接続します mongo シェル環境：

  1. mongo

MongoDBでユーザーを作成するときは、認証データベースとして使用される特定のデータベース内にユーザーを作成する必要があります。 ユーザーの名前とその認証データベースの組み合わせは、そのユーザーの一意の識別子として機能します。

特定の管理アクションは、認証データベースが admin データベース—すべてのMongoDBインストールに含まれる特別な特権データベース—新しいユーザーを作成する機能を含みます。 この手順の目的は、レプリカセットに他のユーザーを作成できるユーザー管理者を作成することであるため、に接続します。 admin このユーザーに適切な権限を付与できるようにするためのデータベース：

  1. use admin



Output
switched to db admin

MongoDBには、データベースの管理に使用できるJavaScriptベースのシェルメソッドが多数インストールされています。 これらの1つ、 db.createUser メソッドは、メソッドが実行されるデータベースに新しいユーザーを作成するために使用されます。

を開始します db.createUser 方法：

  1. db.createUser(

注：Mongoは登録しません db.createUser 閉じ括弧を入力するまで、メソッドは完了します。 そうするまで、プロンプトは大なり記号（>）省略記号（...).

この方法では、ユーザーのユーザー名とパスワード、およびユーザーに付与する役割を指定する必要があります。 MongoDBはデータをJSONのようなドキュメントに保存することを思い出してください。 新しいユーザーを作成するときは、適切なユーザーデータを個々のフィールドとして保持するドキュメントを作成するだけです。

JSONのオブジェクトと同様に、MongoDBのドキュメントは中括弧で始まり、中括弧で終わります（{ と }). 冒頭の中括弧を入力して、ユーザードキュメントを開始します。

  1. {

次に、 user: フィールド。希望するユーザー名を値として二重引用符で囲み、その後にコンマを付けます。 次の例では、ユーザー名 UserAdminSammy を指定していますが、任意のユーザー名を入力できます。

  1. user: "UserAdminSammy",

次に、 pwd フィールドと passwordPrompt() その値としてのメソッド。 実行すると db.createUser メソッド、 passwordPrompt() メソッドは、パスワードを入力するためのプロンプトを提供します。 これは、ユーザー名の場合と同じようにパスワードをクリアテキストで入力するという代替手段よりも安全です。

注： passwordPrompt() メソッドは、MongoDBバージョン4.2以降とのみ互換性があります。 古いバージョンのMongoを使用している場合は、ユーザー名を書き出すのと同じように、パスワードをクリアテキストで書き出す必要があります。

  1. pwd: "password",

このフィールドの後には、必ずコンマを付けてください。

  1. pwd: passwordPrompt(),

次に、 roles フィールドの後に、管理ユーザーに持たせたい役割の詳細を示す配列が続きます。 MongoDBでは、 roles は、ユーザーがアクセスできるリソースに対して実行できるアクションを定義します。 カスタムロールは自分で定義できますが、Mongoには、一般的に必要な権限を付与する多数の組み込みロールも付属しています。

ユーザー管理者を作成しているため、少なくとも、組み込みの管理者を付与する必要があります userAdminAnyDatabase 上の役割 admin データベース。 これにより、ユーザー管理者は新しいユーザーとロールを作成および変更できます。 管理ユーザーがこの役割を持っているため admin データベースの場合、これにより、クラスター全体へのスーパーユーザーアクセスも許可されます。

  1. roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]

続いて、ドキュメントの終わりを示すために閉じ中括弧を入力します。

  1. }

次に、閉じ括弧を入力して閉じて実行します db.createUser 方法：

  1. )

一緒に、これがあなたの db.createUser メソッドは次のようになります。

> db.createUser(
... {
... user: "UserAdminSammy",
... pwd: passwordPrompt(),
... roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
... }
... )

各行の構文が正しい場合、メソッドは正しく実行され、パスワードの入力を求められます。

Output
Enter password:

選択した強力なパスワードを入力します。 次に、ユーザーが追加されたという確認を受け取ります。

Output
Successfully added user: {
    "user" : "UserAdminSammy",
    "roles" : [
        {
            "role" : "userAdminAnyDatabase",
            "db" : "admin"
        },
        "readWriteAnyDatabase"
    ]
}

これで、システム上の他のユーザーとロールを管理するために使用できるMongoDBユーザープロファイルを追加しました。 このステップの残りの部分で概説するように、別のユーザーを作成することでこれをテストできます。

作成したユーザー管理者として認証することから始めます。

  1. db.auth( "UserAdminSammy", passwordPrompt() )

db.auth() 戻ります 1 認証が成功した場合：

Output
1

注：将来、クラスターに接続するときにユーザー管理者として認証する場合は、次のようなコマンドを使用して、サーバープロンプトから直接認証できます。

  1. mongo -u "UserAdminSammy" -p --authenticationDatabase "admin"

このコマンドでは、 -u オプションは、次の引数が認証するユーザー名であることをシェルに通知します。 The -p フラグは、パスワードの入力を求めるプロンプトを表示し、 --authenticationDatabase オプションは、ユーザーの認証データベースの名前の前にあります。 間違ったパスワードを入力した場合、またはユーザー名と認証データベースが一致しない場合、認証できなくなり、接続を再試行する必要があります。

また、レプリカセットにユーザー管理者として新しいユーザーを作成するには、セットのプライマリメンバーに接続する必要があることに注意してください。

別のユーザーを追加する手順は、ユーザー管理者の場合と同じです。 次の例では、 clusterAdmin ロール。これは、レプリケーションとシャーディングに関連する多くの操作を実行できることを意味します。 MongoDBのコンテキスト内では、これらの特権を持つユーザーはクラスター管理者と呼ばれます。

このような特定の機能を実行するための専用ユーザーを用意することは、システム上にいる特権ユーザーの数を制限するため、優れたセキュリティ慣行です。 このチュートリアルの後半でキーファイル認証を有効にした後、で許可されている操作のいずれかを実行したいクライアント clusterAdmin 役割—のいずれかなど rs. のようなメソッド rs.status() また rs.conf() —最初にクラスター管理者として認証する必要があります。

そうは言っても、このユーザーに好きな役割を提供し、同様に別の名前と認証データベースをユーザーに提供することができます。 ただし、新しいユーザーをクラスター管理者として機能させる場合は、ユーザーにを付与する必要があります。 clusterAdmin 内の役割 admin データベース。

次のメソッドは、クラスター管理者として機能するユーザーを作成することに加えて、ユーザーに ClusterAdminSammy という名前を付け、 passwordPrompt() パスワードの入力を求めるプロンプトを表示する方法：

  1. db.createUser(

  2. {

  3. user: "ClusterAdminSammy",

  4. pwd: passwordPrompt(),

  5. roles: [ { role: "clusterAdmin", db: "admin" } ]

  6. }

  7. )

繰り返しになりますが、バージョン 4.2 より前のバージョンのMongoDBを使用している場合は、パスワードを使用する代わりに、クリアテキストでパスワードを書き出す必要があります。 passwordPrompt() 方法。

各行の構文が正しい場合、メソッドは正しく実行され、パスワードの入力を求められます。

Output
Enter password:

選択した強力なパスワードを入力します。 次に、ユーザーが追加されたという確認を受け取ります。

Output
Successfully added user: {
    "user" : "ClusterAdminSammy",
    "roles" : [
        {
            "role" : "clusterAdmin",
            "db" : "admin"
        }
    ]
}

この出力は、ユーザー管理者が新しいユーザーを作成してそれらに役割を付与できることを確認します。 これで、MongoDBシェルを閉じることができます。

  1. exit

または、を押してシェルを閉じることもできます CTRL + C.

この時点で、MongoDBクラスターに接続されているクライアントまたはアプリケーションがある場合は、データベースへの認証に使用できる適切な役割を持つ1人以上の専用ユーザーを作成するのがよいでしょう。 それ以外の場合は、キーファイルを生成する方法を学び、レプリカセットのメンバーに配布してから、レプリカセットのメンバーにキーファイルでの認証を要求するように各メンバーを構成します。

ステップ2—認証キーファイルの作成と配布

キーファイルを作成する前に、整理しておくために、キーファイルを保存するディレクトリを各サーバーに作成すると便利な場合があります。 次のコマンドを実行すると、次の名前のディレクトリが作成されます。 mongo-security 管理用Ubuntuユーザーのホームディレクトリにある3台のサーバーのそれぞれ：

  1. mkdir ~/mongo-security

次に、サーバーの1つでキーファイルを生成します。 これはどのサーバーでも実行できますが、説明のために、このガイドではmongo0にキーファイルを生成します。

に移動します mongo-security 作成したディレクトリ：

  1. cd ~/mongo-security/

そのディレクトリ内に、次のキーファイルを作成します openssl 指図：

  1. openssl rand -base64 768 > keyfile.txt

このコマンドの引数に注意してください。

  • rand：OpenSSLに疑似ランダムバイトのデータを生成するように指示します
  • -base64：コマンドがbase64エンコーディングを使用して、疑似ランダムデータを印刷可能なテキストとして表す必要があることを指定します。 前述のように、MongoDBキーファイルにはbase64セットの文字しか含めることができないため、これは重要です。
  • 768：コマンドが生成する必要のあるバイト数。 base64エンコーディングでは、3バイトのデータが4文字で表されます。 MongoDBキーファイルには最大1024文字を使用できるため、有効なキーファイルに対して生成できる最大バイト数は768です。

このコマンドに続いて 768 引数は大なり記号です（>). これにより、コマンドの出力が次の名前の新しいファイルにリダイレクトされます。 keyfile.txt これがキーファイルとして機能します。 キーファイルに他の名前を付けてください keyfile.txt 必要に応じて、後のコマンドに表示されるたびにファイル名を変更してください。

次に、所有者のみが読み取りアクセス権を持つように、キーファイルの権限を変更します。

  1. chmod 400 keyfile.txt

これに続いて、レプリカセット内のMongoDBインスタンスをホストしている他の2つのサーバーにキーファイルを配布します。 SSHキーの設定方法の前提条件ガイドに従っていると仮定すると、 scp 指図：

  1. scp keyfile.txt sammy@mongo1.replset.member:/home/sammy/mongo-security

  2. scp keyfile.txt sammy@mongo2.replset.member:/home/sammy/mongo-security

これらの各コマンドは、キーファイルを直接にコピーすることに注意してください。 ~/mongo-security/ mongo1およびmongo2で以前に作成したディレクトリ。 必ず変更してください sammy 各サーバーで作成した管理用Ubuntuユーザープロファイルの名前に変更します。

次に、ファイルの所有者をmongodbユーザープロファイルに変更します。 これは、MongoDBをインストールしたときに作成された特別なユーザーであり、 mongod サービス。 このユーザーは、MongoDBがキーファイルを認証に使用するために、キーファイルにアクセスできる必要があります。

各サーバーで次のコマンドを実行して、キーファイルの所有者をmongodbユーザーアカウントに変更します。

  1. sudo chown mongodb:mongodb ~/mongo-security/keyfile.txt

各サーバーでキーファイルの所有者を変更したら、各MongoDBインスタンスを再構成して、キーファイル認証を実施する準備が整います。

ステップ3—キーファイル認証を有効にする

キーファイルを生成し、レプリカセット内の各サーバーに配布したので、各サーバーのMongoDB構成ファイルを更新して、キーファイル認証を適用できます。

認証を要求するようにレプリカセットのメンバーを構成する際のダウンタイムを回避するために、このステップでは、最初にセットのセカンダリメンバーを再構成する必要があります。 次に、プライマリメンバーにステップダウンしてセカンダリメンバーになるように指示します。 これにより、セカンダリメンバーは、新しいプライマリを選択するための選出を行い、クラスターにアクセスする必要のあるクライアントまたはアプリケーションがクラスターを利用できるようにします。 次に、以前のプライマリノードを再構成して認証を有効にします。

レプリカセットのセカンダリメンバーをホストしている各サーバーで、お好みのテキストエディターを使用してMongoDBの構成ファイルを開きます。

  1. sudo nano /etc/mongod.conf

ファイル内で、 security セクション。 デフォルトでは次のようになります。

/etc/mongod.conf
. . .
#security:
. . .

ポンド記号を削除して、この行のコメントを解除します（#). 次に、次の行に、 keyFile: ディレクティブの後に、前の手順で作成したキーファイルへのフルパスが続きます。

/etc/mongod.conf
. . .
security:
  keyFile: /home/sammy/mongo-security/keyfile.txt
. . .

この新しい行の先頭には2つのスペースがあることに注意してください。 これらは、構成ファイルを正しく読み取るために必要です。 独自の構成ファイルにこの行を入力するときは、指定するパスが各サーバー上のキーファイルの実際のパスを反映していることを確認してください。

下 keyFile ディレクティブ、追加 transitionToAuth 値が true. に設定すると true、この構成オプションにより、MongoDBインスタンスは認証された接続と認証されていない接続の両方を受け入れることができます。 これは、レプリカセットを再構成して認証を実施する場合に役立ちます。これにより、セットの各メンバーを再起動してもデータを引き続き使用できるようになります。

/etc/mongod.conf
. . .
security:
  keyFile: /home/sammy/mongo-security/keyfile.txt
  transitionToAuth: true
. . .

繰り返しますが、前に2つの空白スペースが含まれていることを確認してください transitionToAuth 指令。

これらの変更を行った後、ファイルを保存して閉じます。 使用した場合 nano 編集するには、を押して編集できます CTRL + X, Y、 その後 ENTER.

次に、再起動します mongod 両方のセカンダリインスタンスのサーバーでサービスを実行して、これらの変更をすぐに有効にします。

  1. sudo systemctl restart mongod

これで、レプリカセットのセカンダリメンバーのキーファイル認証を構成しました。 この時点で、認証されたユーザーと認証されていないユーザーの両方が、これらのメンバーに制限なくアクセスできます。

次に、プライマリメンバーでこの手順を繰り返します。 ただし、そうする前に、メンバーをステップダウンして、プライマリではなくなるようにする必要があります。 これを行うには、プライマリメンバーをホストしているサーバーでMongoDBシェルを開きます。 説明のために、このガイドでは、これがmongo0であると再び想定しています。

  1. mongo

プロンプトから、を実行します rs.stepDown() 方法。 これにより、プライマリーがセカンダリーメンバーになるように指示され、現在のセカンダリーメンバーが新しいプライマリーとして機能するかどうかを決定するための選挙を実施します。

  1. rs.stepDown()

メソッドが返す場合 "ok" : 1 出力では、プライマリメンバーが正常にステップダウンしてセカンダリになることを意味します。

Output
{
    "ok" : 1,
    "$clusterTime" : {
        "clusterTime" : Timestamp(1614795467, 1),
        "signature" : {
            "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
            "keyId" : NumberLong(0)
        }
    },
    "operationTime" : Timestamp(1614795467, 1)
}

プライマリをステップダウンした後、Mongoシェルを閉じることができます。

  1. exit

次に、このサーバーでMongoDB構成ファイルを開きます。

  1. sudo nano /etc/mongod.conf

セキュリティセクションを見つけて、コメントを外します security ポンド記号を削除してヘッダーを作成します。 次に、同じものを追加します keyFile と transitionToAuth 他のMongoDBインスタンスに追加したディレクティブ。 これらの変更を行った後、 security セクションは次のようになります。

/etc/mongod.conf
. . .
security:
  keyFile: /home/sammy/mongo-security/keyfile.txt
  transitionToAuth: true
. . .

繰り返しますが、後のファイルパスを確認してください keyFile ディレクティブは、このサーバー上のキーファイルの実際の場所を反映します。

終了したら、ファイルを保存して閉じます。 次に、再起動します mongod 処理する：

  1. sudo systemctl restart mongod

その後、すべてのMongoDBインスタンスは、認証された接続と認証されていない接続の両方を受け入れることができます。 このガイドの最後のステップでは、特権アクションを実行する前にユーザーに認証を要求するようにインスタンスを構成します。

ステップ4—なしで各メンバーを再起動する transitionToAuth 認証を実施する

この時点で、各MongoDBインスタンスは transitionToAuth に設定 true. つまり、各サーバーが作成したキーファイルを使用して内部で接続を認証できるようにした場合でも、認証されていない接続を受け入れることができます。

これを変更し、各メンバーに認証を強制するように要求するには、 mongod.conf 各サーバー上のファイル：

  1. sudo nano /etc/mongod.conf

を見つける security セクションを無効にし、 transitionToAuth 指令。 これを行うには、行の前にポンド記号を付けてコメントアウトします。

/etc/mongod.conf
. . .
security:
  keyFile: /home/sammy/mongo-security/keyfile.txt
  #transitionToAuth: true
. . .

を無効にした後 transitionToAuth 各インスタンスの構成ファイルのディレクティブで、各ファイルを保存して閉じます。

次に、再起動します mongod 各サーバーのサービス：

  1. sudo systemctl restart mongod

その後、レプリカセット内の各MongoDBインスタンスは、特権アクションを実行するために認証する必要があります。

これをテストするには、適切な権限を持つ認証済みユーザーによって呼び出されたときに機能するMongoDBメソッドを実行してみてください。 Ubuntuサーバーのプロンプトから次のコマンドを実行してみてください。

  1. mongo --eval 'rs.status()'

手順1でこのメソッドを正常に実行した場合でも、 rs.status() メソッドは、許可されたユーザーのみが実行できるようになりました clusterAdmin また clusterManager キーファイル認証を有効にしてからのロール。 このコマンドをプライマリメンバーまたはセカンダリメンバーの1つをホストしているサーバーで実行するかどうかに関係なく、認証されていないため、このコマンドは機能しません。

Output
. . .
MongoDB server version: 4.4.4
{
    "operationTime" : Timestamp(1616184183, 1),
    "ok" : 0,
    "errmsg" : "command replSetGetStatus requires authentication",
    "code" : 13,
    "codeName" : "Unauthorized",
    "$clusterTime" : {
        "clusterTime" : Timestamp(1616184183, 1),
        "signature" : {
            "hash" : BinData(0,"huJUmB/lrrxpx9YfnONM4mayJwo="),
            "keyId" : NumberLong("6941116945081040899")
        }
    }
}

アクセス制御を有効にした後、すべてのクラスター管理方法（ rs. のような方法 rs.status()）は、適切なクラスター管理ロールが付与されている認証済みユーザーによって呼び出された場合にのみ機能します。 手順1で概説したように、クラスター管理者を作成し、そのユーザーとして認証した場合、この方法は期待どおりに機能します。

  1. mongo -u "ClusterAdminSammy" -p --authenticationDatabase "admin" --eval 'rs.status()'

プロンプトが表示されたらユーザーのパスワードを入力すると、 rs.status() メソッドの出力：

Output
. . .
MongoDB server version: 4.4.4
{
    "set" : "shard2",
    "date" : ISODate("2021-03-19T20:21:45.528Z"),
    "myState" : 2,
    "term" : NumberLong(4),
    "syncSourceHost" : "mongo1.replset.member:27017",
    "syncSourceId" : 2,
    "heartbeatIntervalMillis" : NumberLong(2000),
    "majorityVoteCount" : 2,
. . .

これにより、レプリカセットが認証を実施していること、および正常に認証できることが確認されます。

結論

このチュートリアルを完了することで、OpenSSLを使用してキーファイルを作成し、MongoDBレプリカセットを構成して、メンバーが内部認証に使用するように要求しました。 また、将来的にユーザーと役割を管理できるようにするユーザー管理者を作成しました。 このすべてを通して、レプリカセットはダウンタイムを経ることはなく、データはクライアントとアプリケーションで引き続き利用できます。

MongoDBの詳細については、MongoDBコンテンツのライブラリ全体を確認することをお勧めします。