ユーザー クラスタ認証局のローテーション

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 ローテーション機能による影響を受けません。

制限事項

  • CA 証明書のローテーションの対象は、前述の etcd、クラスタ、フロント プロキシの CA のみです。

  • CA 証明書のローテーションの対象は、Google Distributed Cloud によって自動的に発行される証明書のみです。管理者が手動で発行した証明書は、システム CA によって署名されている場合でも、ローテーションで更新されることはありません。

  • CA ローテーションでは、API サーバー、その他のコントロール プレーン プロセス、クラスタ内の各ノードを複数回再起動します。CA ローテーションの各ステージは、クラスタのアップグレードと同様に行われます。CA のローテーション中もユーザー クラスタは動作を継続しますが、ワークロードが再起動されて再スケジュールされることが想定されます。また、ユーザー クラスタに高可用性コントロール プレーンがない場合、コントロール プレーンのダウンタイムが短時間発生することも想定されます。

  • CA のローテーション後に、ユーザー クラスタの kubeconfig ファイルと認証構成ファイルを更新する必要があります。古いクラスタ証明書が取り消され、kubeconfig ファイルの認証情報が機能しなくなるためです。

  • CA ローテーションの開始後は、一時停止やロールバックはできません。

  • ユーザー クラスタのサイズによっては、CA のローテーションが完了するまでに、かなりの時間を要する場合があります。

CA ローテーションを実行する

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

    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
    
  2. ローテーションのステータスを表示します。

    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 の出力を提供してください。