Kubernetes 服務帳戶與應用程式用來對 Google Cloud API 發出授權呼叫的Google Cloud 服務帳戶不同。
Google Distributed Cloud 會使用私密加密編譯金鑰，簽署發給 Pod 的 KSA 權杖。當 Pod 將要求傳送至 Kubernetes API 伺服器時，kubelet 會使用對應的公開金鑰驗證權杖。當 Pod 使用 Workload Identity 呼叫 API 時， Google Cloud Google Cloud 會使用相同的公開金鑰驗證 Pod 的身分。
建立使用者叢集時，Google Distributed Cloud 會產生私密和公開金鑰。此外，在建立叢集期間，Google Distributed Cloud 會向機群註冊叢集，並將公開金鑰提供給 Google Cloud。
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 (世界標準時間)。"],[],[],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```"]]
