使用 kubectl 手動安裝 Config Sync

安全殼層金鑰組

安全殼層金鑰組包含兩個檔案：公開金鑰和私密金鑰。公開金鑰通常具有 .pub 副檔名。

如要使用安全殼層金鑰組，請完成下列步驟：

1. 建立安全殼層金鑰組，允許 Config Sync 向 Git 存放區驗證。如需驗證存放區，才能複製或讀取存放區，就必須執行這個步驟。如果安全性管理員已提供金鑰組，請略過這個步驟。您可以根據安全性和法規遵循需求，為所有叢集使用單一金鑰組，或為每個叢集使用一組金鑰。

   下列指令會建立 4096 位元的 RSA 金鑰。不建議使用較低的值：

   ssh-keygen -t rsa -b 4096 \
   -C "GIT_REPOSITORY_USERNAME" \
   -N '' \
   -f /path/to/KEYPAIR_FILENAME
   

   更改下列內容：

   • GIT_REPOSITORY_USERNAME：您要 Config Sync 用來向存放區驗證的使用者名稱
   • /path/to/KEYPAIR_FILENAME：金鑰組的路徑

   如果您使用第三方 Git 存放區主機 (例如 GitHub)，或想搭配 Cloud Source Repositories 使用服務帳戶，建議您使用獨立帳戶。

2. 設定存放區來識別您剛剛建立的公開金鑰。請參閱 Git 代管服務供應商的說明文件。為方便起見，我們提供了部分熱門 Git 代管服務供應商的操作說明：

   • Cloud Source Repositories
   • Bitbucket
   • GitHub 建議您建立獨立的部署金鑰，提供單一 GitHub 存放區的唯讀存取權。
   • GitLab

3. 將私密金鑰新增至叢集內的新 Secret：

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=ssh=/path/to/KEYPAIR_PRIVATE_KEY_FILENAME
   

   將 /path/to/KEYPAIR_PRIVATE_KEY_FILENAME 替換為私密金鑰的名稱 (沒有 .pub 後置字串)。

4. (建議) 如要使用 SSH 驗證設定已知主機檢查，請將已知主機金鑰新增至 git_creds 密鑰中的 data.known_hosts 欄位。如要停用 known_hosts 檢查，可以從密鑰中移除 known_hosts 欄位。如要新增已知主機金鑰，請執行下列指令：

   kubectl edit secret git-creds \
    --namespace=config-management-system
   

   接著，在 data 下方新增已知主機項目：

   known_hosts: KNOWN_HOSTS_KEY
   

5. 將私密金鑰從本機磁碟中刪除或妥善保管。

6. 設定 Config Sync 並新增 Git 存放區網址時，請使用 SSH 通訊協定。如果您使用 Cloud Source Repositories 中的存放區，輸入網址時必須採用下列格式：

   ssh://EMAIL@source.developers.google.com:2022/p/PROJECT_ID/r/REPO_NAME
   

   更改下列內容：

   • EMAIL：您的 Cloud de Confiance 使用者名稱
   • PROJECT_ID：存放區所在 Cloud de Confiance專案的 ID
   • REPO_NAME：存放區名稱

Cookiefile

取得 cookiefile 的程序取決於存放區的設定。如需範例，請參閱 Cloud Source Repositories 說明文件中的「產生靜態憑證」。憑證通常儲存在主目錄的 .gitcookies 檔案中，或由資安管理員提供。

如要使用 cookiefile，請完成下列步驟：

1. 建立並取得 cookiefile 後，請將其新增至叢集內的新 Secret。

   如果您不使用 HTTPS Proxy，請使用下列指令建立 Secret：

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=cookie_file=/path/to/COOKIEFILE
   

   如需使用 HTTPS Proxy，請執行下列指令，將 Proxy 與 cookiefile 一併新增至 Secret：

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=cookie_file=/path/to/COOKIEFILE \
    --from-literal=https_proxy=HTTPS_PROXY_URL
   

   更改下列內容：

   • /path/to/COOKIEFILE：適當的路徑和檔案名稱
   • HTTPS_PROXY_URL：與 Git 存放區通訊時使用的 HTTPS Proxy 網址

2. 如果仍須在本機中保存 cookiefile，請務必妥善保管檔案內容。否則請將其刪除。

權杖

