この文書は自動機械翻訳技術を使用して翻訳されています。 正確な翻訳を提供するように努めておりますが、翻訳された内容の完全性、正確性、信頼性については一切保証いたしません。 相違がある場合は、元の英語版 英語 が優先され、正式なテキストとなります。

SUSE Rancher Prime 証明書を更新しています

プライベートCA証明書の更新

Rancher Kubernetesクラスターにインストールされたで使用されるSSL証明書とプライベートCAをローテーションするか、プライベートCAによって署名されたSSL証明書に移行するには、次の手順に従ってください。

手順の概要は以下の通りです：

  1. 新しい証明書とプライベートキーを使用して、tls-rancher-ingress Kubernetesシークレットオブジェクトを作成または更新します。

  2. プライベートCAを使用している場合に限り、ルートCA証明書を含む`tls-ca` Kubernetesシークレットオブジェクトを作成または更新します。

  3. Helm CLIを使用してRancherインストールを更新します。

  4. Rancherエージェントを再構成して新しいCA証明書を信頼させます。

  5. Fleet agentをRancherに接続するために、Fleetクラスターの強制更新を選択します。

これらの指示の詳細は以下にあります。

1.証明書シークレットオブジェクトを作成/更新する

まず、サーバー証明書の後に任意の中間証明書を連結して、`tls.crt`という名前のファイルに保存し、対応する証明書キーを`tls.key`という名前のファイルに提供します。

次のコマンドを使用して、Rancher（ローカル）管理クラスターに`tls-rancher-ingress`シークレットオブジェクトを作成します：

kubectl -n cattle-system create secret tls tls-rancher-ingress \
  --cert=tls.crt \
  --key=tls.key

または、既存の`tls-rancher-ingress`シークレットを更新するには：

kubectl -n cattle-system create secret tls tls-rancher-ingress \
  --cert=tls.crt \
  --key=tls.key \
  --dry-run --save-config -o yaml | kubectl apply -f -

2.CA証明書シークレットオブジェクトを作成/更新する

新しい証明書がプライベートCAによって署名されている場合、対応するルートCA証明書を`cacerts.pem`という名前のファイルにコピーし、`cattle-system`名前空間に`tls-ca`シークレットを作成または更新する必要があります。証明書が中間CAによって署名されている場合、`cacerts.pem`には中間CA証明書とルートCA証明書の両方が含まれている必要があります（この順序で）。

初期の`tls-ca`シークレットを作成するには：

kubectl -n cattle-system create secret generic tls-ca \
  --from-file=cacerts.pem

既存の`tls-ca`シークレットを更新するには：

kubectl -n cattle-system create secret generic tls-ca \
  --from-file=cacerts.pem \
  --dry-run --save-config -o yaml | kubectl apply -f -

3.Rancherデプロイメントを再構成する

証明書のソースが同じままである場合（例えば、secret）、ステップ3aの手順に従ってください。

ただし、証明書のソースが変更される場合（例えば、`letsEncrypt`から`secret`へ）、3bの手順に従ってください。

3a.Rancherポッドを再デプロイします。

このステップは、証明書のソースが同じままであるが、CA証明書が更新される場合に必要です。

このシナリオでは、Rancherポッドの再デプロイが必要です。これは、`tls-ca`シークレットがRancherポッドによって起動時に読み取られるためです。

以下のコマンドを使用してRancherポッドを再デプロイできます：

kubectl rollout restart deploy/rancher -n cattle-system

変更が完了したら、`\https://<rancher_server_url>/v3/settings/cacerts`に移動して、値が以前に`tls-ca`シークレットに書かれたCA証明書と一致することを確認してください。CA `cacerts`の値は、すべての再デプロイされたRancherポッドが起動するまで更新されない場合があります。

3b.RancherのHelm値を更新します。

このステップは、証明書のソースが変更される場合に必要です。Rancherが以前にデフォルトの自己署名証明書（ingress.tls.source=rancher）またはLet’s Encrypt（ingress.tls.source=letsEncrypt）を使用するように構成されていた場合、現在はプライベートCAによって署名された証明書（ingress.tls.source=secret）を使用しています。

以下の手順は、RancherチャートのHelm値を更新し、RancherポッドとIngressがステップ1および2で作成された新しいプライベートCA証明書を使用するように再構成されることを目的としています。

  1. 初回インストール時に使用した値を調整し、現在の値を次のように保存します：

    helm get values rancher -n cattle-system -o yaml > values.yaml

  2. 現在デプロイされているRancherチャートのバージョン文字列を取得して、以下で使用します：

    helm ls -n cattle-system

  3. `values.yaml`ファイル内の現在のHelm値を次のように更新します：

    ingress:
  tls:
    source: secret
