内部での CA の移行

メッシュ内に複数のクラスタがあり、ワークロードが他のクラスタにリクエストを送信している場合は、すべてのクラスタについて、このガイドのすべての手順を行います。

このガイドでは、次のユースケースについて説明します。

  • Mesh CA を使用するクラスタ内の Anthos Service Mesh v1.13 以降のコントロール プレーンを Certificate Authority Service に移行する。
  • Mesh CA を使用し、v1.13 以降にマッピングされたリリース チャネルのマネージド Anthos Service Mesh コントロール プレーンを Certificate Authority Service に移行する。

制限事項

インプレース CA の移行とアップグレードは、Anthos Service Mesh v1.13 以降でのみサポートされます。マネージド コントロール プレーンを移行する場合は、選択したチャネルが v1.13 以降にマッピングされていることを確認します。

前提条件

このガイドの手順に進む前に、次のことを確認してください。

また、現在 Anthos Service Mesh v1.13 以降を使用していることも確認してください。

必要なツール

移行中に、Google 提供のツール（migrate_ca）を実行します。このツールには次の依存関係があります。

  • awk
  • grep
  • jq
  • kubectl
  • head
  • sed
  • tr
  • yq

migrate_ca ツールをダウンロードする前に、移行の準備の手順を行ってください。

移行の概要

移行プロセス中は、以前の CA を使用するワークロードと新しい CA を使用するワークロードの間で、認証と認可が完全に機能します。

migrate_ca 移行ツールは、インストールされている Anthos Service Mesh のリビジョン / チャネルごとに CA 移行のステータスを追跡する Kubernetes 構成マップを作成します。これは、istio-system 名前空間にインストールされる特権リソースです。

apiVersion: v1
kind: ConfigMap
metadata:
  Name: asm-ca-migration-<revision>
Data:
  revision:
  start_time:
  state_update_time:
  current_state: TRUSTANCHOR_INJECT | MIGRATE_CA | ROLLBACK
  old_ca:
  target_ca:

移行ツールは、修正する前に Istio MeshConfig 構成マップをバックアップします。また、可能であれば ProxyConfig CRD を使用して CA 構成の移行を試みます。

CA の移行の概要は次のとおりです。

  1. 移行を準備する。

  2. 新しい CA を初期化する。

  3. フリート内のすべてのクラスタにメッシュ全体の trustAnchors を追加する。

  4. CA を移行する。

  5. ロールバックを行う。

移行を準備する

  1. migrate_ca bash ツールをダウンロードします。

    curl  https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/main/scripts/migration/ca-migration/migrate_ca > migrate_ca

  2. ツールを実行可能にします。

    chmod +x migrate_ca

  3. 作業ディレクトリを設定します。

    ./migrate_ca setup --output_dir OUTPUT_DIR

  4. 作業ディレクトリを前の手順で指定した OUTPUT_DIR に変更します。

    cd OUTPUT_DIR

  5. 次のコマンドを実行して、すべての前提条件が満たされていることを確認します。

    ./migrate_ca check-prerequisites

  6. 移行する以前の CA に関連付けられているコントロール プレーンのリビジョン（ASM_REVISION）をメモします。必要な手順は、コントロール プレーンの種類（クラスタ内またはマネージド）によって異なります。

    クラスタ内

    asm-revision=$(kubectl get deploy -n istio-system -l app=istiod -o \
 "jsonpath={.items[*].metadata.labels[istio\.io/rev']}{'\n'}")

    マネージド

    すでにインストールされているチャネルをご覧ください。

  7. インプレース CA 移行では、ワークロードを再起動する必要があります。このため、Pod 停止予算が正しく構成されていることと、CA の移行が必要なすべてのアプリケーションに、実行中の Pod が複数存在することを確認してください。

  8. クラスタがすでにフリートに登録されていることと、Workload Identity がクラスタで有効になっていることを確認します。以降の手順で使用できるようにフリート プロジェクト ID（FLEET_ID）をメモします。

  9. このツールは、kubeConfig と kubeContext を受け入れ、オペレーションが実行されるクラスタを選択します。これらの引数を渡さない場合、デフォルトのコンテキストと構成が使用されます。

    • GKE クラスタの認証情報を kubeConfig に追加するには、次のコマンドを使用します。

      gcloud container clusters get-credentials CLUSTER_NAME

    • 現在の kubectl コンテキストを変更するか、コンテキストをツールに渡すには、次のコマンドを使用します。

      kubectl config get-contexts
kubectl config use-context CLUSTER_NAME