如果貴組織不允許使用安全殼層金鑰，可以選擇使用權杖。有了 Config Sync，您就能將 GitHub 的個人存取權杖 (PAT)、GiLab 的 PAT 或部署金鑰，或 Bitbucket 的應用程式密碼做為權杖使用。

如要使用權杖建立 Secret，請完成下列步驟：

1. 使用 GitHub、GitLab 或 Bitbucket 建立權杖：

   • GitHub： 建立個人存取權杖 (PAT)。 為權杖授予 repo 範圍，以便讀取私人存放區。 由於您會將 PAT 繫結至 GitHub 帳戶，建議您一併建立機器使用者，並將 PAT 繫結至該使用者。
   • GitLab：建立 PAT 或建立部署權杖
   • Bitbucket： 建立應用程式密碼。

2. 建立並取得權杖之後，請將權杖新增至叢集內的新 Secret。

   如果您不使用 HTTPS Proxy，請使用下列指令建立 Secret：

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
     --namespace="config-management-system" \
     --from-literal=username=USERNAME \
     --from-literal=token=TOKEN
   

   更改下列內容：

   • USERNAME：您要使用的使用者名稱。
   • TOKEN：您在上一個步驟中建立的權杖。

   如需使用 HTTPS Proxy，請執行下列指令，將 Proxy 與 username 和 token 一併新增至 Secret：

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-literal=username=USERNAME \
     --from-literal=token=TOKEN \
    --from-literal=https_proxy=HTTPS_PROXY_URL
   

   更改下列內容：

   • USERNAME：您要使用的使用者名稱。
   • TOKEN：您在上一個步驟中建立的權杖。
   • HTTPS_PROXY_URL：與 Git 存放區通訊時使用的 HTTPS Proxy 網址。

3. 如果本機仍須使用權杖，請妥善保管，如果不需要，則請刪除。

Google 服務帳戶

如果存放區位於 Cloud Source Repositories 或 Secure Source Manager，且叢集使用 GKE Workload Identity Federation for GKE 或機群 Workload Identity Federation for GKE，您可以使用 Google 服務帳戶，授予 Config Sync 權限，允許其存取代管叢集所在專案中的存放區。

1. 如果您還沒有服務帳戶，請建立服務帳戶。

2. 將正確的 IAM 角色授予服務帳戶，以便存取存放區：

   Cloud Source Repositories

   將 Cloud Source Repositories 讀取者 (roles/source.reader) IAM 角色授予 Google 服務帳戶。如要進一步瞭解 Cloud Source Repositories 角色和權限，請參閱「授予查看存放區的權限」。

   • 如果相同權限適用於專案中的所有存放區，請授予專案層級權限。

     gcloud projects add-iam-policy-binding PROJECT_ID \
       --role=roles/source.reader \
       --member="serviceAccount:GSA_NAME@PROJECT_ID.s3ns.iam.gserviceaccount.com"
     

   • 如要讓服務帳戶對專案中的各個存放區擁有不同層級的存取權，請授予存放區專屬權限。

     gcloud source repos set-iam-policy REPOSITORY POLICY_FILE --project=PROJECT_ID
     

   Secure Source Manager

   將 Secure Source Manager 執行個體存取者 (roles/securesourcemanager.instanceAccessor) 和 Secure Source Manager 存放區讀取者 (roles/securesourcemanager.repoReader) IAM 角色授予 Google 服務帳戶。如要進一步瞭解 Secure Source Manager 角色和權限，請參閱「存放區角色管理」。

   • 如果相同權限適用於專案中的所有存放區，請授予專案層級權限。

     gcloud projects add-iam-policy-binding PROJECT_ID \
       --role=roles/securesourcemanager.instanceAccessor \
       --member="serviceAccount:GSA_NAME@PROJECT_ID.s3ns.iam.gserviceaccount.com"
     

     gcloud projects add-iam-policy-binding PROJECT_ID \
       --role=roles/securesourcemanager.repoReader \
       --member="serviceAccount:GSA_NAME@PROJECT_ID.s3ns.iam.gserviceaccount.com"
     

   • 如要授予存放區專屬權限，請使用存放區的 Secure Source Manager 網頁介面。詳情請參閱「授予使用者存放區層級角色」。

