Kubernetes サービス アカウントは、アプリケーションが Google Cloud APIs への承認済み呼び出しを行うために使用するGoogle Cloud サービス アカウントとは異なります。
Google Distributed Cloud は、秘密暗号鍵を使用して Pod に発行する KSA トークンに署名します。さらに、Pod によって Kubernetes API サーバーにリクエストが送信された際に、対応する公開鍵を使用してトークンを検証します。Pod が Workload Identity を使用して Google Cloud APIs を呼び出す場合、 Google Cloud は同じ公開鍵を使用して Pod の ID を認証します。
ユーザー クラスタの作成中に、Google Distributed Cloud は秘密鍵と公開鍵を生成します。また、クラスタの作成中に、Google Distributed Cloud はクラスタをフリートに登録し、公開鍵を Google Cloudに提供します。
Pod は、Kubernetes API サーバーを呼び出す際に、認証と認可のためにレガシー トークンまたはバウンド トークンのいずれかを使用します。バウンド トークンの有効期間は制限されており、計画された量を使用して Pod に配布されます。レガシー トークンには有効期限がなく、Kubernetes の Secret に保持されます。バウンド トークンは、安全性が高いため、使用することをおすすめします。
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]}
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-09-01 UTC。"],[],[],null,["A [Kubernetes service account (KSA)](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/)\nprovides an identity for processes that run in a Pod.\n\nKubernetes service accounts are different from the\n[Google Cloud service accounts](/iam/docs/service-account-overview)\nthat applications use to make authorized calls to Google Cloud APIs.\n\nGoogle Distributed Cloud uses a private cryptographic key to sign the\nKSA tokens that it issues to Pods. It uses the corresponding public key to\nvalidate the tokens when Pods send requests to the Kubernetes API server. When\na Pod uses\n[Workload Identity](/anthos/fleet-management/docs/use-workload-identity)\nto call Google Cloud APIs, Google Cloud uses the same public key to\nauthenticate the Pod's identity.\n\nDuring user cluster creation, Google Distributed Cloud generates the private and\npublic keys. Also during cluster creation, Google Distributed Cloud\n[registers the cluster to a fleet](/anthos/fleet-management/docs)\nand provides the public key to Google Cloud.\n\nAt a later\ntime, you can rotate the private/public key pair. The rotation automatically\nissues new tokens signed by the new private key. At the end of the rotation,\nthe cluster has a new private key, a new public key, and refreshed tokens. Also,\nGoogle Cloud has the new public key.\n\nBound tokens and legacy tokens\n\nA Pod can use either a\n[legacy token or a bound token](https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-bound-service-account-tokens)\nfor authentication and authorization when it calls the Kubernetes API server.\nBound tokens have a limited lifetime and are distributed to Pods using\n[projected volumes](https://kubernetes.io/docs/concepts/storage/projected-volumes/#serviceaccounttoken).\nLegacy tokens never expire and are held in Kubernetes\n[Secrets](https://kubernetes.io/docs/concepts/configuration/secret/).\nWe recommend bound tokens because they are more secure.\n\nBoth bound tokens and legacy tokens are refreshed during a key rotation.\n| **Important:** If you are using third-party tokens, they are not automatically refreshed during a rotation. To generate new third-party tokens, you will need to restart the Pods using these tokens.\n\nLimitations\n\n- If you created the cluster with [`enableAdvancedCluster`](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/user-cluster-configuration-file-latest#enable-advanced-cluster-field) set to `true` (which is required for [setting up topology domains](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/topology-domains-set-up)), key rotation isn't supported.\n\nStart a key rotation\n\nBefore you start a key rotation, consider these points:\n\n- During a key rotation, you cannot start another key rotation, certificate\n authority rotation, or cluster update.\n\n- Key rotation cannot be paused or rolled back. All old keys are deleted.\n\n- A key rotation deletes existing cluster nodes and creates new nodes.\n\nTo start a key rotation:\n\n```\ngkectl update credentials ksa-signing-key rotate \\\n --config USER_CLUSTER_CONFIG \\\n --kubeconfig ADMIN_CLUSTER_KUBECONIFG \\\n [--skip-prompt]\n```\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eUSER_CLUSTER_CONFIG\u003c/var\u003e: The path of the user cluster configuration\n file\n\n- \u003cvar translate=\"no\"\u003eADMIN_KUBECONFIG_FILE\u003c/var\u003e: The path of the admin cluster kubeconfig\n file\n\nInclude `--skip-prompt` if you do not want to be prompted.\n\nView the status of a key rotation\n\nTo view the status of a key rotation:\n\n```\ngkectl update credentials ksa-signing-key status \\\n --config USER_CLUSTER_CONFIG \\\n --kubeconfig ADMIN_CLUSTER_KUBECONIFG\n```\n\nIf the key rotation has already completed, you will see a message similar to\nthis:\n\n```\nState of KSASigningKeyRotation with KSASigningKeyVersion 2 is -\nstatus: True,\nreason: KSASigningKeyRotationCompleted,\nmessage:{\"tokenVersion\":2,\"privateKeyVersion\":2,\"publicKeyVersions\":[2]}\n```\n\nIf the KSA Signing Key rotation rotation is still in progress, you will see a\nmessage similar to this:\n\n```\nState of KSASigningKeyRotation with KSASigningKeyVersion 2 is -\nstatus: False,\nreason: KSASigningKeyRotationProcessedReason,\nmessage:{\"tokenVersion\":2,\"privateKeyVersion\":2,\"publicKeyVersions\":[1,2]}\n```"]]
