Kubernetes 서비스 계정은 애플리케이션에서 Google Cloud API에 승인된 호출을 수행하는 데 사용하는 Google Cloud 서비스 계정과는 다릅니다.
Google Distributed Cloud는 비공개 암호화 키를 사용하여 포드에 발급하는 KSA 토큰에 서명합니다. 포드가 Kubernetes API 서버로 요청을 전송할 때 해당 공개 키를 사용하여 토큰을 검증합니다. 포드가 워크로드 아이덴티티를 사용하여 Google Cloud API를 호출하면 Google Cloud가 동일한 공개 키를 사용하여 포드의 ID를 인증합니다.
사용자 클러스터를 만드는 동안 Google Distributed Cloud는 비공개 키와 공개 키를 생성합니다. 또한 클러스터를 만드는 동안 Google Distributed Cloud는 클러스터를 Fleet에 등록하고 Google Cloud에 공개 키를 제공합니다.
나중에 비공개/공개 키 쌍을 순환할 수 있습니다. 순환은 새로운 비공개 키에 의해 서명된 새 토큰을 자동으로 발행합니다. 순환이 끝나면 클러스터에 새 비공개 키, 새 공개 키, 갱신된 토큰이 포함됩니다. 또한 Google Cloud에는 새로운 공개 키가 있습니다.
바인딩된 토큰 및 기존 토큰
포드는 Kubernetes API 서버를 호출할 때 인증 및 승인에 기존 토큰 또는 바인딩된 토큰을 사용할 수 있습니다.
바인딩된 토큰은 기간이 제한되며 예상 볼륨을 사용하여 포드에 분산됩니다.
기존 토큰은 만료되지 않으며 Kubernetes 보안 비밀에 보관됩니다.
바인딩된 토큰은 더 안전하므로 권장됩니다.
바인딩된 토큰과 기존 토큰 모두 키 순환 중에 새로고침됩니다.
키 순환 시작
키 순환을 시작하기 전에 다음 사항을 고려하세요.
키 순환 중에는 다른 키 순환, 인증 기관 순환 또는 클러스터 업데이트를 시작할 수 없습니다.
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"]],["최종 업데이트: 2024-11-22(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```"]]
