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 ローテーションを実行する必要があります。
制限事項
高度なクラスタには次の制限事項があります。
- バージョン 1.31: 高度なクラスタでは CA のローテーションはサポートされていません。
- バージョン 1.32 以降: 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 ファイルのパス
コマンドの動作は、高度なクラスタが有効になっているかどうかによって異なります。
無効
gkectl update credentials certificate-authorities rotate コマンドは、ローテーションの最初の半分を開始して実行します。次にコマンドは一時停止するので、次のコマンドを実行して kubeconfig ファイルを更新できます。
kubeconfig ファイルを更新する
gkectl update credentials certificate-authorities rotate コマンドが一時停止したら、管理クラスタの 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
有効
高度なクラスタが有効になっている場合、gkectl update credentials
certificate-authorities rotate コマンドは同期されます。コマンドは、CA ローテーションの進行に応じてステータス メッセージを管理ワークステーションに出力します。
CA が正常にローテーションされると、コマンドが終了し、新しい kubeconfig ファイルが自動的に生成されます。コマンドで指定した kubeconfig ファイルが新しいファイルに置き換えられます。コマンドの出力は次のようになります。
Beginning CA rotation with generated CA ... Successfully rotated CA for admin cluster. The kubeconfig file "/home/ubuntu/kubeconfig" has been updated. Done rotating certificate-authorities
新しい kubeconfig ファイルを配布する
新しい管理クラスタの kubeconfig ファイルをすべてのクラスタ ユーザーに配布します。