OpenShift クラスター証明書の再生成

この手順は RHSB-2023-001 用です。

OpenShift Container Platform クラスターには、内部の自己署名ルート CA を使用する複数のトラストチェーンがあります。OpenShift Container Platform にこれらの CA と関連する証明書を再生成させることができます。

特に ROSA の場合、マネージドサービスの SRE が FIPS 証明書のローテーションを実行します。ARO チームがローテーションを行う必要はありません。

FIPS モードで実行されているクラスターの証明書を再生成する場合は、FIPS モードで起動された RHEL サーバーなどの FIPS 準拠環境からこれらの手順を実行する必要があります。

クラスター証明書を再生成する目的は、FIPS に準拠していないバイナリーによって生成された証明書の使用を回避することです。この目的を達成するには、ターゲットクラスターを完全に FIPS 準拠のバージョンにアップグレードした後にこの手順を実行する必要があります。

選択したコントロールプレーンの証明書の再生成

コントロールプレーンの選択した証明書を再生成するには、次の手順に従います。すべての証明書がローテーションされるわけではありません。

前提条件

• cluster-admin パーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。
• https://access.redhat.com/security/vulnerabilities/RHSB-2023-001 を読み、クラスターで実行されている OpenShift のバージョンに FIPS の修正済み z stream を適用している。
• OpenShift CLI (oc) の修正済み 4.11 z stream バージョンがインストールされている。
• STS で AWS を使用している場合は、以下も必要となる。
  • 利用可能な ccoctl ツール
  • 利用可能な AWS CLI ツール
  • keys.json を S3 にプッシュするために使用した CLUSTER_ID。これはインストール時に ccoctl で使用された可能性があります。

手順

1. この手順を開始した日付をメモして保存し、クラスター内の古い証明書の信頼を取り消す日付を把握できるようにします。
   date +"%Y-%m-%dT%H:%M:%S%:z"

   出力はこの形式で表示されます。この情報は必ず保存してください。
   2023-06-16T10:57:04-04:00

2. クラスターが安定状態にあることを確認します。
   oc adm wait-for-stable-cluster --minimum-stable-period=5s

   コマンドの結果は次のように出力されます。

   All clusteroperators are stable

   クラスターが安定状態にない場合は、まず Operator を安定させます。このコマンドを使用して確認できます。

3. namespace/openshift-config-managed に新しいクライアント証明書を生成します。有効期限は約 4 週間後になります。
   oc adm ocp-certificates regenerate-leaf -n openshift-config-managed secrets kube-controller-manager-client-cert-key kube-scheduler-client-cert-key

   コマンドの結果は次のように出力されます。

   secret/kube-controller-manager-client-cert-key regeneration set
secret/kube-scheduler-client-cert-key regeneration set

4. namespace/kube-apiserver-operator に新しい証明書を生成します。有効期限は約 4 週間後になります。
   oc adm ocp-certificates regenerate-leaf -n openshift-kube-apiserver-operator secrets node-system-admin-client

   コマンドの結果は次のように出力されます。
   secret/node-system-admin-client regeneration set

5. namespace/kube-apiserver に新しい証明書を生成します。有効期限は約 4 週間後になります。
   oc adm ocp-certificates regenerate-leaf -n openshift-kube-apiserver secrets check-endpoints-client-cert-key control-plane-node-admin-client-cert-key  external-loadbalancer-serving-certkey internal-loadbalancer-serving-certkey kubelet-client localhost-recovery-serving-certkey localhost-serving-cert-certkey service-network-serving-certkey

   コマンドの結果は次のように出力されます。

   secret/check-endpoints-client-cert-key regeneration set
secret/control-plane-node-admin-client-cert-key regeneration set
secret/external-loadbalancer-serving-certkey regeneration set
secret/internal-loadbalancer-serving-certkey regeneration set
secret/kubelet-client regeneration set
secret/localhost-recovery-serving-certkey regeneration set
secret/localhost-serving-cert-certkey regeneration set
secret/service-network-serving-certkey regeneration set

6. 変更後、クラスター Operator が安定するまで待ちます。これには 30 分ほどかかる場合がありますので、しばらくお待ちください。
   oc adm wait-for-stable-cluster

   コマンドの結果は次のように出力されます。
   All clusteroperators are stable