3. 如果您使用 Cloud de Confiance 控制台設定 Config Sync，請選取「Workload Identity Federation for GKE」做為「驗證類型」，然後新增服務帳戶電子郵件地址。

   如果您使用 Google Cloud CLI 設定 Config Sync，請將 gcpserviceaccount 新增為 secretType，然後將服務帳戶電子郵件地址新增至 gcpServiceAccountEmail。

4. 如果您使用 Secure Source Manager 中的存放區，請務必在設定 Config Sync 時採用下列格式，並新增 Git 存放區網址：

   https://INSTANCE_ID-PROJECT_NUMBER-git.LOCATION.sourcemanager.dev/PROJECT_ID/REPO_NAME.git
   

   更改下列內容：

   • INSTANCE_ID：Secure Source Manager 執行個體的名稱。
   • PROJECT_ID：執行個體所在 Cloud de Confiance專案的 ID。
   • PROJECT_NUMBER：執行個體所在的 Cloud de Confiance專案編號。
   • LOCATION：執行個體所在的區域。
   • REPO_NAME：存放區名稱。

5. 設定 Config Sync 後，請在 Kubernetes 服務帳戶與 Google 服務帳戶之間建立 IAM 政策繫結。系統會等到您完成 Config Sync 初次設定之後，再建立 Kubernetes 服務帳戶。

   如果您使用的叢集已註冊至機群，則每個機群只需建立一次政策繫結。在機群中註冊的所有叢集，都會共用相同的 Workload Identity Federation for GKE 集區。根據機群的相同性概念，如果您將 IAM 政策新增至某個叢集中的 Kubernetes 服務帳戶，則同一機群中其他叢集上相同命名空間的 Kubernetes 服務帳戶也會取得相同的 IAM 政策。

   有了這個繫結，Config Sync Kubernetes ServiceAccount 即可做為 Google 服務帳戶：

   gcloud iam service-accounts add-iam-policy-binding \
       GSA_NAME@PROJECT_ID.s3ns.iam.gserviceaccount.com \
       --role=roles/iam.workloadIdentityUser \
       --member="serviceAccount:FLEET_HOST_PROJECT_ID.s3ns.svc.id.goog[config-management-system/KUBERNETES_SERVICEACCOUNT]" \
       --project=PROJECT_ID
   

更改下列內容：

• PROJECT_ID：組織的專案 ID。
• FLEET_HOST_PROJECT_ID：如果您使用 GKE Workload Identity Federation for GKE，這與 PROJECT_ID 相同。如果您使用 GKE 適用的機群 Workload Identity Federation，則這是叢集註冊的機群專案 ID。
• GSA_NAME：要用於連線至 Secure Source Manager 或 Cloud Source Repositories 的自訂 Google 服務帳戶。
• KUBERNETES_SERVICEACCOUNT：協調器的 Kubernetes ServiceAccount：
  • 如果是根存放區，且 RootSync 名稱為 root-sync，請使用 root-reconciler。否則，請使用 root-reconciler-ROOT_SYNC_NAME。如果您使用 Cloud de Confiance 控制台或 Google Cloud CLI 安裝 Config Sync，Config Sync 會自動建立名為 root-sync 的 RootSync 物件。
• REPOSITORY：存放區名稱。
• POLICY_FILE：含有 Identity and Access Management 政策的 JSON 或 YAML 檔案。

Compute Engine 預設服務帳戶

如果您的存放區位於 Cloud Source Repositories，且叢集是 GKE，但未啟用 Workload Identity Federation for GKE，則可使用 gcenode 做為驗證類型。

如果您使用 Cloud de Confiance 控制台設定 Config Sync，請選取「Google Cloud Repository」做為「Authentication Type」(驗證類型)。

如果您使用 Google Cloud CLI 設定 Config Sync，請將 gcenode 新增為 secretType。

選取「Google Cloud Repository」或 gcenode，即可使用 Compute Engine 預設服務帳戶。您必須將 Cloud Source Repositories 讀取者 (roles/source.reader) IAM 角色授予 Compute Engine 預設服務帳戶。如要進一步瞭解 Cloud Source Repositories 角色和權限，請參閱「授予查看存放區的權限」。

gcloud projects add-iam-policy-binding PROJECT_ID \
  --role=roles/source.reader \
  --member="serviceAccount:PROJECT_NUMBER-compute@developer.s3ns-system.iam.gserviceaccount.com"

