Google Distributed Cloud에서 서비스 계정 키를 순환하려면 기존 클러스터 사용자 인증 정보를 bmctl 명령어로 업데이트합니다. 이 서비스 계정 키 순환은 사용자 인증 정보를 업데이트하는 일반 프로세스 중에 또는 잠재적인 키 노출에 대한 응답으로 수행될 수 있습니다. 클러스터 사용자 인증 정보를 업데이트하면 새 정보가 관리자 또는 하이브리드 클러스터로 전달되거나 관리자 클러스터에서 관리하는 영향을 받는 사용자 클러스터로 자동으로 라우팅됩니다.
업데이트할 수 있는 클러스터 사용자 인증 정보
Google Distributed Cloud 클러스터 생성 시에는 여러 사용자 인증 정보가 필요합니다.
관리자, 독립형 또는 하이브리드 클러스터를 만들 때 클러스터 구성에서 사용자 인증 정보를 설정하는데, 위에서 설명한 것처럼 사용자 클러스터는 관리자 클러스터(또는 관리자 역할을 하는 하이브리드 클러스터)가 관리하며 관리자 클러스터에서 동일한 사용자 인증 정보를 재사용합니다.
bmctl 명령어를 사용하여 Google Distributed Cloud 클러스터에서 다음 사용자 인증 정보와 해당 보안 비밀을 업데이트할 수 있습니다.
SSH 비공개 키: 노드 액세스에 사용됩니다.
Artifact Registry 키(anthos-baremetal-gcr): 이미지 가져오기를 위해 Artifact Registry가 인증하는 데 사용되는 서비스 계정 키입니다.
Connect 에이전트 서비스 계정 키(anthos-baremetal-connect): Connect 에이전트 포드에 사용되는 서비스 계정 키입니다.
Connect 레지스트리 서비스 계정 키(anthos-baremetal-register): 클러스터를 등록 또는 등록 취소할 때 허브에 인증하는 데 사용되는 서비스 계정 키입니다.
Cloud 운영 서비스 계정 키(anthos-baremetal-cloud-ops): Google Cloud Observability(Logging 및 Monitoring) API로 인증하기 위한 서비스 계정 키입니다.
bmctl로 사용자 인증 정보 업데이트
클러스터를 만들면 Google Distributed Cloud가 사용자 인증 정보 키를 기반으로 Kubernetes 보안 비밀을 만듭니다. 새 키를 생성할 때는 다음 단계에 설명된 대로 해당 보안 비밀을 업데이트해야 합니다. 키 이름 또는 경로가 변경되면 해당 클러스터 구성 파일도 업데이트해야 합니다.
ADMIN_KUBECONFIG: 관리자 또는 자체 관리 클러스터의 kubeconfig 파일 경로
CLUSTER_NAME: SSH 키를 업데이트할 클러스터의 이름
SSH_KEY_PATH: SSH 키 파일의 경로. 기본적으로 bmctl는 클러스터 구성 파일에 지정된 SSH 및 서비스 계정 키 파일을 확인합니다. bmctl이 만료된 키 파일을 찾으면 명령어가 실패합니다. 새 유효한 키 파일이 구성 파일에 지정된 것과 다른 위치에 있는 경우 이 같은 실패를 방지하기 위해 --ignore-validation-errors 플래그를 포함합니다.
bmctl update
credentials 명령어에 사용할 수 있는 플래그의 전체 목록은 bmctl 명령어 참조의 사용자 인증 정보 업데이트를 참조하세요.
[[["이해하기 쉬움","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-07-10(UTC)"],[],[],null,["To rotate the service account keys in Google Distributed Cloud, you update the\nexisting cluster credentials with the `bmctl` command. This service account key\nrotation might be as part of your regular processes to update credentials, or in\nresponse to a potential exposure of the keys. When you update cluster\ncredentials, the new information is passed to admin or hybrid clusters, or\nautomatically routed to affected user clusters managed by an admin cluster.\n\nCluster credentials that can be updated\n\nGoogle Distributed Cloud clusters require multiple credentials when they are created.\nYou set the credentials in the cluster config when you create an admin,\nstandalone, or hybrid cluster. User clusters, as noted previously, are managed\nby an admin cluster (or a hybrid cluster acting as admin), and will reuse the\nsame credentials from the admin cluster.\n\nFor more information about creating clusters and different cluster types,\nsee [Installation overview: choosing a deployment model](/kubernetes-engine/distributed-cloud/bare-metal/docs/installing/install-prep).\n\nYou can update the following credentials, and their corresponding secrets,\nin Google Distributed Cloud clusters with the `bmctl` command:\n\n- **SSH private key**: Used for node access.\n- **Artifact Registry key** (`anthos-baremetal-gcr`): Service account key used to authenticate with Artifact Registry for image pulling.\n- **Connect agent service account key** (`anthos-baremetal-connect`): Service account key used by Connect agent pods.\n- **Connect register service account key** (`anthos-baremetal-register`): Service account key used to authenticate with Hub when registering or unregistering a cluster.\n- **Cloud operations service account key** (`anthos-baremetal-cloud-ops`): Service account key to authenticate with Google Cloud Observability (logging \\& monitoring) APIs.\n\nUpdate credentials with `bmctl`\n\nWhen you create clusters, Google Distributed Cloud creates Kubernetes Secrets\nbased on your credential keys. If you generate new keys, you must update the\ncorresponding Secrets as described in the following steps. If the name or path\nto your keys change, you must also update the corresponding cluster\nconfiguration file.\n\n1. Prepare the new values for the credentials you want to update:\n\n - You can\n [generate new Google service account keys](/iam/docs/keys-create-delete#creating)\n through the Google Cloud CLI or through the Google Cloud console.\n\n - Generate new SSH private key on the admin workstation and make sure the\n cluster node machines have the corresponding public key.\n\n2. Update the credentials section of your cluster configuration file with paths\n to the new keys.\n\n3. Update the corresponding cluster Secrets with the `bmctl update credentials`\n command, adding the appropriate flags.\n\n The following example updates the credentials for a new SSH private key: \n\n bmctl update credentials --kubeconfig \u003cvar translate=\"no\"\u003eADMIN_KUBECONFIG\u003c/var\u003e \\\n --cluster \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e \\\n --ssh-private-key-path \u003cvar translate=\"no\"\u003eSSH_KEY_PATH\u003c/var\u003e\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eADMIN_KUBECONFIG\u003c/var\u003e: the path of the kubeconfig file\n of the admin or self-managing cluster.\n\n - \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e: the name of the cluster that you're\n updating the SSH key for.\n\n - \u003cvar translate=\"no\"\u003eSSH_KEY_PATH\u003c/var\u003e: the path of the SSH key file. By\n default, `bmctl` checks the SSH and service account key files specified\n in the cluster configuration file. If `bmctl` finds an expired key file,\n the command fails. If you have the new valid key file in a different\n location than what's specified in the configuration file, include the\n `--ignore-validation-errors` flag to avoid this failure.\n\n For a complete list of the flags that you can use with the `bmctl update\n credentials` command, see [update\n credentials](/kubernetes-engine/distributed-cloud/bare-metal/docs/reference/bmctl#update_credentials) in the `bmctl`\n command reference."]]