7. FIPS に準拠していない暗号モジュールを使用して作成された新しいルート署名者を生成します。

   注意: この手順を実行したら、手順 17 (ノードの再起動) までのすべての手順を
   できるだけ早く完了する必要があります。約 4 週間後、クラスターは自動的にこの新しい署名者を使用して新しいリーフ証明書を再生成し、
   再起動されていないものは kube-apiserver を信頼しなくなります。
   oc adm ocp-certificates regenerate-top-level -n openshift-kube-apiserver-operator secrets kube-apiserver-to-kubelet-signer
kube-control-plane-signer loadbalancer-serving-signer localhost-serving-signer service-network-serving-signer

   コマンドの結果は次のように出力されます。
   secret/kube-apiserver-to-kubelet-signer regeneration set
secret/kube-control-plane-signer regeneration set
secret/loadbalancer-serving-signer regeneration set
secret/localhost-serving-signer regeneration set
secret/service-network-serving-signer regeneration set

8. clusteroperator/kube-controller-manager をトリガーして、バインドされた新しいサービスアカウント署名鍵を作成します。
   oc -n openshift-kube-controller-manager-operator delete secrets/next-service-account-private-key

   このコマンドにより次の出力が生成されます。
   secret "next-service-account-private-key" deleted

9. clusteroperator/kube-apiserver をトリガーして、バインドされた新しいサービスアカウント署名鍵を作成します。
   `oc -n openshift-kube-apiserver-operator delete secrets/next-bound-service-account-signing-key

   このコマンドにより次の出力が生成されます。

   secret "next-bound-service-account-signing-key" deleted

10. 変更後、クラスター Operator が安定するまで待ちます。これには 30-45 分ほどかかる場合がありますので、しばらくお待ちください。
    oc adm wait-for-stable-cluster

    コマンドの結果は次のように出力されます。
    All clusteroperators are stable

11. AWS で実行しており、STS を使用している場合は、バインドされたサービスアカウントトークンの署名者を信頼するために、STS で使用する S3 バケットを更新する必要があります。
    a. バインドされた SA トークンキーの署名に使用する現在の公開鍵を収集します。
    oc get -n openshift-kube-apiserver-operator secret/next-bound-service-account-signing-key -ojsonpath='{ .data.service-account\.pub }' | base64 -d > bound-sa.pub

    これにより、RSA 公開鍵を含む bound-sa.pub ファイルが書き込まれます。

    b. S3 に提供する必要がある keys.json を生成します。
    ccoctl aws create-identity-provider --name=some-name --region=other-region --dry-run --public-key-file=bound-sa.pub

    これにより、ローカルディレクトリーにいくつかのファイルが書き込まれます。必要なのは 03-keys.json だけです。

    c. 新しい keys.json を S3 にアップロードします。
    aws s3 cp ./03-keys.json s3://rh-oidc-staging/$CLUSTER_ID/keys.json

    d. OIDC プロバイダーに CloudFront を使用している場合は、CloudFront で keys.json の特定のパス
    (例: /$CLUSTER_ID/keys.json) のキャッシュを削除します。

これを行う方法は状況によって異なります。たとえば、CLI で次のコマンドを実行します。

aws cloudfront create-invalidation --distribution-id $DISTRIBUTION_ID --path /$CLUSTER_ID/keys.json

12. GCP Workload Identity で実行している場合は、バインドされたサービスアカウントトークンの署名者を信頼するために、次の更新を実行する必要があります。
    a. バインドされた SA トークンキーの署名に使用する現在の公開鍵を収集します。
    oc get -n openshift-kube-apiserver-operator secret/next-bound-service-account-signing-key -ojsonpath='{ .data.service-account\.pub }' | base64 -d > bound-sa.pub

    b. gs に提供する必要がある keys.json を生成します。
    

\# Must export GOOGLE_CREDENTIALS, otherwise the ccoctl command will prompt "Service Account (absolute path to file or JSON content) [Enter 2
empty lines to finish]", even if gcloud auth list shows current account is the same aos-qe-serviceaccount@openshift-qe.iam.gserviceaccount.com .

    export GOOGLE_CREDENTIALS=/home/xxia/my/priv/cucushift-internal/config/credentials/openshift-qe-gce_v4.json

    REGION=$(oc get infrastructure cluster -o=jsonpath='{.status.platformStatus.gcp.region}')

    BUCKET=$(oc get authentication.config cluster -o jsonpath='{.spec.serviceAccountIssuer}' | grep -o '[^/]*$')

    WIDP=$(sed 's/-oidc$//' <<< $BUCKET)

    ccoctl gcp create-workload-identity-provider --name=$WIDP --region=$REGION --project=openshift-qe --dry-run --public-key-file=bound-sa.pub --
workload-identity-pool=$WIDP

    c. 次に、新しい keys.json を gs にアップロードします。
    

\# Must export company proxy otherwise the gsutil ls command is stuck with "INFO 0705 17:39:39.103127 retry_util.py] Retrying request, attempt

\#21..." if your network is not good to access google cloud services.

    https_proxy=http://squid.apac.redhat.com:3128 gsutil ls gs://$BUCKET/

    KEYS_FILE=$(ls 0?-keys.json) <br><br>\

\# unlike 03-keys.json for above aws sts cluster, it is 04-keys.json for GCP workload identity cluster

    https_proxy=http://squid.apac.redhat.com:3128 gsutil cp $KEYS_FILE gs://$BUCKET/keys.json

13. FIPS に準拠していない暗号モジュールを使用して作成された openshift-config-managed の新しいクライアント証明書を生成します。
    oc adm ocp-certificates regenerate-leaf -n openshift-config-managed secrets kube-controller-manager-client-cert-key kube-scheduler-client-cert-key

    コマンドの結果は次のように出力されます。

    secret/kube-controller-manager-client-cert-key regeneration set
secret/kube-scheduler-client-cert-key regeneration set

14. ローカルの kubeconfig でクラスターの CA バンドルを更新します。これにより、マシン上の kubeconfig が書き換えられ、kube-apiserver を認識するために Pod に注入された同じ CA バンドルを含むようになります。
    oc config refresh-ca-bundle

    このコマンドでは通常、次のようなメッセージが生成されます。

    CA bundle for cluster "<your-cluster-name>" updated.

    次のメッセージが表示される場合もあります。

    error: failed to update CA bundle: using system CA bundle to verify server, not allowing refresh to
overwrite

    コマンドによると、kube-apiserver への接続にはシステムのトラストバンドルが使用されており、
    refresh-ca-bundle は必要ないので、続行できます。

15. 新しい kubelet の bootstrap.kubeconfig を作成して、kube-apiserver がその提供証明書を再生成した後に kubelet がその kube-apiserver を認識できるようにします。
    oc config new-kubelet-bootstrap-kubeconfig > bootstrap.kubeconfig

    これにより、現在の作業ディレクトリーに bootstrap.kubeconfig が作成されます。

16. 次のコマンドを実行して、新しい bootstrap.kubeconfig が機能することを確認します。
    oc whoami --kubeconfig=bootstrap.kubeconfig --server=$(oc get infrastructure/cluster -ojsonpath='{ .status.apiServerURL }')

    コマンドの結果は次のように出力されます。

    system:serviceaccount:openshift-machine-config-operator:node-bootstrapper

17. bootstrap.kubeconfig をすべてのノードにコピーします。
    oc adm copy-to-node nodes --all --copy=bootstrap.kubeconfig=/etc/kubernetes/kubeconfig

18. すべての kubelet を再起動し、古い kubelet.kubeconfig を削除して新しい bootstrap.kubeconfig を取得し (2 つの異なる kubeconfig)、新しいクライアント証明書を取得します。
    oc adm restart-kubelet nodes --all --directive=RemoveKubeletKubeconfig

19. すべてのノードを再起動して、すべての Pod が新しい署名者を含む更新後のトラストバンドルで再起動することを確認します。
    oc adm reboot-machine-config-pool mcp/worker mcp/master

    コマンドの結果は次のように出力されます。

    machineconfig.machineconfiguration.openshift.io/95-oc-initiated-reboot-worker rolling reboot initiated
machineconfigpool.machineconfiguration.openshift.io/worker rolling reboot initiated
machineconfig.machineconfiguration.openshift.io/95-oc-initiated-reboot-master rolling reboot initiated
machineconfigpool.machineconfiguration.openshift.io/master rolling reboot initiated

20. ノードが再起動するまで待ちます。このコマンドが完了しなかった場合は、特定のノードが目的の再起動を達成できなかった理由を判断する必要があります。これは通常、ノードが何らかの正常でない状態にあるために発生します。これらのノードを正常な状態にするか、削除してください。信頼がローテーションされているため、この再起動を実行できないノードでは、手順 7 からの 30 日間のカウントダウン後に Operator によって新しい提供証明書が作成されると、Pod が期待どおりに機能しない可能性があります。
    oc adm wait-for-node-reboot nodes --all

    完了すると、コマンドが出力されます。成功するまで、ステータス行が 30 秒ごとに出力されます。ステータスが
    長時間フリーズしているように見える場合は、特定のノードが進行しない理由をさらに詳しくデバッグします。

    All nodes rebooted

21. FIPS に準拠していない暗号モジュールを使用して作成された kube-apiserver-operator の新しいクライアント証明書を生成します。
    oc adm ocp-certificates regenerate-leaf -n openshift-kube-apiserver-operator secrets node-system-admin-client

    コマンドの結果は次のように出力されます。

    secret/node-system-admin-client regeneration set

22. FIPS に準拠していない暗号モジュールを使用して作成された kube-apiserver の新しいクライアント証明書を生成します。
    oc adm ocp-certificates regenerate-leaf -n openshift-kube-apiserver secrets check-endpoints-client-cert-key control-plane-node-admin-client-cert-key external-loadbalancer-serving-certkey internal-loadbalancer-serving-certkey kubelet-client localhost-recovery-serving-certkey localhost-serving-cert-certkey service-network-serving-certkey

    コマンドの結果は次のように出力されます。

    secret/check-endpoints-client-cert-key regeneration set
secret/control-plane-node-admin-client-cert-key regeneration set
secret/external-loadbalancer-serving-certkey regeneration set
secret/internal-loadbalancer-serving-certkey regeneration set
secret/kubelet-client regeneration set
secret/localhost-recovery-serving-certkey regeneration set
secret/localhost-serving-cert-certkey regeneration set
secret/service-network-serving-certkey regeneration set

23. 変更後、クラスター Operator が安定するまで待ちます。このプロセスには 30 分ほどかかる場合があります。
    oc adm wait-for-stable-cluster

    コマンドの結果は次のように出力されます。

    All clusteroperators are stable

    イメージレジストリーが STS クラスター上でスタックする場合、この現象は、イメージレジストリー自体の
    問題ではありません。失敗する場合は、手順 11 からの keys.json が正しいことを再確認し、すべての Pod を再起動します。これは、
    すべてのノードを再起動し直すのが最善です。

    `oc adm reboot-machine-config-pool mcp/worker mcp/master

    oc adm wait-for-node-reboot nodes --all`

24. この時点で、クラスターは新しい証明書を使用していますが、古い証明書もまだ信頼しています。

25. 次のコマンドを入力して、新しい system:masters/admin.kubeconfig を作成します。
    oc config new-admin-kubeconfig > admin.kubeconfig

    これにより、新しい署名者とクライアントの証明書と鍵のペアを使用して kube-apiserver に接続できるファイルが admin.kubeconfig に
    保存されます。

26. 次のコマンドを入力して、新しい admin.kubeconfig が機能することを確認します。
    oc --kubeconfig=admin.kubeconfig whoami

    コマンドの結果は次のように出力されます。

    system:admin

27. 上記で置き換えられた古い署名者の信頼を取り消します。
    oc adm ocp-certificates remove-old-trust -n openshift-kube-apiserver-operator configmaps kube-apiserver-to-kubelet-client-ca kube-control-plane-signer-ca loadbalancer-serving-ca localhost-serving-ca service-network-serving-ca --created-before=<date-from-step-1>

    コマンドの結果は次のように出力されます。

    configmap/kube-apiserver-to-kubelet-client-ca trust purged
configmap/kube-control-plane-signer-ca trust purged
configmap/loadbalancer-serving-ca trust purged
configmap/localhost-serving-ca trust purged
configmap/service-network-serving-ca trust purged

28. 変更後にクラスター Operator が安定するまで待ちます。このプロセスには 30 分ほどかかる場合があります。
    oc adm wait-for-stable-cluster

    コマンドの結果は次のように出力されます。

    All clusteroperators are stable

29. すべてのノードを再起動して、すべての Pod が新しい署名者を含む更新後のトラストバンドルで再起動することを確認します。
    oc adm reboot-machine-config-pool mcp/worker mcp/master

    コマンドの結果は次のように出力されます。

    machineconfig.machineconfiguration.openshift.io/95-oc-initiated-reboot-worker rolling reboot initiated
machineconfigpool.machineconfiguration.openshift.io/worker rolling reboot initiated
machineconfig.machineconfiguration.openshift.io/95-oc-initiated-reboot-master rolling reboot initiated
machineconfigpool.machineconfiguration.openshift.io/master rolling reboot initiated

30. ノードが再起動するまで待ちます。このコマンドが完了しなかった場合は、特定のノードが目的の再起動を達成できなかった理由を判断する必要があります。これは通常、ノードが何らかの正常でない状態にあるために発生します。
    oc adm wait-for-node-reboot nodes --all

    完了すると、コマンドが出力されます。 成功するまで、ステータス行が 30 秒ごとに出力されます。ステータスが
    長時間フリーズしているように見える場合は、特定のノードが進行しない理由を
    さらに詳しくデバッグします。

    すべてのノードが再起動されます。

マシン設定サーバーの CA 証明書の再生成

重要: この手順を実行する前に、更新するクラスターのそれぞれの OCP マイナーバージョンに対して最新の OC クライアントバイナリーバージョンを使用していることを確認してください。 これらは次の場所から入手できます。
最新の 4.10 OC
最新の 4.11 OC
最新の 4.12 OC
最新の 4.13 OC

Machine Config Operator には、マシン設定サーバーによって使用される、自動的にローテーションされない CA と証明書のペアがあります。これは、ノードが起動して初めてクラスターに結合するときにのみ使用されるもので、その結果は次のようになります。

1. クラスター内で完全には動作しない可能性があります。

2. インストール後は、新しいノードがクラスターに結合しない限り使用されません。

証明書チェーンは、次のように、新しいノードの Ignition バイナリーが、クラスターのマシン設定サーバーが提供する Ignition のコンテンツを検証するときに使用されます (例: IPI on AWS を使用)。

1. マシンセットがスケールアップされ、クラスターに新しいノードが追加されます。

2. マシンセットで参照される user-data シークレットは、AWS のクラウドの user-data に渡されます。これは、MCS CA と、マシン設定サーバーのエンドポイントを指す HTTP URL を含むスタブ Ignition です。

3. 新しいノードは、最初の起動時に initramfs フェーズで Ignition を実行して完全な Ignition 設定を要求し、その際にスタブ Ignition の CA データを使用して受信コンテンツを検証します。

4. 新しいノードは完全な (ワーカー) 設定で再起動し、クラスターに結合します。

ローテーションコマンドには 2 つの部分があります。

1. クラスター内で MCS CA/証明書をローテーションします。

2. デフォルトでは、これは新しい証明書を使用するために user-data の Ignition の更新を呼び出します。

以下に詳述するように、特定のクラスター環境でこのシークレットがどのように消費されるかに応じて手順は異なります。

前提条件

• cluster-admin パーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。
• OpenShift CLI (oc) がインストールされている。

手順

続行する前に、openshift-machine-config-operator プロジェクトのシークレットのバックアップを作成します。

oc get secret/machine-config-server-tls -n openshift-machine-config-operator -oyaml > machine-config-server-tls.bak
oc get secret/machine-config-server-ca -n openshift-machine-config-operator -oyaml > machine-config-server-ca.bak

シナリオ 1: 完全に自動化されている (クラウドなど、ノードスケーリング対応マシンセットに適用可能)

1. 1 つのコマンドを実行して CA/証明書を再生成し、user-data を自動的にローテーションします。
   oc adm ocp-certificates regenerate-machine-config-server-serving-cert

   このコマンドにより次の出力が生成されます。

   Successfully rotated MCS CA + certs.Redeploying MCS and updating references.
Successfully modified user-data secret master-user-data
Successfully modified user-data secret worker-user-data

   手順を個別に実行するには、次の 2 つのコマンドを実行します。

   oc adm ocp-certificates regenerate-machine-config-server-serving-cert
oc adm ocp-certificates update-ignition-ca-bundle-for-machine-config-server

2. 任意で、CA と証明書が正常に作成されたことを検証します。
   oc adm ocp-certificates regenerate-machine-config-server-serving-cert --update-ignition=false
oc -n openshift-machine-config-operator get secrets

   新しく生成された次のものが表示されます。

   machine-config-server-ca
machine-config-server-tls

   リスト内のシークレット

3. 任意で、新しいワーカーノードをクラスターにスケールできることを検証します。これにより、追加のリソースコストが発生します。

シナリオ 2: 半自動の手作業での user-data 更新 (metal/pxe など、スケーリング非対応マシンセットに適用可能)

1. --update-ignition フラグで user-data シークレットを更新することなく、再生成コマンドを実行します。このフラグはオプションであり、シークレットが未使用または存在しない場合でもエラーは発生しません。
   oc adm ocp-certificates regenerate-machine-config-server-serving-cert --update-ignition=false

   このコマンドにより次の出力が生成されます。

   `Successfully rotated MCS CA + certs.`Redeploying MCS and updating references.

2. 更新済みの MCS CA 証明書を見つけます。
   oc -n openshift-machine-config-operator get secret/machine-config-server-ca -o=jsonpath='{.data.tls\.crt}'

3. インストーラーによって生成された可能性のある、ノードの起動に使用されている現在のスタブ Ignition を見つけます。以下に例を示します。
   {"ignition":{"config":{"merge":[{"source":"..."}]},"security":{"tls":{"certificateAuthorities":[{"source":"data:text/plain;charset=utf-8;base64,CERT"}]}},"version":"3.2.0"}}

   CERT フィールドを 2 の内容に置き換えます。

   任意で、更新された設定で新しいノードを追加して、クラスターに結合できるかどうかを確認することもできます。この
   新しい証明書は、新しいノードをクラスターに結合させる必要がない場合は使用されません。

Ingress の内部 CA の再生成

クラスターのインストール後、Ingress Operator は内部の自己署名 CA を生成し、それを openshift-ingress-operator namespace の router-ca シークレットに保存します。Ingress Operator はこの CA を使用して、デフォルトの Ingress Controller とカスタムの Ingress Controller 用のワイルドカード証明書を発行します。

クラスター管理者は、インストール後にクラスターを実稼働環境に移行する前に、Operator が生成したワイルドカード証明書をカスタムのワイルドカード証明書に置き換える必要があります。詳細は、デフォルト ingress 証明書の置き換え を参照してください。

クラスター管理者がカスタムのワイルドカード証明書を設定した後、router-ca シークレットの自己署名 CA 証明書は、使用されない場合であっても、引き続き存在します。この証明書が期限切れになった場合、または再生成する必要がある場合は、次の手順に従って再生成します。

前提条件

• cluster-admin パーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。
• cluster-admin パーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。

手順

1. router-ca シークレットを削除します。
   oc -n openshift-ingress-operator delete secrets/router-ca

   このコマンドにより次の出力が生成されます。

   secret "router-ca" deleted

2. router-ca シークレットがなくなったことを検証します。
   oc -n openshift-ingress-operator get secrets/router-ca

   このコマンドにより次の出力が生成されます。

   Error from server (NotFound): secrets "route-ca" not found

3. Ingress Operator を再起動します。
   oc -n openshift-ingress-operator delete pods -l name=ingress-operator

   このコマンドにより、次のような出力が生成されます (Ingress-operator- の後の Pod 名の部分は異なります)。
   pod "ingress-operator-db59c9d96-t58ch" deleted

   OpenShift Container Platform が自動的に Ingress Operator を再起動します。

4. Ingress Operator が再起動することを検証します。
   oc -n openshift-ingress-operator get pods -l name=ingress-operator

このコマンドにより、次のような出力が生成されます (Pod 名と AGE は異なります)。

Ingress Operator が router-ca シークレットが見つからないことを検出すると、Ingress Operator は新しい自己署名 CA を生成し、シークレットを再作成します。

5. Ingress Operator が router-ca シークレットを再作成したことを検証します。
   oc -n openshift-ingress-operator get secrets/router-ca

   このコマンドにより、次の出力が生成されます (AGE は異なる場合があります)。

AGE は、この手順を開始してからシークレットが再作成されていることを反映しています。