Google Distributed Cloud は、証明書と秘密鍵を使用して、ユーザー クラスタにあるシステム コンポーネント間の接続の認証と暗号化を行います。管理クラスタは、ユーザー クラスタごとに新しい認証局(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 ローテーション機能による影響を受けません。
制限事項
enableAdvancedCluster
をtrue
に設定してクラスタを作成した場合(トポロジ ドメインの設定に必要)、CA 証明書のローテーションはサポートされません。CA 証明書のローテーションの対象は、前述の etcd、クラスタ、フロント プロキシの CA のみです。
CA 証明書のローテーションの対象は、Google Distributed Cloud によって自動的に発行される証明書のみです。管理者が手動で発行した証明書は、システム 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 とコントロール プレーンの証明書はどちらも、クラスタの作成日から 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
の出力を提供してください。