管理クラスタの CA 証明書のローテーション

Google Distributed Cloud は、証明書と秘密鍵を使用して、管理クラスタ内の Kubernetes システムコンポーネント間の通信を認証します。管理クラスタを作成すると、新しい認証局（CA）証明書が作成され、それらのルート証明書が Kubernetes システムコンポーネントに追加のリーフ証明書を発行するために使用されます。

このガイドは、管理クラスタの CA 証明書のローテーションにのみ適用されます。ユーザークラスタについては、ユーザークラスタの CA 証明書のローテーションをご覧ください。

管理クラスタでは、Kubernetes システムで使用される CA 証明書が 3 つあります。

etcd CA 証明書は、Kubernetes API サーバーから etcd レプリカへの通信と、etcd レプリカ間の通信を保護します。この証明書は自己署名によるものです。
クラスタ CA 証明書は、Kubernetes API サーバーとすべての内部 Kubernetes API クライアント（kubelet、コントローラマネージャー、スケジューラなど）間の通信を保護します。この証明書は自己署名によるものです。
フロントプロキシ CA 証明書は、集約 API との通信を保護します。この証明書は自己署名によるものです。

証明書のローテーションは、gkectl を使用してトリガーできます。ローテーションの際、gkectl によって管理クラスタのコアシステムの CA 証明書が新しく生成された証明書に置き換えられます。その後、新しい CA 証明書、リーフ証明書、秘密鍵が管理クラスタのシステムコンポーネントに配布されます。ローテーションは段階的に行われるため、システムコンポーネントはローテーション中も通信を継続できます。ただし、ローテーション中にワークロードとノードが再起動されることに注意してください。

ローテーションを行わないと、CA 証明書とコントロールプレーン証明書はクラスタの作成日から 5 年で期限切れになります。コントロールプレーンの証明書はクラスタのアップグレード中に自動的にローテーションされますが、CA は自動的にローテーションされません。つまり、定期的なバージョンアップグレードに加え、少なくとも 5 年に 1 回 CA ローテーションを実行する必要があります。

制限事項

CA 証明書のローテーションの対象は、前述の etcd、クラスタ、フロントプロキシの証明書のみです。
CA 証明書のローテーションは、Google Distributed Cloud によって自動的に発行される証明書に限定されます。管理者が手動で発行した証明書は、システム CA によって署名されている場合でも、ローテーションで更新されることはありません。
CA 証明書のローテーションにより、Kubernetes API サーバー、他のコントロールプレーンプロセス、管理クラスタ内の各ノードが複数回再起動されます。ローテーションの各ステージは、クラスタのアップグレードと同じように進行します。管理クラスタと、管理クラスタが管理するユーザークラスタは、証明書のローテーション中も動作し続けますが、管理クラスタ内のワークロードは再起動、再スケジュール設定されることが想定されます。また、管理クラスタコントロールプレーンとユーザークラスタコントロールプレーンでは、短時間のダウンタイムも想定されます。
証明書のローテーションの途中と、ローテーションの完了後に、管理クラスタの kubeconfig ファイルを更新する必要があります。古いクラスタ証明書が取り消され、kubeconfig ファイルの認証情報が機能しなくなるためです。
CA 証明書のローテーションは、一旦開始するとロールバックできません。
クラスタのサイズによっては、CA 証明書のローテーションが完了するまでに、かなりの時間を要する場合があります。
証明書のローテーションプロセスが中断された場合、同じコマンドを再実行することにより再開できます。ただし、1 度に実行されるローテーションコマンドは 1 つだけにする必要があります。

ローテーションを開始する

証明書のローテーションを開始するには、次のコマンドを実行します。ローテーションの前半が実行され、一時停止点で停止します。

ローテーションを開始します。

gkectl update credentials certificate-authorities rotate \
    --admin-cluster \
    --config ADMIN_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

次のように置き換えます。

ADMIN_CLUSTER_CONFIG: 管理クラスタの構成ファイルのパス
ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス

コマンドが中断した場合は、同じコマンドを実行すれば再開できます。

kubeconfig ファイルを更新する

前述のコマンドが一時停止したら、管理クラスタの kubeconfig ファイルを更新します。これにより、新しいクライアント証明書と新しい CA 証明書が kubeconfig ファイルに配置されます。古いクライアント証明書は kubeconfig ファイルから削除され、古い CA 証明書は kubeconfig ファイル内に保持されます。

gkectl update credentials certificate-authorities update-kubeconfig \
    --admin-cluster \
    --config ADMIN_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

ローテーションを続ける

次のコマンドを実行して、プロセスの後半を実行します。コマンドは、更新された kubeconfig ファイルが現在のディレクトリにあることを gkectl が確認できてはじめて続行されます。

gkectl update credentials certificate-authorities rotate \
    --admin-cluster \
    --complete \
    --config ADMIN_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

コマンドが中断した場合は、同じコマンドを実行すれば再開できます。

ローテーションが完了すると、現在の CA バージョンが報告されます。

再度 kubeconfig ファイルを更新する

ローテーションの後半が完了したら、再度 kubeconfig ファイルを更新します。これにより、古い CA 証明書が kubeconfig ファイルから削除されます。

gkectl update credentials certificate-authorities update-kubeconfig \
    --admin-cluster \
    --config ADMIN_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

新しい kubeconfig ファイルを配布する

新しい管理クラスタの kubeconfig ファイルをすべてのクラスタユーザーに配布します。