Google Distributed Cloud는 인증서 및 비공개 키를 사용하여 클러스터의 시스템 구성요소 간 연결을 인증하고 암호화합니다. 클러스터 인증 기관(CA)은 이러한 인증서 및 키를 관리합니다. bmctl
update credentials certificate-authorities rotate 명령어를 실행하면 Google Distributed Cloud가 다음 작업을 수행합니다.
이 명령어는 클러스터 CA, etcd CA, 프런트 프록시 CA의 새 클러스터 인증 기관(CA)을 만들어 관리자 클러스터의 사용자 클러스터 네임스페이스에 업로드합니다.
관리자 클러스터 컨트롤러는 사용자 클러스터 인증 기관을 새로 생성된 인증 기관으로 바꿉니다.
관리자 클러스터 컨트롤러는 새로운 공개 CA 인증서 및 리프 인증서 키 쌍을 사용자 클러스터 시스템 구성요소에 배포합니다.
이 명령어는 또한 클러스터 생성 중 Google Distributed Cloud에서 생성된 stackdriver-prometheus-etcd-scrape 보안 비밀을 업데이트합니다.
Prometheus가 etcd 측정항목을 수집하려면 이 보안 비밀이 필요합니다.
보안 클러스터 통신을 유지하려면 주기적으로 사용자 클러스터 CA를 순환하고 보안 침해가 발생할 가능성이 있을 때마다 순환합니다.
시작하기 전에
클러스터의 인증 기관을 순환하기 전에 다음 조건과 영향을 고려하여 계획을 수립하세요.
CA 순환을 시작하기 전에 관리자 및 사용자 클러스터 버전이 1.9.0 이상인지 확인합니다.
CA 순환은 점진적으로 이루어지므로 순환 중에도 시스템 구성요소가 서로 통신할 수 있습니다.
CA 순환은 API 서버, 제어 영역 프로세스, 클러스터의 각 노드를 여러 번 다시 시작합니다. CA 순환의 각 단계는 클러스터 업그레이드와 비슷하게 진행됩니다. CA가 순환되는 동안 사용자 클러스터가 작동 상태로 유지되지만 워크로드가 다시 시작되고 다시 예약된다는 것에 주의해야 합니다.
사용자 클러스터에 고가용성 컨트롤 플레인이 없으면 CA 순환 중 컨트롤 플레인에 짧은 다운타임이 발생할 수 있습니다.
클러스터 관리 작업은 CA 순환 중에 허용되지 않습니다.
CA 순환 기간은 클러스터 크기에 따라 달라집니다. 예를 들어 컨트롤 플레인이 1개 있고 워커 노드가 50개인 클러스터의 경우 CA 순환이 완료되는 데 2시간까지 걸릴 수 있습니다.
제한사항
인증 기관 순환 기능에는 다음 제한이 포함됩니다.
CA 순환은 클러스터 CA가 인증서를 서명하더라도 관리자가 수동으로 발급한 인증서를 업데이트하지 않습니다. 사용자 클러스터 CA 순환이 완료된 후 수동으로 발급된 인증서를 업데이트하고 다시 배포합니다.
CA 순환은 시작된 후 일시 중지되거나 롤백될 수 없습니다.
클러스터 CA 순환 시작
기본적으로 TLS 인증서의 유효 기간은 1년입니다.
Google Distributed Cloud는 인증 기관을 순환할 때 이러한 인증서를 갱신합니다. Google Distributed Cloud는 또한 클러스터 업그레이드 중 TLS 인증서를 갱신합니다. 보안과 지원을 유지하고 TLS 인증서가 만료되지 않도록 클러스터를 정기적으로 업그레이드하는 것이 좋습니다.
[[["이해하기 쉬움","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,["Google Distributed Cloud uses certificates and private keys to authenticate and encrypt\nconnections between system components in clusters. The cluster certificate\nauthority (CA) manages these certificates and keys. When you run the `bmctl\nupdate credentials certificate-authorities rotate` command,\nGoogle Distributed Cloud performs the following actions:\n\n- The command creates and uploads new cluster certificate authorities (CAs)\n for the cluster CA, the etcd CA, and the front-proxy CA to the user cluster\n namespace in the admin cluster.\n\n- The admin cluster controllers replace the user cluster certificate\n authorities with the newly generated ones.\n\n- The admin cluster controllers distribute the new public CA certificates and\n leaf certificate key pairs to user cluster system components.\n\n- The command also updates the `stackdriver-prometheus-etcd-scrape` Secret,\n which was created by Google Distributed Cloud during cluster creation.\n Prometheus requires this secret to collect etcd metrics.\n\nTo maintain secure cluster communication, rotate your user cluster CA\nperiodically and whenever there is a possible security breach.\n| **Important:** If your cluster certificates have expired, you must renew them manually to regain cluster operation. For more information and instructions, see [Renew expired cluster certificates manually](/kubernetes-engine/distributed-cloud/bare-metal/docs/troubleshooting/expired-certs).\n\nBefore you begin\n\nBefore you rotate your cluster's certificate authority, plan according to the\nfollowing conditions and impacts:\n\n- Ensure admin and user clusters are at version 1.9.0 or higher before\n starting the CA rotation.\n\n- CA rotation is incremental, allowing system components to communicate during\n the rotation.\n\n- A CA rotation restarts the API server, other control-plane processes, and\n each node in the cluster multiple times. Each stage of a CA rotation\n progresses similarly to a cluster upgrade. While the user cluster does\n remain operational during a CA rotation, you should expect that workloads\n will be restarted and rescheduled.\n\n- If your user cluster doesn't have a [high-availability control plane](/kubernetes-engine/distributed-cloud/bare-metal/docs/reference/cluster-config-ref#controlplane-nodepoolspec-nodes),\n expect brief periods of control-plane downtime during CA rotation.\n\n- Cluster management operations aren't allowed during CA rotation.\n\n- CA rotation duration depends on the size of your cluster. For example, CA\n rotation may take close to two hours to complete for a cluster with one\n control plane and 50 worker nodes.\n\nLimitations\n\nThe certificate authority rotation capability has the\nfollowing limitations:\n\n- CA rotation doesn't update certificates issued manually by an administrator,\n even if the cluster CA signs the certificates. Update and redistribute any\n manually issued certificates after user cluster CA rotation is complete.\n\n- Once started, CA rotation can't be paused or rolled back.\n\nStart a cluster CA rotation\n\nBy default, TLS certificates have a 1-year expiration period.\nGoogle Distributed Cloud renews these certificates when you rotate certificate\nauthorities. Google Distributed Cloud also renews the TLS certificates during\ncluster upgrades. We recommend that you upgrade your clusters regularly to keep\nthem secure, supported, and to prevent TLS certificates from expiring.\n\nUse the following command to start the CA rotation process: \n\n bmctl update credentials certificate-authorities rotate --cluster \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e \\\n --kubeconfig \u003cvar translate=\"no\"\u003eKUBECONFIG\u003c/var\u003e\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e: the name of the cluster for which you want to rotate CAs.\n- \u003cvar translate=\"no\"\u003eKUBECONFIG\u003c/var\u003e: the path to the admin cluster kubeconfig file. For self-managing clusters, this file is the cluster's kubeconfig file.\n\nThe `bmctl` command exits after the CA is rotated successfully and a new\nkubeconfig file is generated. The standard path for the kubeconfig file is\n`bmctl-workspace/`\u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e`/`\u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e`-kubeconfig`.\n\nTroubleshoot a cluster CA rotation\n\nThe `bmctl update credentials` command displays the progress of the CA rotation.\nThe associated `update-credentials.log` file is saved to the following\ntimestamped directory: \n\n bmctl-workspace/\u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e/log/update-credentials-\u003cvar translate=\"no\"\u003eTIMESTAMP\u003c/var\u003e"]]