將 PROJECT_ID 替換為貴組織的專案 ID，並將 PROJECT_NUMBER 替換為貴組織的專案編號。

GitHub 應用程式

如果存放區位於 GitHub，可以使用 githubapp 做為驗證類型。

如要使用 GitHub 應用程式，請完成下列步驟：

1. 請按照 GitHub 上的操作說明佈建 GitHub 應用程式，並授予讀取存放區的權限。

2. 將 GitHub 應用程式設定新增至叢集內的新 Secret：

   使用用戶端 ID

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-literal=github-app-client-id=CLIENT_ID \
     --from-literal=github-app-installation-id=INSTALLATION_ID \
     --from-file=github-app-private-key=/path/to/GITHUB_PRIVATE_KEY \
     --from-literal=github-app-base-url=BASE_URL
   

   • 將 CLIENT_ID 替換為 GitHub 應用程式的用戶端 ID。
   • 將 INSTALLATION_ID 替換為 GitHub 應用程式的安裝 ID。
   • 將 /path/to/GITHUB_PRIVATE_KEY 替換為包含私密金鑰的檔案名稱。
   • 將 BASE_URL 替換為 GitHub API 端點的基準網址。只有在存放區並非託管於 www.github.com 時，才需要使用這個引數。否則可以省略，預設值為 https://api.github.com/。

   使用應用程式 ID

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-literal=github-app-application-id=APPLICATION_ID \
     --from-literal=github-app-installation-id=INSTALLATION_ID \
     --from-file=github-app-private-key=/path/to/GITHUB_PRIVATE_KEY \
     --from-literal=github-app-base-url=BASE_URL
   

   • 將 APPLICATION_ID 替換為 GitHub 應用程式的應用程式 ID。
   • 將 INSTALLATION_ID 替換為 GitHub 應用程式的安裝 ID。
   • 將 /path/to/GITHUB_PRIVATE_KEY 替換為包含私密金鑰的檔案名稱。
   • 將 BASE_URL 替換為 GitHub API 端點的基準網址。只有在存放區並非託管於 www.github.com 時，才需要使用這個引數。否則可以省略，預設值為 https://api.github.com/。

3. 將私密金鑰從本機磁碟中刪除或妥善保管。

4. 設定 Config Sync 並新增 Git 存放區網址時，請使用 githubapp 驗證類型。

Kubernetes ServiceAccount

如果 OCI 映像檔儲存在 Artifact Registry，且叢集使用 GKE Workload Identity Federation for GKE 或機群 Workload Identity Federation for GKE，則可使用 Kubernetes ServiceAccount 做為驗證類型。

將專案或存放區的 Artifact Registry 讀取者角色 (roles/artifactregistry.reader) 授予 Kubernetes ServiceAccount。如要進一步瞭解 Artifact Registry 角色和權限，請參閱「設定 Artifact Registry 的角色和權限」。

• 如果相同權限適用於專案中的所有存放區，請授予專案層級權限：

  gcloud projects add-iam-policy-binding PROJECT_ID \
      --role=roles/artifactregistry.reader \
      --member="principal://iam.googleapis.com/projects/FLEET_HOST_PROJECT_NUMBER/locations/global/workloadIdentityPools/FLEET_HOST_PROJECT_ID.s3ns.svc.id.goog/subject/ns/config-management-system/sa/KUBERNETES_SERVICEACCOUNT" \
      --condition=None
  

• 如要讓服務帳戶對專案中的每個存放區具有不同層級的存取權，請授予存放區專屬權限：

  gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
      --location=LOCATION \
      --role=roles/artifactregistry.reader \
      --member="principal://iam.googleapis.com/projects/FLEET_HOST_PROJECT_NUMBER/locations/global/workloadIdentityPools/FLEET_HOST_PROJECT_ID.s3ns.svc.id.goog/subject/ns/config-management-system/sa/KUBERNETES_SERVICEACCOUNT" \
      --project=PROJECT_ID \
      --condition=None
  

更改下列內容：

