管理クラスタの 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 ファイルをすべてのクラスタ ユーザーに配布します。