privateCA: true
    重要:
    証明書がプライベートCAによって署名されているため、{xref-helm-chart-options}#_common_options[`privateCA: true`]が`values.yaml`ファイルに設定されていることを確認することが重要です。

  4. `values.yaml`ファイルと現在のチャートバージョンを使用してHelmアプリケーションインスタンスをアップグレードします。バージョンは、Rancherのアップグレードを防ぐために一致する必要があります。

    helm upgrade rancher rancher-prime/rancher \
  --namespace cattle-system \
  -f values.yaml \
  --version <DEPLOYED_RANCHER_VERSION>

変更が完了したら、`\https://<rancher_server_url>/v3/settings/cacerts`に移動して、値が以前に`tls-ca`シークレットに書かれたCA証明書と一致することを確認してください。CA `cacerts`の値は、すべてのRancherポッドが起動するまで更新されない場合があります。

4.RancherエージェントをプライベートCAを信頼するように再構成します。

このセクションでは、RancherエージェントをプライベートCAを信頼するように再構成するための3つの方法を説明します。次のいずれかが真である場合、このステップは必要です：

  • Rancherは以前にRancher自己署名証明書（ingress.tls.source=rancher）またはLet’s Encrypt発行の証明書（ingress.tls.source=letsEncrypt）を使用するように構成されていました。

  • 証明書が異なるプライベートCAによって署名されていました。

なぜこのステップが必要なのですか？

RancherがプライベートCAによって署名された証明書で構成されている場合、CA証明書チェーンはRancherエージェントコンテナによって信頼されます。エージェントは、ダウンロードした証明書のチェックサムを`CATTLE_CA_CHECKSUM`環境変数と比較します。これは、Rancherが使用するプライベートCA証明書が変更された場合、環境変数`CATTLE_CA_CHECKSUM`をそれに応じて更新する必要があることを意味します。

どの方法を選ぶべきですか？

方法1は最も簡単ですが、証明書が回転された後、すべてのクラスターがRancherに接続されている必要があります。これは通常、Rancherのデプロイメントを更新または再デプロイした直後にプロセスが実行される場合に当てはまります（ステップ3）。

クラスターがRancherとの接続を失ったが、すべてのクラスターで認可されたクラスターエンドポイント（ACE）が有効になっている場合は、方法2を選択してください。

方法3は、方法1および2が不可能な場合のバックアップとして使用できます。

方法1:Rancherエージェントの再デプロイを強制します。

各ダウンストリームクラスターに対して、Rancher（ローカル）管理クラスターのKubeconfigファイルを使用して次のコマンドを実行します。

kubectl annotate clusters.management.cattle.io <CLUSTER_ID> io.cattle.agent.force.deploy=true

ダウンストリームクラスターのクラスターID（c-xxxxx）を特定します。これは、Rancher UIのクラスター管理でクラスターを表示しているときにブラウザのURLバーに表示されます。

このコマンドは、エージェントマニフェストを新しい証明書のチェックサムで再適用させます。

方法2:チェックサム環境変数を手動で更新します。

新しいCA証明書のチェックサムに一致する値に`CATTLE_CA_CHECKSUM`環境変数を更新することで、エージェントKubernetesオブジェクトを手動でパッチします。新しいチェックサム値を次のように生成します:

curl -k -s -fL <RANCHER_SERVER_URL>/v3/settings/cacerts | jq -r .value | sha256sum | awk '{print $1}'

各ダウンストリームクラスターの更新にKubeconfigを使用して、2つのエージェントデプロイメントの環境変数を更新します。クラスターにACEが有効になっている場合、直接ダウンストリームクラスターに接続するためにkubectlコンテキストを調整できます。

kubectl edit -n cattle-system ds/cattle-node-agent
kubectl edit -n cattle-system deployment/cattle-cluster-agent

方法3：Rancherエージェントを手動で再デプロイします。

この方法では、各ダウンストリームクラスターのコントロールプレーンノードで一連のコマンドを実行することにより、Rancherエージェントが再適用されます。

以下の手順を各ダウンストリームクラスターに対して繰り返します：

  1. エージェント登録のkubectlコマンドを取得します：

    1. ダウンストリームクラスターのクラスターID(c-xxxxx)を見つけます。これは、Rancher UIのクラスター管理でクラスターを表示しているときにURLに表示されます。

    2. 次のURLにRancherサーバーのURLとクラスターIDを追加します：https://<rancher_server_url>/v3/clusterregistrationtokens?clusterId=<CLUSTER_ID>

    3. `insecureCommand`フィールドからコマンドをコピーします。このコマンドは、プライベートCAが使用されている場合に用いられます。

  2. 前のステップのkubectlコマンドを、次のいずれかの方法でダウンストリームクラスターのkubeconfigを使用して実行します:

    1. クラスターにACEが有効になっている場合、コンテキストを調整して直接ダウンストリームクラスターに接続できます。

    2. または、SSHでコントロールプレーンノードに接続します：

      • RKE:https://github.com/rancherlabs/support-tools/tree/master/how-to-retrieve-kubeconfig-from-custom-cluster[ドキュメント内の手順]を使用してkubeconfigを生成します。

      • RKE2/K3s:インストール中に設定されたkubeconfigを使用します。

