x のローリング アップデート。自己管理型クラスター上の新しい DN を含む509証明書
レプリカセットまたはシャーディングされたクラスターのメンバーは、 x を使用できます。 同じ配置のノードとして相互を識別する 509ためのメンバーシップ認証用の 証明書 。
相互を同じ配置のノードとして識別するには、組織属性( O
)、組織単位属性( OU
)、およびドメインコンポーネント( DC
)を含む証明書は一致する必要があります。
状況によっては、組織がその名前を変更した場合など、メンバー証明書を新しい識別名( DN
)を持つ新しい証明書に更新する必要がある場合があります。 tlsX509ClusterAuthDNOverride
パラメータを使用して、一致するように使用する代替のDN
を設定できます。 このパラメータを使用すると、異なるDN
を使用して新しい証明書に、証明書のローリング アップデートを実行できます。
注意
ローリング アップデートでは、メンバー証明書が一度に 1 つずつ更新されるため、配置のダウンタイムは発生しません。 To perform a rolling update to rotate certificates on a cluster that uses net.tls.clusterAuthX509
settings or on a cluster that will use these settings after the update, see Rotate X.509 Certificates on Self-Managed Clusters.
次のチュートリアルでは、レプリカセットの証明書をダウンタイムなしで更新するプロセスについて説明します。
各ノードの証明書( clusterFile
とcertificateKeyFile
)が、 "OU=10gen Server,O=10gen"
を含むDN
値を持つレプリカセットを検討します(追加の属性は比較の一部として考慮されません)。
net.tls.mode: requireTLS net.tls.certificateKeyFile: "./mycerts/10gen-server1.pem" net.tls.CAFile: "./mycerts/ca.pem" security.clusterAuthMode: x509 net.tls.clusterFile: "./mycerts/10gen-cluster1.pem" net.tls.clusterCAFile: "./mycerts/ca.pem"
次の手順では、メンバーの証明書( clusterFile
とcertificateKeyFile
を、 DN
値が"OU=MongoDB Server,O=MongoDB"
を持つ新しい証明書に更新します。
注意
次の手順では、新しい x.509 証明書がメンバーシップ証明書の他のすべての要件を満たしていることを前提としています。 詳細については、「ノード証明書の要件」を参照してください。
手順
0。任意。 実行中のノードでの上書きパラメータの設定
この手順では、配置のすべてのノードを再起動する必要があります。 すべてのメンバーを再起動するまで設定は考慮されないため、手順が完了するまで インスタンスはメッセージをログに記録する可能性があります。
このようなメッセージを回避するには、実行中のメンバーに の上書きパラメーターを設定します。
mongosh
を配置の各ノードに直接接続し、 tlsX509ClusterAuthDNOverride
パラメータを新しい証明書DN
に設定します。
db.adminCommand( { setParameter: 1, tlsX509ClusterAuthDNOverride: "OU=MongoDB Server,O=MongoDB" } )
1. すべてのノードの構成を変更する
各ノードの構成を変更します。
net.tls.certificateKeyFile
を新しい証明書に更新します。net.tls.clusterFile
を新しい証明書に更新します。tlsX509ClusterAuthDNOverride
パラメータを新しい証明書DN
に設定します。
以下に例を挙げます。
net.tls.mode: requireTLS net.tls.certificateKeyFile: "./mycerts/mongodb-server1.pem" net.tls.CAFile: "./mycerts/ca.pem" security.clusterAuthMode: x509 net.tls.clusterFile: "./mycerts/mongodb-cluster1.pem" net.tls.clusterCAFile: "./mycerts/ca.pem" setParameter: tlsX509ClusterAuthDNOverride: "OU=MongoDB Server,O=MongoDB"
各ノードを再起動するまで、設定は考慮されません(次の手順を参照)。
2. 各ノードを再起動する
すべてのメンバーの構成を変更したら、各セカンダリを再起動し、次にプライマリを再起動します。
各 セカンダリ メンバー について、 mongosh
をメンバーに接続し、
ノードをシャットダウンするには、
db.shutdownServer()
メソッドを使用します。use admin db.shutdownServer() ノードを再起動します。
次のセカンダリを再起動する前に、ノードが
SECONDARY
状態に達していることを確認します。
プライマリの場合は、 mongosh
をノードに接続し、
rs.stepDown()
を使用してメンバーを降格します。rs.stepDown() ノードをシャットダウンするには、
db.shutdownServer()
メソッドを使用します。use admin db.shutdownServer() ノードを再起動します。
3。 設定を削除tlsX509ClusterAuthDNOverride
すべてのメンバーが新しい証明書で再起動されたら、構成からtlsX509ClusterAuthDNOverride
パラメータを削除できます。
以下に例を挙げます。
net.tls.mode: requireTLS net.tls.certificateKeyFile: "./mycerts/mongodb-server1.pem" net.tls.CAFile: "./mycerts/ca.pem" security.clusterAuthMode: x509 net.tls.clusterFile: "./mycerts/mongodb-cluster1.pem" net.tls.clusterCAFile: "./mycerts/ca.pem"
各ノードを再起動するまで、設定は考慮されません。