インターネット企業の開発過程では、当初は考慮されていなかったシナリオに遭遇することがよくあります。オンラインになった後、またはサービスが一定期間実行された後、いくつかのことがうまく行われておらず、最適化して再構築する必要があることがわかります。
これらのシナリオには、一部のサービスのパスワード構成が単純すぎる（または構成されていない）、機密データの感度が低下（転送）されていない、コードに十分なテストケースがない、毎日のサービスが脆弱性を解消し、アップグレードと修復が必要であるなどが含まれます。最適化プロセスでは、サービスへの影響を最小限に抑えるために、ダウンタイムをゼロにし、移行をスムーズにすることを望んでいます。
今日は、ここでシナリオの1つについて話します。Mongoは、アクセス制御を追加するためにゼロリスタートを実装します。
前に書く
この記事はUbuntuで実施されています：16.04、mongo3.4バージョン
要件：レプリカセットは、既存のプライマリメンバー（ダウンタイムなど）の後に新しいプライマリを選択できます。
Mongoクラスターは、「ID認証」を追加するためにゼロダウンタイムを実現します。必要なバージョンはmongo 3.4以降です。理由は、mongoが3.4で--transitionToAuth パラメーターを追加したためです。この記事では、主にこのパラメーターを使用して、アップグレード認証のゼロダウンタイムを実現します。
ここでは、例として3つのノードレプリカセットを取り上げます。
ユーザー管理者を作成する
作成userAdminAnyDatabase 権限のためにプライマリにリンクされた ユーザー
admin = db.getSiblingDB（ "admin"）
admin.createUser（
{
user： "yourname1"、pwd： "changeme1"、
roles：[{role： "userAdminAnyDatabase"、db： "admin"}]
}
）
このプロセスを完了した後、レプリカセット内のユーザーを管理するクライアントは、そのユーザー、または同様の権限を持つユーザーとして認証する必要があります。
クラスター管理者を作成する
プライマリノードに接続し、clusterAdminロールを持つユーザーを作成します。clusterAdminロールは、レプリカセットの構成などのレプリケーション操作へのアクセスを許可します。
db.getSiblingDB（ "admin"）。createUser（
{"user"： "yourname2"、 "pwd"： "changeme2"、
roles：[{"role"： "clusterAdmin"、 "db"： "admin"}]
}
）
クライアントアプリケーションリンクを作成したユーザー
クライアントプログラムがレプリカレベルと対話できるようにするユーザーを作成します。この手順を完了するには、クライアントは対応するアカウントパスワードを介してコピーレベルをリンクする必要があります。
ここではreadWrite、データを操作するためのアクセス許可の使用に注意する必要があります。システムのセキュリティを強化するために、特定のデータベース（yourdbなど）に対してより複雑なパスワードを設定することをお勧めします。ここでは、世代管理に1passwordを使用することをお勧めします。
db.getSiblingDB（ "yourdb"）。createUser（
{"user"： "yourname_client"、 "pwd"： "changeme2"、
roles：[{"role"： "readWrite"、 "db"： "yourdb"}]
}
）
クライアント認証yourdbはそれを読み書きできます。
クライアントアプリケーションコードを更新する
このステップでは、コピーレベルのリンクは認証を必要としませんが、クライアントアプリケーションは、認証されたアカウントとパスワードを介してコピーレベルにリンクできます。
ここでは、コピーレベルのrepliaセットがyourRepl テスト用であると想定しています。
mongo -u yourname_client -password changeme2 -authenticationDatabase yourdb —host yourRepl / mongo1.example.net：27017、mongo2.example.net：27017、mongo3.example.net：27017
正常にリンクしてから、クライアントコードを更新し、オンラインでリリースできます。
キーファイルを作成する
openssl rand -base64 756>
<path-to-keyfile>
chmod 400<path-to-keyfile>
ここでは、任意の方法で作成でき、opensslによってパスワードの複雑さが保証されます。
上記のキーmongodbファイルは、ユーザーがアクセスできる必要があることが保証されています（mongodを起動します）
キーファイル認証方式により、レプリカレベルの各mongodインスタンスは、キーファイルの内容をパスワードとして使用して、他のメンバーを認証します。レプリカレベルに参加できるのは、正しいキーファイルを持つ正しいmongoインスタンスのみです。
次に、キーファイルを各コピーレベルにコピーします
transitionToAuthを追加し、インスタンスを再起動します
注：再起動する前に、構成ファイルに次の構成があることを確認してください
security： keyFile：<path-to-keyfile> transitionToAuth：true＃この構成は非常に重要なレプリケーションです： replSetName：<replicaSetName>
最初にセカンダリまたはアービターを再起動します
sudo service mongod restart
在重启针对primary节点需要
rs.stepDown()
sudo service mongod restart
一个原则，保持primary在线
去掉transitionToAuth，重启实例
注意：在重启之前保证配置文件中有以下配置
security: keyFile: <path-to-keyfile> replication: replSetName: <replicaSetName>
先重启secondary 或arbiter
sudo service mongod restart
重启primary节点需要
rs.stepDown()
sudo service mongod restart
至此所有的集群认证已经添加完毕，所有客户端也需要进行认证才能进行链接。
我们这种「边开飞机，边换引擎」方式到此就已经完成了。