• PROJECT_ID：組織的專案 ID。
• FLEET_HOST_PROJECT_NUMBER：如果您使用 Workload Identity Federation for GKE，這會與 PROJECT_ID 的專案編號相同。如果您使用 GKE 適用的機群 Workload Identity Federation，則這是叢集註冊的機群專案編號。
• FLEET_HOST_PROJECT_ID：如果您使用 GKE Workload Identity Federation for GKE，這與 PROJECT_ID 相同。如果您使用 GKE 適用的機群 Workload Identity Federation，則這是叢集註冊的機群專案 ID。
• KUBERNETES_SERVICEACCOUNT：協調器的 Kubernetes ServiceAccount：
• 如果是根存放區，且 RootSync 名稱為 root-sync，請使用 root-reconciler。否則，請使用 root-reconciler-ROOT_SYNC_NAME。如果您使用 Cloud de Confiance 控制台或 Google Cloud CLI 安裝 Config Sync，Config Sync 會自動建立名為 root-sync 的 RootSync 物件。
• REPOSITORY：存放區 ID。
• LOCATION：存放區的區域或多區域位置。

Compute Engine 預設服務帳戶

如果您將 OCI 映像檔儲存在 Artifact Registry，且叢集是 GKE，但未啟用 Workload Identity Federation for GKE，則可使用 gcenode 做為驗證類型。Config Sync 會使用 Compute Engine 預設服務帳戶。您必須授予 Compute Engine 預設服務帳戶 Artifact Registry 的讀取權限。

執行下列指令，將 Artifact Registry 的讀取的權限授予 Compute Engine 服務帳戶：

gcloud projects add-iam-policy-binding PROJECT_ID \
   --member=serviceAccount:PROJECT_NUMBER-compute@developer.s3ns-system.iam.gserviceaccount.com \
   --role=roles/artifactregistry.reader

將 PROJECT_ID 替換為貴組織的專案 ID，並將 PROJECT_NUMBER 替換為貴組織的專案編號。

RootSync

1. 擷取用於核發 Git 伺服器憑證的 CA 憑證，並儲存至檔案。

2. 如果是 RootSync 物件，則必須在 config-management-system 命名空間中建立 Secret。例如：

   kubectl create ns config-management-system && 
   
   kubectl create secret generic ROOT_CA_CERT_SECRET_NAME 
   
    --namespace=config-management-system 
   
    --from-file=cert=/path/to/CA_CERT_FILE
   

3. 設定 Config Sync 時，請將 RootSync 物件中 caCertSecretRef.name 欄位的值設為 ROOT_CA_CERT_SECRET_NAME。

RepoSync

1. 擷取用於核發 Git 伺服器憑證的 CA 憑證，並儲存至檔案。

2. 如果是 RepoSync 物件，Secret 必須建立在與 RepoSync 相同的命名空間中。例如：

   kubectl create ns REPO_SYNC_NAMESPACE && 
   
   kubectl create secret generic NAMESPACE_CA_CERT_SECRET_NAME 
   
    --namespace=REPO_SYNC_NAMESPACE 
   
    --from-file=cert=/path/to/CA_CERT_FILE
   

3. 設定 RepoSync 時，請將 RepoSync 物件中 caCertSecretRef.name 欄位的值設為 NAMESPACE_CA_CERT_SECRET_NAME。

權杖

使用 Helm 存放區使用者名稱和密碼建立 Secret：

kubectl create secret generic SECRET_NAME \
    --namespace=config-management-system \
    --from-literal=username=USERNAME \
    --from-literal=password=PASSWORD

更改下列內容：

• SECRET_NAME：要為 Secret 指定的名稱。
• USERNAME：Helm 存放區使用者名稱。
• PASSWORD：Helm 存放區密碼。

設定 Config Sync 時，請使用您為 spec.helm.secretRef.name 選擇的 Secret 名稱。

Kubernetes ServiceAccount

如果將 Helm 圖表儲存在 Artifact Registry，且叢集使用 GKE Workload Identity Federation for GKE 或機群 Workload Identity Federation for GKE，則可使用 Kubernetes ServiceAccount 做為驗證類型。

將專案或存放區的 Artifact Registry 讀取者角色 (roles/artifactregistry.reader) 授予 Kubernetes ServiceAccount。如要進一步瞭解 Artifact Registry 角色和權限，請參閱「設定 Artifact Registry 的角色和權限」。

