Kubernetes サービス アカウント（KSA）は、Pod で実行されるプロセスの ID を提供します。
Kubernetes サービス アカウントは、アプリケーションが Google Cloud APIs への承認済み呼び出しを行うために使用する Google Cloud サービス アカウントとは異なります。
GKE on VMware は、秘密暗号鍵を使用して Pod に発行する KSA トークンに署名します。それは、Pod が Kubernetes API サーバーにリクエストを送信する際に、対応する公開鍵を使用してトークンを検証します。Pod が Workload Identity を使用して Google Cloud APIs を呼び出す場合、Google Cloud は同じ公開鍵を使用して Pod の ID を認証します。
ユーザー クラスタの作成中に、GKE on VMware は秘密鍵と公開鍵を生成します。また、クラスタの作成中に、GKE on VMware はクラスタをフリートに登録し、公開鍵を Google Cloud に提供します。
後で、秘密鍵と公開鍵のペアをローテーションできます。ローテーションによって、新しい秘密鍵で署名された新しいトークンが自動的に発行されます。ローテーションの終了時に、クラスタには新しい秘密鍵、新しい公開鍵、更新されたトークンがあります。また、Google Cloud には新しい公開鍵もあります。
バウンド トークンとレガシー トークン
Pod は、Kubernetes API サーバーを呼び出す際に、認証と認可のためにレガシー トークンまたはバウンド トークンのいずれかを使用します。バウンド トークンの有効期間は制限されており、計画された量を使用して Pod に配布されます。レガシー トークンには有効期限がなく、Kubernetes の Secret に保持されます。バウンド トークンは安全性がより高いため、使用することをおすすめします。
バウンド トークンとレガシー トークンの両方が、鍵のローテーション中に更新されます。
鍵のローテーションを開始する
鍵のローテーションを開始する前に、次の点を検討します。
鍵のローテーション中は、別の鍵のローテーション、認証局のローテーション、クラスタの更新を開始できません。
鍵のローテーションは一時停止またはロールバックできません。古いキーがすべて削除されます。
鍵のローテーションにより、既存のクラスタノードが削除され、新しいノードが作成されます。
鍵のローテーションを開始するには:
gkectl update credentials ksa-signing-key rotate \
--config USER_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONIFG \
[--skip-prompt]
以下を置き換えます。
USER_CLUSTER_CONFIG: ユーザー クラスタの構成ファイルのパス
ADMIN_KUBECONFIG_FILE: 管理クラスタの kubeconfig ファイルのパス
プロンプトを表示したくない場合は、--skip-prompt を含めます。
鍵のローテーションのステータスを表示する
鍵のローテーションのステータスを表示するには:
gkectl update credentials ksa-signing-key status \
--config USER_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONIFG
鍵のローテーションがすでに完了している場合は、次のようなメッセージが表示されます。
State of KSASigningKeyRotation with KSASigningKeyVersion 2 is -
status: True,
reason: KSASigningKeyRotationCompleted,
message:{"tokenVersion":2,"privateKeyVersion":2,"publicKeyVersions":[2]}
KSA 署名鍵のローテーションが進行中の場合は、次のようなメッセージが表示されます。
State of KSASigningKeyRotation with KSASigningKeyVersion 2 is -
status: False,
reason: KSASigningKeyRotationProcessedReason,
message:{"tokenVersion":2,"privateKeyVersion":2,"publicKeyVersions":[1,2]}