新しい CA を初期化する

  1. 新しい CA の初期化に必要な手順は、移行先の新しい CA によって異なります。CA を移行するすべてのフリート クラスタで次の操作を行います。

    Mesh CA

    ユーティリティ ツールの initialize サブコマンドを呼び出します。

    Kubernetes カスタム構成を指定する場合:

     ./migrate_ca initialize --kubeconfig KUBECONFIG --kubecontext KUBECONTEXT --ca mesh_ca --old_ca OLD_CA_TYPE \
 --fleet_id FLEET_ID --revision ASM_REVISION

    それ以外の場合:

     ./migrate_ca initialize --ca mesh_ca --old_ca OLD_CA_TYPE \
 --fleet_id FLEET_ID --revision ASM_REVISION
 ```

    CA Service

    a. Certificate Authority Service の初期化に必要な手順を行います。CA_POOL をメモします。

    b. ユーティリティ ツールの initialize サブコマンドを呼び出します。

    Kubernetes カスタム構成を指定する場合:

     ./migrate_ca initialize --kubeconfig KUBECONFIG --context KUBECONTEXT --ca gcp_cas --ca-pool CA_POOL --ca-old OLD_CA_TYPE \
 --fleet-id FLEET_ID --revision ASM_REVISION

    それ以外の場合:

      ./migrate_ca initialize --ca gcp_cas --ca-pool CA_POOL --ca-old OLD_CA_TYPE \
  --fleet-id FLEET_ID --revision ASM_REVISION

フリート内のすべてのクラスタにメッシュ全体の trustAnchors を追加する

  1. フリートに含まれるすべてのクラスタで、新しい CA と古い CA の両方に対して以下の手順を繰り返します。

  2. CA の trustAnchors をダウンロードします。

    Mesh CA

    ./migrate_ca download-trust-anchor --ca mesh_ca --ca_cert ROOT_CERT.pem

    CA Service

    CA 証明書をファイルに保存します。

    gcloud privateca pools get-ca-certs POOL_NAME --location=POOL_REGION --project=POOL_PROJECT--output-file ROOT_CERT.pem

  3. CA の trustAnchors を追加します。

    ./migrate-ca add-trust-anchor --ca_cert ROOT_CERT.pem

  4. trustAnchors がフリート内のすべてのワークロードで受信されていることを確認します。namespaces 引数で、ワークロードがデプロイされているすべての名前空間を渡します。

    ./migrate-ca check-trust-anchor --ca_cert ROOT_CERT.pem --namespaces NAMESPACES

    予想される出力:

    Check the CA cert in namespace nsa-1-24232
a-v1-597f875788-52c5t.nsa-1-24232 trusts root-cert.pem

CA を移行する

  1. CA 構成を移行します。必要なコマンドは、移行先の新しい CA によって異なります。

    Mesh CA

    ./migrate_ca migrate-ca --ca mesh_ca

    CA Service

    ./migrate_ca migrate-ca --ca gcp_cas --ca_pool CA_POOL

  2. すべてのワークロードを再起動します。

    TLS トラフィックのダウンタイム リスクを最小限に抑えるため、この手順で最初に影響を受けるワークロードの数を最小限にとどめる必要があります。再起動するのは、コントロール プレーンのリビジョン ASM_REVISION に関連付けられているワークロードのみです。たとえば、kubernetes 名前空間 NAMESPACE 内のすべてのワークロードが同じ Anthos Service Mesh コントロール プレーンに関連付けられているとします。

    kubectl rollout restart deployment -n NAMESPACE

  3. 再起動した名前空間のワークロードと他のワークロードの間で mTLS 接続が機能することを確認してから、すべての名前空間とフリート内のすべてのクラスタに対して手順 1 と 2 を繰り返します。新しいワークロードが起動し、メッシュ トラフィックが中断されていない場合は、フリートの一部であるすべての名前空間とクラスタで手順 1 と 2 を繰り返します。それ以外の場合は、ロールバックを実行して、新しい CA 構成をロールバックします。

  4. すべてのワークロードで新しい CA 構成が使用されていることを確認します。

    ./migrate_ca verify-ca --ca_cert ROOT_CERT.pem --namespaces NAMESPACES

    予想される出力:

    Check the CA configuration in namespace nsb-2-76095
b-v1-8ff557759-pds69.nsb-2-76095 is signed by root-cert.pem

ロールバックを実行する

  1. CA 構成をロールバックし、新しく構成した trustAnchors を削除します。

    ./migrate-ca rollback

  2. すべてのワークロードを再起動します。コントロール プレーンのリビジョン ASM_REVISION に関連付けられているワークロードのみを再起動してください。たとえば、kubernetes 名前空間 NAMESPACES 内のすべてのワークロードが同じ Anthos Service Mesh コントロール プレーンに関連付けられているとします。

    kubectl rollout restart deployment -n NAMESPACES

  3. （省略可）古い CA 構成がすべてのワークロードで使用されていることを確認します。

    ./migrate-ca verify-ca --ca_cert older-root-cert.pem

  4. ワークロードが ASM_REVISION コントロール プレーンを使用するフリート内のすべてのクラスタに対して、手順 1～3 を繰り返します。

これで完了です。インプレース CA 移行が正常に完了しました。