仮想マシンから Kubernetes へ TLS が有効なレプリカセットを移行する際に、1 つのレプリカセットは 1 つのトラスト ドメインです。Kubernetes ノードの証明書を、仮想マシンの証明書に署名した同じ証明書発行者 (CA) から発行してください。これが唯一の移行固有の TLS 要件です。Kubernetes 演算子用の一般的な TLS ドキュメントには、TLS の構成に関するその他のすべてが記述されています。CA の不一致は、設計上ドライランを失敗させます。ドライ実行するでその失敗がどのように検出されるかを学ぶには、ドライ実行するを使用した移行準備状況の検証を参照してください。
重要
このページのフィールドは移行専用です。フィールドの説明に別段の指示がない限り、グリーンフィールドの Kubernetes 演算子配置でそれらを設定しないでください。
このタスクについて
証明書の発行方法、SecretsとConfigMapsの構成方法、およびMongoDBカスタムリソースでの一般的なTLS設定の構成方法を学ぶには、以下を参照してください。
セキュリティ設定で、
spec.security.tlsと関連フィールドの全体リストを参照してください。cert-マネージャー 統合の設定を行い、
cert-managerを使用して証明書を発行します。X.509 クライアント証明書の生成で、証明書を手動で発行します。
移行に関するドキュメントに従う場合、Kubernetesのノード証明書は、仮想マシンの証明書に署名したのと同じCAから発行してください。新しいCAから発行しないでください。<resourceName>-caという名前のCA ConfigMapには、その同じCAから生成されたca-pemキーが含まれている必要があります。
始める前に
以下のものが必要です。
バーチャル マシン配置の既存の CA 証明書およびキーマテリアル。
cert-managerまたは、同じ CA から Kubernetes ノード証明書を発行するための同等のツール。生成された
MongoDBカスタム リソースから レプリカセットを Kubernetes に移行する
手順
ソース CA から証明書と CA リソースを作成します。
「cert-マネージャー 統合の設定」または「X.509 クライアント証明書の生成」の手順に従って、<certsSecretPrefix>-<resourceName>-cert という名前の kubernetes.io/tls Secret を作成することで、バーチャル マシン証明書に署名した CA と同じ CA から証明書を発行します。
CA ConfigMap を作成し、<resourceName>-ca という名前を付け、その同じ CA から入力された ca-pem キーを使用します。
X.509 エージェント認証を使用する場合は、<certsSecretPrefix>-<resourceName>-agent-certs Secret も作成し、spec.security.authentication.agents.clientCertificateSecretRef を設定して参照させます。この要件はエージェント認証にのみ適用されます。内部クラスター認証（spec.security.authentication.internalCluster）には適用されません。
パス互換性フィールドをソース配置と一致するように設定します。
これらのフィールドは、Kubernetes 演算子 のファイル パスの表示を、仮想マシンの配置が既に証明書とキーファイルを配置する方法と一致させるためにのみ存在します。ソース配置に適用されるもののみを設定します。
spec.security.tls.caFilePathPod 内に CA が投影される絶対パス。デフォルトは/mongodb-automation/tls/ca/ca-pemです。パスには少なくとも 2 つのパスセグメントが含まれている必要があります。このフィールドは、アプリケーションデータベースではサポートされていません。podTemplateがこのパスに別のボリュームをマウントしている場合、そのマウントが投影された CA をシャドウし、MongoDB Ops Manager エージェントはそれを読み取ることができません。spec.security.authentication.agents.autoPEMKeyFilePath：データベースPod内のエージェントの結合PEMファイルの絶対パス。このフィールドはエージェントの認証のみを構成します。このフィールドを設定すると、MongoDB Ops Managertls.autoPEMKeyFilePath値が設定され、clientCertificateSecretRefによって参照されるSecretがそのパスにマウントされます。デフォルトはハッシュされたエージェント証明書のマウントパスであり、これを設定するにはspec.security.authentication.agents.clientCertificateSecretRefが既に設定されている必要があります。このフィールドは、仮想マシンの配置でデフォルト以外のエージェントPEMパスを使用する場合にのみ設定してください。spec.downloadBaseOps Manager エージェントバイナリがダウンロードされるディレクトリ。デフォルトの値は/var/lib/mongodb-mms-automationです。Kubernetes 演算子は、この値からキーファイルのパスを<downloadBase>/keyfileとして導出します。
ソース配置で TLS を使用していない場合は、ソース配置で TLS を無効にします。
仮想マシンの配置でTLSが構成されていない場合は、移行する前に、既存の仮想マシンの配置でOps ManagerまたはCloud Managerのnet.tls.modeをdisabledに設定します。MongoDBカスタムリソースでこのフィールドを設定しないでください。
ソース配置の TLS モードを未設定のままにしておくと、Kubernetes 演算子は、ソース オートメーション構成と一致しない配置変更を試みます。これは、TLS のデフォルトビューが、TLS をまったく構成していない配置と異なるためです。ソース配置でフィールドを disabled に設定すると、Kubernetes 演算子 のビューがバーチャル マシン配置と一致するようになり、偽の変更を回避できます。
ドライランを実行して、CAが一致することを確認します。
dry-runアノテーションが付いたままリソースを適用し、NetworkConnectivityVerified条件を確認します。結果の読み方や失敗時の対処法を学ぶには、「ドライランによる移行準備状況の検証」を参照してください。
シャーディングされたクラスターの場合
クラスターには、コンフィギュレーションサーバー用に<resourceName>-config-*、各シャード用に<resourceName>-<shardIndex>-*、mongosルーター用に<resourceName>-mongos-*というパスワードなしに従って、コンポーネントごとに1つの証明書が必要です。
注意
再調和する前に、生成されたリソースと照らし合わせて、コンポーネントごとの Secret 名が正確であることを確認してください。シャーディングされたクラスターの移行がレプリカセットの移行とどのように異なるかについては、シャーディングされたクラスターを Kubernetes に移行する を参照してください。