GKE on VMware は、証明書と秘密鍵を使用して、ユーザー クラスタにあるシステム コンポーネント間の接続を認証および暗号化します。管理クラスタは、ユーザー クラスタごとに新しい認証局（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 証明書のローテーションは、前述の etcd、クラスタ、フロントプロキシの CA に限定されます。
CA 証明書のローテーションの対象は、GKE on VMware によって自動的に発行される証明書のみです。管理者が手動で発行した証明書は、システム CA によって署名されている場合でも、ローテーションで更新されることはありません。
CA ローテーションでは、API サーバー、その他のコントロール プレーン プロセス、クラスタ内の各ノードを複数回再起動します。CA ローテーションの各ステージは、クラスタのアップグレードと同様に行われます。CA のローテーション中もユーザー クラスタは動作を継続しますが、ワークロードが再起動されて再スケジュールされることが想定されます。また、ユーザー クラスタに高可用性コントロール プレーンがない場合は、コントロール プレーンのダウンタイムが短時間発生することも予想されます。
CA ローテーション後に、ユーザー クラスタの kubeconfig ファイルと認証構成ファイルを更新する必要があります。古いクラスタ証明書が取り消され、kubeconfig ファイルの認証情報が機能しなくなるためです。
CA ローテーションが開始されると、一時停止やロールバックはできません。
ユーザー クラスタのサイズによっては、CA のローテーションが完了するまでに、かなりの時間を要する場合があります。
CA ローテーションを実行する
ローテーションを開始します。
gkectl update credentials certificate-authorities rotate \ --config USER_CLUSTER_CONFIG \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG次のように置き換えます。
USER_CLUSTER_CONFIGE: ユーザー クラスタの構成ファイルのパス
ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの 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
ローテーションのステータスを表示します。
gkectl update credentials certificate-authorities status \ --config USER_CLUSTER_CONFIG \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG上記のコマンドは、
CAVersionを報告します。これは、ローテーションの前後に使用された CA を区別するためにシステムが自動的に増加する整数です。また、このコマンドは、CA ローテーションが完了したかどうかを示すステータス（TrueまたはFalse）と、各コンポーネントで現在使用されているCAVersionを示すメッセージも報告します。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 ファイルを取得する必要があります。これは、CA ローテーションによって、古い kubeconfig ファイルが基づく CA が取り消されるためです。
新しい kubeconfig ファイルを取得します。
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret admin \
-n USER_CLUSTER_NAME -o jsonpath='{.data.admin\.conf}' \
| base64 --decode > USER_CLUSTER_NAME-kubeconfig
新しい kubeconfig ファイルを、kubeconfig ファイルを使用してクラスタを操作するすべてのユーザーに配布します。
認証構成ファイルを更新する
CA のローテーションが完了したら、認証構成ファイルを更新して再配布する必要があります。リンク先の手順に沿って、CA のローテーション後に、これらのファイルを更新して再配布します。
コントロール プレーン証明書のローテーション
ローテーションを行わないと、ユーザー クラスタの CA とコントロール プレーンの証明書はどちらも、クラスタの作成日から 5 年間で期限切れになります。ユーザー クラスタのコントロール プレーン証明書は、各ユーザー クラスタのアップグレードから 10 時間以内に自動的にローテーションされますが、CA は自動的にローテーションされません。つまり、定期的なバージョン アップグレードに加え、少なくとも 5 年に 1 回 CA ローテーションを実行する必要があります。
ユーザー クラスタが使用不能にならないようにするために、ユーザー クラスタのアップグレードから 10 時間以内にコントロール プレーンの証明書がローテーションされます。この場合、ユーザー クラスタの CA ローテーション ステータスにメッセージが表示されます。
コントロール プレーンの証明書がローテーションされたときに、ユーザー クラスタがアップグレードされた最後のバージョンを表示するには:
gkectl update credentials certificate-authorities status \ --config USER_CLUSTER_CONFIG \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
この情報は、アップグレードから 10 時間以内に message フィールドの最後に表示されます。次に例を示します。
Last Leaf Certificates Rotation Version: 1.16.0-gke.0.
CA ローテーションのトラブルシューティング
gkectl diagnose コマンドは、完了した CA ローテーションの予想されるステータスをユーザー クラスタに対してチェックすることをサポートします。ユーザー クラスタで gkectl diagnose を実行する方法については、クラスタの問題の診断をご覧ください。CA ローテーションの問題が発生した場合は、Google サポートに連絡して gkectl diagnose の出力を提供してください。