5.SUSE® Rancher Prime: Continuous Deliveryクラスターを強制更新して、Fleet agentをRancherに再接続します。

Rancher UIの継続的デリバリビュー内のクラスターに対して「強制更新」を選択し、ダウンストリームクラスターのFleet agentがRancherに正常に接続できるようにします。

なぜこのステップが必要なのですか？

Rancherが管理するクラスター内のFleet agentは、Rancherに接続するために使用されるkubeconfigを保存します。kubeconfigには、Rancherによって使用される証明書のCAを含む`certificate-authority-data`フィールドが含まれています。CAを変更する際には、このブロックを更新して、Fleet agentがRancherによって使用される証明書を信頼できるようにする必要があります。

プライベートCA証明書からパブリックCA証明書への更新

上記の手順に従って、プライベートCAによって発行された証明書からパブリックまたは自己署名CAに変更する手順を実行してください。

1.証明書シークレットオブジェクトを作成/更新する

まず、サーバー証明書の後に任意の中間証明書を連結して、`tls.crt`という名前のファイルに保存し、対応する証明書キーを`tls.key`という名前のファイルに提供します。

次のコマンドを使用して、Rancher（ローカル）管理クラスターに`tls-rancher-ingress`シークレットオブジェクトを作成します：

kubectl -n cattle-system create secret tls tls-rancher-ingress \
  --cert=tls.crt \
  --key=tls.key

または、既存の`tls-rancher-ingress`シークレットを更新するには：

kubectl -n cattle-system create secret tls tls-rancher-ingress \
  --cert=tls.crt \
  --key=tls.key \
  --dry-run --save-config -o yaml | kubectl apply -f -

2.CA証明書のシークレットオブジェクトを削除します。

もはや必要ないため、`cattle-system`名前空間内の`tls-ca`シークレットを削除します。必要に応じて、`tls-ca`シークレットのコピーを保存することもできます。

既存の`tls-ca`シークレットを保存するには：

kubectl -n cattle-system get secret tls-ca -o yaml > tls-ca.yaml

既存の`tls-ca`シークレットを削除するには：

kubectl -n cattle-system delete secret tls-ca

3.Rancherデプロイメントを再構成する

このステップは、証明書のソースが変更される場合に必要です。このシナリオでは、Rancherが以前にデフォルトの自己署名証明書（ingress.tls.source=rancher）を使用するように構成されていたため、変更される可能性が高いです。

以下の手順は、RancherチャートのHelm値を更新し、RancherポッドとIngressがステップ1で作成された新しい証明書を使用するように再構成されることを目的としています。

  1. 初回インストール時に使用した値を調整し、現在の値を次のように保存します：

    helm get values rancher -n cattle-system -o yaml > values.yaml

  2. 現在デプロイされているRancherチャートのバージョン文字列も取得します：

    helm ls -n cattle-system

  3. `values.yaml`ファイル内の現在のHelm値を更新します：

    1. プライベートCAはもはや使用されていないため、`privateCA: true`フィールドを削除するか、これを`false`に設定します。

    2. 必要に応じて`ingress.tls.source`フィールドを調整します。詳細については、チャートオプションを参照してください。たとえば、次のようになります。

      1. パブリックCAを使用している場合は、次の値を続行します：secret

      2. Let’s Encryptを使用している場合は、値を次のように更新します：letsEncrypt

  4. `values.yaml`ファイルと現在のチャートバージョンを使用してRancherチャートのHelm値を更新し、アップグレードを防ぎます：

    helm upgrade rancher rancher-prime/rancher \
  --namespace cattle-system \
  -f values.yaml \
  --version <DEPLOYED_RANCHER_VERSION>

4.Rancherエージェントを非プライベート/共通証明書用に再構成します。

プライベートCAがもはや使用されていないため、ダウンストリームクラスターエージェントの`CATTLE_CA_CHECKSUM`環境変数は削除するか、""（空の文字列）に設定する必要があります。

5.SUSE® Rancher Prime: Continuous Deliveryクラスターを強制更新して、Fleet agentをRancherに再接続します。

Rancher UIの継続的デリバリビュー内のクラスターに対して「強制更新」を選択し、ダウンストリームクラスターのFleet agentがRancherに正常に接続できるようにします。

なぜこのステップが必要なのですか？

Rancherが管理するクラスター内のFleet agentは、Rancherに接続するために使用されるkubeconfigを保存します。kubeconfigには、Rancherによって使用される証明書のCAを含む`certificate-authority-data`フィールドが含まれています。CAを変更する際には、このブロックを更新して、Fleet agentがRancherによって使用される証明書を信頼できるようにする必要があります。