• 如果相同權限適用於專案中的所有存放區，請授予專案層級權限：

  gcloud projects add-iam-policy-binding PROJECT_ID \
     --role=roles/artifactregistry.reader \
     --member="principal://iam.googleapis.com/projects/FLEET_HOST_PROJECT_NUMBER/locations/global/workloadIdentityPools/FLEET_HOST_PROJECT_ID.s3ns.svc.id.goog/subject/ns/config-management-system/sa/KUBERNETES_SERVICEACCOUNT" \
     --condition=None
  

• 如要讓服務帳戶對專案中的每個存放區具有不同層級的存取權，請授予存放區專屬權限：

  gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
     --location=LOCATION \
     --role=roles/artifactregistry.reader \
     --member="principal://iam.googleapis.com/projects/FLEET_HOST_PROJECT_NUMBER/locations/global/workloadIdentityPools/FLEET_HOST_PROJECT_ID.s3ns.svc.id.goog/subject/ns/config-management-system/sa/KUBERNETES_SERVICEACCOUNT" \
     --project=PROJECT_ID \
     --condition=None
  

更改下列內容：

• PROJECT_ID：組織的專案 ID。
• FLEET_HOST_PROJECT_NUMBER：如果您使用 Workload Identity Federation for GKE，這會與 PROJECT_ID 的專案編號相同。如果您使用 GKE 適用的機群 Workload Identity Federation，則這是叢集註冊的機群專案編號。
• FLEET_HOST_PROJECT_ID：如果您使用 GKE Workload Identity Federation for GKE，這與 PROJECT_ID 相同。如果您使用 GKE 適用的機群 Workload Identity Federation，則這是叢集註冊的機群專案 ID。
• KUBERNETES_SERVICEACCOUNT：協調器的 Kubernetes ServiceAccount：
• 如果是根存放區，且 RootSync 名稱為 root-sync，請使用 root-reconciler。否則，請使用 root-reconciler-ROOT_SYNC_NAME。
• REPOSITORY：存放區 ID。
• LOCATION：存放區的區域或多區域位置。

Compute Engine 預設服務帳戶

如果 Helm 圖表儲存在 Artifact Registry，且叢集是 GKE，但未啟用 Workload Identity Federation for GKE，則可使用 gcenode 做為驗證類型。Config Sync 會使用 Compute Engine 預設服務帳戶。您必須授予 Compute Engine 預設服務帳戶 Artifact Registry 的讀取權限。您可能需要授予 storage-ro 存取權範圍，才能授予唯讀權限來提取映像檔。

將 Artifact Registry 的讀取的權限授予 Compute Engine 服務帳戶：

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:PROJECT_NUMBER-compute@developer.s3ns-system.iam.gserviceaccount.com \
    --role=roles/artifactregistry.reader

將 PROJECT_ID 替換為貴組織的專案 ID，並將 PROJECT_NUMBER 替換為貴組織的專案編號。

nomos (建議)

1. 確認 nomos CLI 為最新版本。

2. 執行下列指令，更新目前 kubectl 內容中的叢集：

   nomos migrate --remove-configmanagement
   

殼層指令碼

將下列殼層指令碼複製到檔案，然後執行指令碼，更新目前 kubectl 內容中的叢集。

 #!/bin/bash

 set -euox pipefail

 hnc_enabled="$(kubectl get configmanagements.configmanagement.gke.io config-management -o=jsonpath="{.spec.hierarchyController.enabled}" --ignore-not-found)"

 if [[ "${hnc_enabled}" == "true" ]]; then
   echo "Hierarchy Controller is enabled on the ConfigManagement object. It must be disabled before migrating."
   echo "This can be done by unsetting the spec.hierarchyController field on ConfigManagement."
   exit 1
 fi

 kubectl delete deployment -n config-management-system config-management-operator --ignore-not-found --cascade=foreground

 if kubectl get configmanagement config-management &> /dev/null ; then
   kubectl patch configmanagement config-management --type="merge" -p '{"metadata":{"finalizers":[]}}'
   kubectl delete configmanagement config-management --cascade=orphan --ignore-not-found
 fi

 kubectl delete clusterrolebinding config-management-operator --ignore-not-found
 kubectl delete clusterrole config-management-operator --ignore-not-found
 kubectl delete serviceaccount -n config-management-system config-management-operator --ignore-not-found
 kubectl delete customresourcedefinition configmanagements.configmanagement.gke.io --ignore-not-found