Anthos clusters on VMware（GKE On-Prem）は、証明書と秘密鍵を使用してユーザー クラスタ内のシステム コンポーネント間の接続を認証および暗号化します。管理クラスタは、ユーザー クラスタごとに新しい認証局（CA）を作成し、これらの CA 証明書を使用してシステム コンポーネントの追加のリーフ証明書を発行します。管理クラスタは、システム コンポーネントへの公開 CA 証明書とリーフ証明書の鍵ペアの配布を管理し、安全な通信を確立します。
ユーザー クラスタの CA ローテーション機能を使用すると、ユーザー クラスタ内のコアシステム証明書のローテーションをトリガーできます。ローテーション時に、管理クラスタはユーザー クラスタのコアシステム CA を新しく生成した CA に置き換え、新しい公開 CA 証明書とリーフ証明書鍵ペアをユーザー クラスタ システム コンポーネントに分散します。ローテーションは段階的に行われるため、システム コンポーネントはローテーション中も通信を継続できます。ただし、ローテーション中にワークロードとノードが再起動されることに注意してください。
各ユーザー クラスタで、管理クラスタによって管理されるシステム CA は次の 3 つです。
- etcd CA は、API サーバーから etcd レプリカへの通信と、etcd レプリカ間のトラフィックを保護します。この CA は自己署名です。
- クラスタ CA は、API サーバーとすべての内部 Kubernetes API クライアント（kubelet、コントローラ、スケジューラ）間の通信を保護します。 この CA は自己署名です。
- フロントプロキシ CA は、集約 API との通信を保護します。この CA は自己署名です。
authentication.sni オプションで構成した証明書に署名するために、org CA を使用することもできます。この CA と SNI 証明書は、クラスタ外部のクライアントに Kubernetes API を提供するために使用されます。自身でこの CA を管理し、SNI 証明書を手動で生成します。この CA と SNI 証明書のどちらも、ユーザー クラスタの CA ローテーション機能による影響を受けません。
制限事項
- ユーザー クラスタの CA ローテーション機能は、Anthos clusters on VMware クラスタ バージョン 1.8 以降でサポートされています。
- ユーザー クラスタの CA ローテーション機能は、概要で説明した etcd、クラスタ、フロントプロキシの CA に限定されています。org CA はローテーションされません。ユーザー クラスタの CA ローテーション機能は、さらに Anthos clusters on VMware によって自動的に発行される証明書に限定されます。管理者が手動で発行した証明書は、システム CA によって署名されている場合でも、ローテーションで更新されることはありません。
- CA ローテーションでは、API サーバー、その他のコントロール プレーン プロセス、クラスタ内の各ノードを複数回再起動する必要があります。CA ローテーションの各ステージは、クラスタのアップグレードと同様に行われます。CA のローテーション中もユーザー クラスタは動作を継続しますが、ワークロードが再起動されて再スケジュールされることが想定されます。また、HA 構成を使用しない場合は、コントロール プレーンのダウンタイムが短時間発生することも予想されます。
- ユーザー クラスタに接続するためのユーザー クラスタの kubeconfig ファイルと認証構成ファイルは、CA ローテーション後に手動で更新して再配布する必要があります。これは、CA ローテーションによって古い CA が必ず取り消されるため、これらの認証情報が認証されなくなるためです。
- 一度開始されると、CA ローテーションを一時停止またはロールバックすることはできません。
- ユーザー クラスタのサイズによっては、CA のローテーションが完了するまでに、かなりの時間を要する場合があります。
CA ローテーションの実行方法
次の gkectl コマンドを実行して、CA ローテーションを開始し、ローテーションの現在のステータスを表示できます。
CA 証明書をローテーションする
CA ローテーションをトリガーするには、次のコマンドを実行します。
gkectl update credentials certificate-authorities rotate \ --config USER_CONFIG_FILE \ --kubeconfig ADMIN_KUBECONFIG_FILE
ここで
- USER_CONFIG_FILE は、CA をローテーションする対象であるユーザー クラスタのユーザー クラスタ構成ファイルへのパスです。
- ADMIN_KUBECONFIG_FILE は、ユーザー クラスタを管理する管理クラスタに接続するための kubeconfig ファイルへのパスです。
CA ローテーションが正常に開始すると、次のようなメッセージが表示されます。
successfully started the CA rotation with CAVersion 2, use gkectl update credentials certificate-authorities status command to view the current state of CA rotation
CA ローテーションがすでに進行中の場合は、次のようなエラー メッセージが表示されます。
Exit with error: admission webhook "vonpremusercluster.onprem.cluster.gke.io" denied the request: requests must not modify CAVersion when cluster is not ready: ready condition is not true: ClusterCreateOrUpdate: Creating or updating user cluster control plane workloads
CA ローテーション ステータスを表示する
CA ローテーションのステータスを表示するには、次のコマンドを実行します。このコマンドは CAVersion を報告します。これは、各 CA ローテーションの前後で使用された CA を区別するために、システムが自動的にインクリメントする整数です。ステータス（True または False）は、CA のローテーションが完了したかどうかと、システムの各コンポーネントで現在使用されている CAVersion を示すメッセージです。
gkectl update credentials certificate-authorities status \ --config USER_CONFIG_FILE \ --kubeconfig ADMIN_KUBECONFIG_FILE
CA のローテーションがすでに完了している場合は、次のようなメッセージが表示されます。
State of CARotation with CAVersion 2 is - status: True, reason: CARotationCompleted, message: Control plane has CA bundle [2], certs from CA 2, CA 2 is CSR signer. Data plane has CA bundle [2], CA 2 was CSR signer at last restart.
CA のローテーションが引き続き進行中である場合は、次のようなメッセージが表示されます。
State of CARotation with CAVersion 2 is - status: False, reason: CARotationProgressed, message: Control plane has CA bundle [1 2], certs from CA 2, CA 1 is CSR signer. Data plane has CA bundle [1 2], CA 1 was CSR signer at last restart.
ユーザー クラスタ認証情報を更新する
CA ローテーションが完了したら、新しいユーザー クラスタ kubeconfig ファイルを管理クラスタからダウンロードして、以前にユーザー クラスタへの接続に使用していた古い kubeconfig を置き換える必要があります。これは、CA ローテーションによって、古い kubeconfig ファイルが基づく古い CA が取り消されるためです。CA のローテーションの完了後に次のコマンドを実行して、新しい kubeconfig ファイルをダウンロードします。
kubectl --kubeconfig ADMIN_KUBECONFIG_FILE get secret admin \
-n USER_CLUSTER_NAME -o jsonpath='{.data.admin\.conf}' \
| base64 --decode > USER_CLUSTER_NAME-kubeconfig
追加の kubeconfig ファイルがクラスタの他のユーザーに手動で発行された場合は、それらのファイルも更新する必要があります。
認証構成ファイルを更新する
CA のローテーションが完了したら、認証構成ファイルを更新して再配布する必要があります。リンク先の手順に沿って、CA のローテーション後に、これらのファイルを更新して再配布します。
CA ローテーションのトラブルシューティング
gkectl diagnose コマンドは、完了した CA ローテーションの予想されるステータスをユーザー クラスタに対してチェックすることをサポートします。ユーザー クラスタで gkectl diagnose を実行する方法については、クラスタの問題の診断をご覧ください。CA ローテーションの問題が発生した場合は、Google サポートに連絡して gkectl diagnose の出力を提供してください。