從 Policy Controller 遷移

Autopilot Standard

本文說明如何從 Policy Controller 遷移准入政策，降低政策執行出現落差的風險。Policy Controller 已於 2026 年 11 月 12 日淘汰，並將於 2027 年 12 月 31 日終止支援。1.39 以上版本中，Google Kubernetes Engine (GKE) 叢集不支援 Policy Controller。

您可以使用 Policy Controller，將強制執行的許可政策遷移至 Kubernetes ValidatingAdmissionPolicies，或自行管理的 Open Policy Agent (OPA) Gatekeeper。遷移作業不會影響已在執行的工作負載。Policy Controller 會評估建立或更新資源的要求，因此移除這項工具不會重新啟動或變更執行中的工作負載。

本文適用於管理整個機群 Policy Controller 的操作人員和資安專家。如要進一步瞭解Google Cloud 內容中提及的常見角色和工作範例，請參閱「常見的 GKE 使用者角色和工作」。

無法升級至 GKE 1.39 版

如果叢集已安裝 Policy Controller，GKE 會禁止升級至 1.39 以上版本。將叢集升級至 1.39 版前，請先遷移政策，並從該叢集移除 Policy Controller。請勿在遷移政策前，為了升級而移除 Policy Controller，否則叢集將無法強制執行政策。

選擇替換相片

評估 Policy Controller 中的各項准入政策，並從下表選擇該政策的替代選項。您不必為整個叢集選擇單一替代方案。您可以根據各項政策的需求，在同一個叢集上合併使用多個選項：

Policy Controller 替代方案比較

選項	使用時機	營運與支援
ValidatingAdmissionPolicy (建議)	在建立或更新單一資源時，檢查該資源的政策。Policy Controller 範本庫中的大多數範本都採用這種運作方式。	ValidatingAdmissionPolicies 內建於 Kubernetes，適用於 GKE 1.30 以上版本，不需額外付費。Cloud Customer Care 支援 ValidatingAdmissionPolicies，做為 GKE 的一部分。
Pod 安全性許可 (建議用於 Pod 安全性套件)	pss-baseline-v2022、pss-restricted-v2022 或 psp-v2022 套件中預先定義的 Pod 安全性控管機制。詳情請參閱「使用 Pod 安全性許可功能管理 Pod 安全性套裝組合」。	Pod 安全性許可內建於 Kubernetes，並在 GKE 中預設啟用，不需額外付費。客戶服務支援 Pod 安全性許可，做為 GKE 的一部分。
自行管理的 OPA Gatekeeper	ValidatingAdmissionPolicies 無法表達的政策，例如讀取叢集中其他資源的參照政策、您想保留在 Rego 中的政策，以及現有資源的稽核。您也可以將一般運算語言 (CEL) 規則新增至 Gatekeeper ConstraintTemplates，讓 Gatekeeper 產生 ValidatingAdmissionPolicies，以便強制執行 API 伺服器，並讓稽核控制器檢查現有資源。	您需要安裝、升級及操作 Gatekeeper。客戶服務不支援開放原始碼 Gatekeeper。Gatekeeper 社群透過 GitHub 提供支援。

盤點及分類政策

根據預設，Policy Controller 範本庫會安裝所有範本，而政策套裝組合會安裝限制，並採取 dryrun 違規處置。因此，叢集上的範本和限制不一定符合您強制執行的政策。如要瞭解強制執行的項目，請按照下列步驟操作：

1. 找出機群中執行 Policy Controller 的叢集：

   gcloud container fleet policycontroller describe \
       --project=PROJECT_ID
   

   將 PROJECT_ID 替換為機群主專案的 ID。

   注意：您可能有執行 Policy Controller 的叢集不屬於任何機群，例如使用 ConfigManagement Operator 安裝 Policy Controller 的叢集，或從機群取消註冊但未解除安裝 Policy Controller 的叢集。這些叢集不會顯示在上述指令的輸出內容中。如要確認叢集是否執行 Policy Controller，請參閱「查看 Policy Controller 版本」。如要從這些叢集移除 Policy Controller，請參閱「從機群外的叢集移除 Policy Controller」。

2. 在您找出的每個叢集上，列出限制：

   kubectl get constraints \
       -o custom-columns='KIND:.kind,NAME:.metadata.name,'\
   'ACTION:.spec.enforcementAction,VIOLATIONS:.status.totalViolations,'\
   'BUNDLE:.metadata.labels.policycontroller\.gke\.io/bundleName'
   

   輸出內容會顯示每項限制的違規處置、最近一次稽核的違規次數，以及安裝該限制的所有套件。如果限制在 ACTION 欄中沒有值，則會使用預設的 deny 違規處置。

3. 將 ConstraintTemplates 和限制備份至個別檔案：

   kubectl get constrainttemplates -o yaml \
       > policy-controller-templates-backup.yaml
   kubectl get constraints -o yaml \
       > policy-controller-constraints-backup.yaml
   

4. 選用：執行下列其他備份作業：

   • 如果您在 Policy Controller 中啟用了參照規則，請備份同步設定：

     kubectl get config.config.gatekeeper.sh -n gatekeeper-system -o yaml \
         > policy-controller-config-backup.yaml
     

   • 如果您在 Policy Controller 中啟用了變動功能，請備份變動器：

     kubectl get assign,assignmetadata,assignimage,modifyset -o yaml \
         > policy-controller-mutators-backup.yaml
     

請將這些備份檔案存放在安全的地方。移除 Policy Controller 會刪除叢集上的所有 ConstraintTemplate、限制、同步設定和變異器，包括您建立的項目。您需要備份才能轉換或重新建立政策。

備份政策後，請查看下表中的限制類型，判斷各項限制的遷移路徑：

依限制類型劃分的遷移路徑

限制類型	遷移路徑
單一資源限制	如果限制只會評估傳入資源的欄位，不會讀取 data.inventory，也不屬於 Pod 安全性套件，請使用 ValidatingAdmissionPolicy。
未強制執行的 dryrun 限制	如果限制使用 dryrun 違規處置動作，而您不打算強制執行，請刪除該限制。
Pod 安全性套件限制	如果限制來自 pss-baseline-v2022、pss-restricted-v2022 或 psp-v2022 套裝組合，請使用 Pod 安全性許可。對於 Pod 安全性許可未涵蓋的任何控制項，請使用 ValidatingAdmissionPolicies。
參照限制	如果限制使用參照範本，讀取叢集中的其他資源，請使用自行管理的 Gatekeeper。如要尋找參照範本，請在備份檔案中搜尋 data.inventory 參照。
Cloud Service Mesh、Istio 或 Google Cloud 限制	請個別檢查限制，確認是否有內建 GKE 功能取代政策，或備份檔案中的 ConstraintTemplate 是否讀取 data.inventory。這些範本大多只會檢查傳入的資源，並在 ValidatingAdmissionPolicies 中運作，但參照 AsmAuthzPolicyDefaultDeny 和 AsmPeerAuthnMeshStrictMtls 範本除外，這類範本需要自行管理的 Gatekeeper。如要使用內建替代方案，請啟用二進位授權，而非使用 K8sRequireBinAuthZ ConstraintTemplate，並設定節點集區的節點映像檔，而非使用 K8sRequireCosNodeImage ConstraintTemplate。

遷移至 ValidatingAdmissionPolicy

ValidatingAdmissionPolicy 包含政策邏輯，例如 ConstraintTemplate。ValidatingAdmissionPolicyBinding 會套用政策，就像限制一樣。ValidatingAdmissionPolicy 使用 CEL 運算式而非 Rego，API 伺服器會直接評估運算式，不需使用 Webhook。

範例：允許的映像檔存放區

下列 Policy Controller 限制規定 Pod 必須使用來自一個 Artifact Registry 存放區的映像檔。排除 kube-system 命名空間：

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepos
metadata:
  name: allowed-repos
spec:
  enforcementAction: deny
  match:
    kinds:
    - apiGroups: [""]
      kinds: ["Pod"]
    excludedNamespaces: ["kube-system"]
  parameters:
    repos:
    - "us-docker.pkg.dev/example-project/example-repo/"

下列 ValidatingAdmissionPolicy 和 ValidatingAdmissionPolicyBinding 會強制執行相同規則。ValidatingAdmissionPolicyBinding 會使用 Warn 和 Audit 動作，讓您在強制執行 ValidatingAdmissionPolicy 之前比較結果：

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: allowed-repos
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      operations: ["CREATE", "UPDATE"]
      resources: ["pods", "pods/ephemeralcontainers"]
  variables:
  - name: repos
    expression: "['us-docker.pkg.dev/example-project/example-repo/']"
  - name: images
    expression: >-
      object.spec.containers.map(c, c.image) +
      (has(object.spec.initContainers) ?
        object.spec.initContainers.map(c, c.image) : []) +
      (has(object.spec.ephemeralContainers) ?
        object.spec.ephemeralContainers.map(c, c.image) : [])
  validations:
  - expression: >-
      variables.images.all(image,
        variables.repos.exists(repo, image.startsWith(repo)))
    messageExpression: >-
      'container images must come from one of these repositories: ' +
      variables.repos.join(', ')
    reason: Forbidden
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: allowed-repos
spec:
  policyName: allowed-repos
  validationActions: ["Warn", "Audit"]
  matchResources:
    namespaceSelector:
      matchExpressions:
      - key: kubernetes.io/metadata.name
        operator: NotIn
        values: ["kube-system", "gatekeeper-system"]

在本例中，repos 變數會保留限制條件 parameters 欄位的值。驗證運算式會針對符合 ValidatingAdmissionPolicy 的 Pod 傳回 true 值，這與 Rego 違規規則相反。如要在多個提供不同值的 ValidatingAdmissionPolicyBinding 中重複使用同一個 ValidatingAdmissionPolicy，請使用參數資源，而非變數。如要進一步瞭解參數資源，請參閱 Kubernetes 說明文件中的「參數資源」。

下表顯示限制欄位如何對應至 ValidatingAdmissionPolicy 和 ValidatingAdmissionPolicyBinding 欄位：

Policy Controller 限制欄位與 ValidatingAdmissionPolicy 和 ValidatingAdmissionPolicyBinding 欄位的對應關係

限制欄位	ValidatingAdmissionPolicy 或 ValidatingAdmissionPolicyBinding 欄位
spec.enforcementAction	ValidatingAdmissionPolicyBinding 中的 validationActions 欄位，會將 deny、warn 和 dryrun 動作對應至 ["Deny"]、["Warn"] 和 ["Audit"] 值
spec.parameters	ValidatingAdmissionPolicy 中的 variables 欄位，或 ValidatingAdmissionPolicyBinding 在 paramRef 欄位中參照的參數資源
spec.match.kinds	ValidatingAdmissionPolicy 中的 matchConstraints.resourceRules 欄位，使用 API 群組和資源名稱 (例如 pods 資源)，而非種類
spec.match.namespaces和spec.match.excludedNamespaces	ValidatingAdmissionPolicyBinding 中的 matchResources.namespaceSelector 欄位，在 kubernetes.io/metadata.name 標籤上使用 In 或 NotIn 運算子
spec.match.labelSelector	ValidatingAdmissionPolicyBinding 中的 matchResources.objectSelector 欄位
spec.match.namespaceSelector	ValidatingAdmissionPolicyBinding 中的 matchResources.namespaceSelector 欄位
spec.match.scope	每個資源規則的 scope 欄位

如要進一步瞭解如何編寫運算式，請參閱 Kubernetes 說明文件中的「Kubernetes 中的 CEL」。

搭配 Policy Controller 測試政策

如要取代限制，且不中斷強制執行，請在強制執行 ValidatingAdmissionPolicy 之前，先在限制旁執行 ValidatingAdmissionPolicy：

1. 套用 ValidatingAdmissionPolicy 和具有 validationActions: ["Warn", "Audit"] 設定的 ValidatingAdmissionPolicyBinding。保留 Policy Controller 限制。
2. 使用「取代違規回報」中的稽核記錄查詢，比較結果。如果 ValidatingAdmissionPolicy 標記了 Policy Controller 允許的要求，或反之，請修正 ValidatingAdmissionPolicy。對於與 Pod 相符的 ValidatingAdmissionPolicies，請勿依賴警告。控制器會為 Deployment 和其他工作負載建立 Pod，因此控制器會收到警告。
3. 結果相符後，請變更 ValidatingAdmissionPolicyBinding，改用 validationActions: ["Deny"] 設定。
4. 刪除 Policy Controller 限制。

規劃行為差異

ValidatingAdmissionPolicies 與 Policy Controller 的運作方式有下列差異，可能會導致要求遭到封鎖，或是在強制執行時出現漏洞：

• 失敗政策：Policy Controller Webhook 失敗時仍開放，也就是說，如果 Policy Controller 沒有回應，API 伺服器會接受要求。如果運算式傳回錯誤或超過 CEL 費用限制，具有 failurePolicy: Fail 設定的 ValidatingAdmissionPolicy 會拒絕要求。如果參照的參數資源不存在，且 ValidatingAdmissionPolicyBinding 中 paramRef.parameterNotFoundAction 欄位的值為 Deny，ValidatingAdmissionPolicy 也會拒絕要求。如果值為 Allow，則無論 failurePolicy 設定為何，API 伺服器都會略過缺少的參數資源。測試每個 ValidatingAdmissionPolicy，並為這兩個欄位選擇值。
• 缺少欄位：Rego 會將缺少欄位視為未違規，但 CEL 會傳回錯誤。讀取選用欄位前，請使用 has() 巨集檢查欄位是否存在。
• 豁免：ValidatingAdmissionPolicy 預設不會豁免命名空間，也不會使用 admission.gatekeeper.sh/ignore 標籤。在 GKE Standard 叢集中，ValidatingAdmissionPolicyBinding 會套用至叢集中的每個命名空間，包括 kube-system 命名空間等系統命名空間，除非您在 ValidatingAdmissionPolicyBinding 的 matchResources.namespaceSelector 欄位，或 ValidatingAdmissionPolicy 的 matchConstraints.namespaceSelector 或 matchConditions 欄位中排除這些命名空間。在 Autopilot 叢集上，GKE 會自動排除代管命名空間，並拒絕與 nodes、persistentVolumes、certificatesigningrequests 或 tokenreviews 資源相符的 ValidatingAdmissionPolicies。詳情請參閱「GKE Autopilot 安全措施」。
• 子資源：Policy Controller 會檢查新增臨時容器的 Pod 更新。如要維持該涵蓋範圍，請在資源規則中加入 pods/ephemeralcontainers 子資源，如範例所示。
• 不稽核現有資源：ValidatingAdmissionPolicy 只會評估傳入的 API 伺服器要求，不會回報違反 ValidatingAdmissionPolicy 的現有資源。
• 每項要求一則訊息：ValidatingAdmissionPolicy 會回報第一個失敗的驗證，而非所有違規事項。

使用 Pod 安全性許可，為 Pod 建立安全性套裝組合

如果您使用 pss-baseline-v2022 或 pss-restricted-v2022 套件，請將套件替換為 Pod 安全性許可，而不是轉譯每項限制。Pod 安全性許可會使用內建的 Kubernetes PodSecurity 許可控制器，根據命名空間標籤強制執行 Kubernetes Pod 安全性標準中的預先定義規則。pss-baseline-v2022 套件對應 baseline 級別，pss-restricted-v2022 套件對應 restricted 級別。

Pod 安全性許可不涵蓋 psp-v2022 套件中的所有控制項，例如主機路徑、使用者、功能和 sysctl 的許可清單。請使用 ValidatingAdmissionPolicies 控管。Pod 安全性許可也無法豁免特定映像檔，例如使用 exemptImages 參數的 Policy Controller 限制。GKE 不支援設定 Pod 安全性許可豁免。如需例外狀況，請針對受影響的政策使用 ValidatingAdmissionPolicies。

如要進一步瞭解如何設定 Pod 安全性許可，請參閱「使用 PodSecurity 套用預先定義的 Pod 層級安全性政策」。

遷移至自行管理的 OPA Gatekeeper

如果 ValidatingAdmissionPolicies 無法表達政策，請選擇 Gatekeeper。Policy Controller 以 Gatekeeper 為基礎，因此 ConstraintTemplates 和限制會使用 Gatekeeper 中的相同 API。Policy Controller 範本庫中的所有範本都可在 Gatekeeper 中運作，不需變更邏輯。不過，Gatekeeper 使用較新的 Rego 引擎和更嚴格的驗證，可能會拒絕自訂 ConstraintTemplate。

使用自行管理的 Gatekeeper 時，您必須負責Google Cloud 為 Policy Controller 執行的工作，例如在各個叢集上安裝、升級、擴充及監控 Gatekeeper。客戶服務不支援開放原始碼 Gatekeeper。如需協助，請使用 Gatekeeper GitHub Issue Tracker。

Gatekeeper 不含 Policy Controller 範本庫或政策套件。備份檔案包含叢集的 ConstraintTemplates 和限制。如果範本源自開放原始碼 Gatekeeper 程式庫，您可以使用 Gatekeeper 政策庫中的範本。範本名稱保持不變，但參數和訊息可能因版本而異。

如要將政策移至 Gatekeeper，請按照下列步驟操作：

1. 選用：如果無法接受在更換 Policy Controller 時出現強制執行空窗期，請先將最重要的政策遷移至 ValidatingAdmissionPolicies。請確認這些 ValidatingAdmissionPolicyBindings 排除 gatekeeper-system 命名空間，以免封鎖 Gatekeeper 安裝工作。移除 Policy Controller 後，叢集會停止強制執行 Gatekeeper 政策，直到您套用對應的 Gatekeeper 限制為止。ValidatingAdmissionPolicies 不依賴 Policy Controller 或 Gatekeeper，因此會繼續強制執行。

2. 如果您使用自訂 ConstraintTemplate，請透過預計安裝的 Gatekeeper 版本，使用 gator 指令列工具測試各個自訂範本資訊清單：

   gator test --filename=TEMPLATE_FILE
   

   將 TEMPLATE_FILE 替換為 ConstraintTemplate 資訊清單檔案的路徑。移除 Policy Controller 之前，請先修正 Gatekeeper 拒絕的所有自訂 ConstraintTemplate。

3. 如果您使用 GitOps 工具從 Git 存放區部署限制，請準備限制使用的 ConstraintTemplates，並在安裝 Gatekeeper 時將其新增至存放區。否則，移除 Policy Controller 後，限制會因 ConstraintTemplates 不存在而無法套用。

4. 按照「移除 Policy Controller」中的步驟移除 Policy Controller。請勿在仍執行 Policy Controller 的叢集上安裝 Gatekeeper。兩者都使用 gatekeeper-system 命名空間、相同的 CustomResourceDefinitions 和相同的 Webhook 名稱。

5. 使用 Helm 安裝 Gatekeeper，並採用下一節「與 Policy Controller 不同的 Gatekeeper 設定」表格中選擇的設定。如要進一步瞭解如何安裝 Gatekeeper，請參閱 Gatekeeper 說明文件中的「安裝」一節。

   在 Autopilot 叢集上，預設的 Helm 圖表安裝作業會失敗，因為 GKE 會拒絕變更 Webhook 中的萬用字元規則。設定 disableMutation: true Helm 值，或設定 mutatingWebhookCustomRules Helm 值，僅列出變動器指定的特定資源。請勿加入 nodes、persistentvolumes、certificatesigningrequests 或 tokenreviews 資源。

6. 在備份檔案中，從您打算重新套用的各項資源中移除下列欄位、標籤和註解：

   • status 欄位。
   • metadata 區段中的 resourceVersion、uid、creationTimestamp、generation、managedFields 和 ownerReferences 欄位。
   • kubectl.kubernetes.io/last-applied-configuration 註解。
   • app.kubernetes.io/managed-by: anthospolicycontroller.googleapis.com 標籤。如果再次在叢集上啟用 Policy Controller (例如透過機群層級預設設定)，則會管理具有這個標籤的資源，並可修改或刪除這些資源。
   • 鍵具有 policycontroller. 前置字元的標籤和註解。

7. 套用限制使用的 ConstraintTemplates，然後檢查 Gatekeeper 是否為每個範本建立 CustomResourceDefinition：

   kubectl get constrainttemplates \
       -o custom-columns='NAME:.metadata.name,CREATED:.status.created'
   

   當每個範本的 CREATED 欄都顯示 true 值時，請套用限制。

與 Policy Controller 不同的 Gatekeeper 設定

安裝 Gatekeeper 前，請先查看下表中的設定，瞭解 Gatekeeper Helm 圖表預設值與 Policy Controller 的差異：

的比較

Policy Controller 預設值和 Gatekeeper Helm 圖表 預設值

設定	Policy Controller 預設	Gatekeeper Helm 資訊套件預設值	建議
突變	除非你開啟，否則預設為關閉	開啟	如果不使用變異，請設定 disableMutation: true Helm 值。在 Autopilot 叢集上，您必須設定 disableMutation: true Helm 值，或設定不含萬用字元或受限資源的 mutatingWebhookCustomRules Helm 值。如未指定其中一個值，GKE 會拒絕安裝。
豁免命名空間	gatekeeper-system 命名空間和 exemptableNamespaces 清單中的命名空間	安裝 Gatekeeper 的命名空間	將豁免的命名空間新增至 controllerManager.exemptNamespaces Helm 值。Gatekeeper 會拒絕變更具有 admission.gatekeeper.sh/ignore 標籤的命名空間，除非這些命名空間符合豁免條件。
參照資料	自動同步參照套裝組合	未同步處理	建立 Gatekeeper 設定或 SyncSet，列出參照範本讀取的種類。在這些種類同步至 data.inventory 物件之前，衝突檢查會允許違規要求，而存在檢查 (例如 K8sRequireNamespaceNetworkPolicies ConstraintTemplate) 則會拒絕每個相符的要求，即使所需資源存在也一樣。
ValidatingAdmissionPolicy 產生	無法使用	為含有 CEL 程式碼的範本啟用	Policy Controller 範本僅包含 Rego，因此只有在您將 CEL 新增至 ConstraintTemplates 時，Gatekeeper 才會產生 ValidatingAdmissionPolicies。如要在 Webhook 中保留強制執行功能，請設定 defaultCreateVAPForTemplates: false 和 defaultCreateVAPBindingForConstraints: false Helm 值。詳情請參閱 Gatekeeper 說明文件中的「與 Kubernetes 驗證准入政策整合」一節。
副本和資源	每個元件一個副本，記憶體限制為 1,024 MiB	三個 Webhook 副本，資源限制各不相同	根據目前用量設定副本數量和資源限制。
圖片	從 Google 代管的登錄檔提取	從 Docker Hub 提取 (openpolicyagent/gatekeeper、openpolicyagent/gatekeeper-crds 和 curlimages/curl 映像檔)	如果是私人叢集或強制執行二進位授權的叢集，請將這三個映像檔全部鏡像至 Artifact Registry，並覆寫圖表中的映像檔值。如果您未鏡像 curlimages/curl 映像檔，請停用 Webhook 探測工作。

根據預設，Gatekeeper 只會公開 Prometheus 指標，且其指標名稱與 Policy Controller 傳送至 Cloud Monitoring 的名稱不同。更新所有使用 Policy Controller 指標的資訊主頁和警告。

遷移變動政策

如果您在 Policy Controller 啟用了變動功能，請列出變動器：

kubectl get assign,assignmetadata,assignimage,modifyset

請為每個變異器選擇下列其中一個選項：

• MutatingAdmissionPolicy：您可以在 GKE 1.36 以上版本使用 MutatingAdmissionPolicy。與 ValidatingAdmissionPolicy 相同，MutatingAdmissionPolicy 使用 CEL 運算式，並在 API 伺服器中執行，不需使用 Webhook。Kubernetes 會先執行所有 MutatingAdmissionPolicy，再執行 ValidatingAdmissionPolicy，因此請一併測試兩者，確保變更不會導致 ValidatingAdmissionPolicy 拒絕有效的資訊清單。在 Autopilot 叢集中，GKE 會將代管命名空間從 MutatingAdmissionPolicies 排除。如要進一步瞭解變更政策，請參閱 Kubernetes 說明文件中的「變更准入政策」。
• 自行管理的 Gatekeeper：在標準叢集上，您的變動器不需變更即可運作，因為 Gatekeeper 預設會啟用變動功能。在 Autopilot 叢集上，您必須在 Gatekeeper 圖表中設定 mutatingWebhookCustomRules Helm 值，列出變動器指定的特定資源，而非萬用字元規則。詳情請參閱「GKE Autopilot 安全措施」。安裝 Gatekeeper 後，請從變動器備份檔案中移除 Policy Controller 中繼資料，並重新套用變動器，就像處理限制一樣。

更新建構管道中的政策檢查

建構管道可能會在部署前，根據 Policy Controller 限制檢查資訊清單。舉例來說，管道可能會使用 kpt 中的 gatekeeper 函式或 gator 指令列工具。詳情請參閱「在 CI 管道中依據公司政策驗證應用程式」。

如果管道會檢查資訊清單，請更新管道，以便進行替換：

• 如果您使用 Gatekeeper，則可以保留管道。更新 gator 或 kpt 指令中的檔案或目錄路徑，參照含有已清理 Gatekeeper ConstraintTemplate 和限制資訊清單的存放區或目錄。

• 如果您使用 ValidatingAdmissionPolicies，這些工具就不會評估您的政策。請改為對測試叢集執行伺服器端模擬測試，該叢集應包含使用 Deny 動作的 ValidatingAdmissionPolicies 和 ValidatingAdmissionPolicyBindings：

  kubectl apply --dry-run=server -f MANIFEST_DIRECTORY
  

  將 MANIFEST_DIRECTORY 替換為資訊清單所在的目錄。如果 ValidatingAdmissionPolicy 拒絕資訊清單，指令就會失敗。

取代違規檢舉

ValidatingAdmissionPolicy 不含資訊主頁，也不會稽核叢集中現有的資源。請改用下列方法：

• 警告：如果 ValidatingAdmissionPolicyBinding 使用 Warn 動作，API 伺服器會向傳送要求的用戶端 (例如 kubectl 指令列工具) 傳回警告。如果是控制器建立的 Pod (例如 Deployment 中的 Pod)，控制器會收到警告。

• 稽核記錄：如果 ValidatingAdmissionPolicyBinding 使用 Audit 動作，API 伺服器會為每個失敗的驗證加上稽核記錄項目註解。GKE 會將建立、更新和刪除要求寫入 Cloud Logging 的管理員活動稽核記錄。如要找出失敗的驗證，請在 Logs Explorer 中執行下列查詢：

  resource.type="k8s_cluster"
  logName:"cloudaudit.googleapis.com%2Factivity"
  labels."validation.policy.admission.k8s.io/validation_failure":*
  

如果您使用的限制條件是以 dryrun 違規處置 做為現有資源的法規遵循報告，ValidatingAdmissionPolicies 無法取代該報告。請將這些政策保留在自行管理的 Gatekeeper 上，其稽核控制器會定期檢查現有資源。

移除 Policy Controller

從叢集移除 Policy Controller 之前，請先完成下列工作：

• 確認已強制執行遷移至 ValidatingAdmissionPolicies 或 Pod 安全性許可的政策，且 ConstraintTemplates、限制和變動器皆有備份。移除 Policy Controller 會刪除其 CustomResourceDefinitions，進而刪除叢集上的所有 ConstraintTemplate、限制和變異器，包括您建立的項目。
• 如果您使用 Config Sync 或 Argo CD 等 GitOps 工具，從 Git 存放區部署限制，請從存放區中移除已取代的限制。確認已從叢集移除限制。
• 選用：如要確認沒有任何項目依附於 Policy Controller Webhook，請先暫停 Policy Controller。暫停只會移除 Webhook 設定，您可以還原這些設定。

如要移除 Policy Controller，請按照下列步驟操作：

1. 從叢集解除安裝 Policy Controller：

   gcloud container fleet policycontroller disable \
       --memberships=MEMBERSHIP_NAME \
       --project=PROJECT_ID
   

   更改下列內容：

   • MEMBERSHIP_NAME：要解除安裝 Policy Controller 的已註冊叢集成員名稱。如要從多個叢集解除安裝 Policy Controller，請指定以逗號分隔的成員資格名稱清單，或將 --memberships=MEMBERSHIP_NAME 旗標替換為 --all-memberships 旗標。
   • PROJECT_ID：機群主機專案的 ID。

2. 確認 Policy Controller 已從叢集解除安裝：

   gcloud container fleet policycontroller describe \
       --memberships=MEMBERSHIP_NAME \
       --project=PROJECT_ID \
       --format="yaml(membershipStates)"
   

   請等待每個成員資格的頂層 policycontroller.state 欄位值變為 NOT_INSTALLED，而非 DECOMMISSIONING。個別 componentStates 項目會在 CustomResourceDefinition 清理完成前達到 NOT_INSTALLED 狀態。

   如果您打算安裝自行管理的 Gatekeeper，請確認 gatekeeper-system 命名空間已不存在：

   kubectl get namespace gatekeeper-system
   

   請等到輸出內容回報找不到 gatekeeper-system 命名空間。

3. 選用：如要避免日後註冊的叢集取得 Policy Controller，請移除機群層級預設設定：

   gcloud container fleet policycontroller enable \
       --no-fleet-default-member-config \
       --project=PROJECT_ID
   

   這個指令只會移除預設設定。不會在任何叢集安裝 Policy Controller。

注意：在 Policy Controller 完成解除安裝前，請勿刪除 Policy Controller 機群功能或取消註冊叢集。否則，Policy Controller 會繼續在叢集上執行，但不會受到管理。請勿使用 gcloud container fleet policycontroller detach 指令移除 Policy Controller，因為該指令會停止管理，並讓 Policy Controller 繼續執行。

從機群外的叢集移除 Policy Controller

gcloud container fleet policycontroller disable 指令只會從機群管理的叢集中移除 Policy Controller。在下列情況下，叢集可以執行 Policy Controller，而不必啟用機群管理功能：

• 您已使用 ConfigManagement Operator 安裝 Policy Controller。
• 在 Policy Controller 完成解除安裝前，您已從機群取消註冊叢集，或執行 gcloud container fleet policycontroller detach 指令。

如要從這些叢集移除 Policy Controller，請將叢集納入機群管理，然後解除安裝 Policy Controller：

1. 按照「盤點及分類政策」一文所述，備份 ConstraintTemplate、限制、同步設定和變動器。從 ConfigManagement Operator 安裝作業建立的備份中清除中繼資料時，除了 ownerReferences 欄位和 policycontroller.* 中繼資料外，也請移除 configmanagement.gke.io/* 和 k8s-app: kubernetes-config-management 標籤。

2. 如果您是使用 ConfigManagement Operator 安裝 Policy Controller，請從叢集上的 ConfigManagement 自訂資源中移除 policyController 欄位。等待對帳完成。 協調作業大約需要兩分鐘。接著，檢查 gatekeeper-system 命名空間是否仍存在：

   kubectl get namespace gatekeeper-system
   

   在 ConfigManagement Operator 1.17 版和更早版本中，移除 policyController 欄位會自動解除安裝 Policy Controller。如果找不到 gatekeeper-system 命名空間，請略過本節的其餘步驟。在 ConfigManagement Operator 1.18 以上版本中，gatekeeper-system 命名空間會保留在叢集上，因此請繼續執行下一個步驟。

3. 如果叢集未註冊至機群，請先註冊。詳情請參閱「將 Google Cloud 上的叢集註冊至機群」。

4. 檢查叢集是否已啟用變動功能：

   kubectl get mutatingwebhookconfiguration \
       gatekeeper-mutating-webhook-configuration
   

5. 在叢集的成員資格上啟用 Policy Controller，讓機群接管現有安裝項目的管理作業。如果上述指令傳回 gatekeeper-mutating-webhook-configuration 資源，請加入 --mutation 旗標，讓機群採用並在之後移除叢集範圍的變動資源：

   gcloud container fleet policycontroller enable \
       --memberships=MEMBERSHIP_NAME \
       --project=PROJECT_ID
   

   更改下列內容：

   • MEMBERSHIP_NAME：已註冊叢集的成員資格名稱。
   • PROJECT_ID：機群主機專案的 ID。

6. 請等待成員資格的 policycontroller.state 欄位值變成 ACTIVE：

   gcloud container fleet policycontroller describe \
       --memberships=MEMBERSHIP_NAME \
       --project=PROJECT_ID \
       --format="yaml(membershipStates)"
   

7. 按照「移除 Policy Controller」中的步驟，解除安裝 Policy Controller。如果您不打算安裝自行管理的 Gatekeeper，請在移除 gatekeeper-system 命名空間後，刪除所有剩餘的限制 CustomResourceDefinitions：

   kubectl get crd -o name \
       | grep '\.constraints\.gatekeeper\.sh$' \
       | xargs -r kubectl delete
   

8. 選用：如果您註冊叢集只是為了完成這項程序，請在 describe 指令顯示成員資格的 NOT_INSTALLED 狀態後，取消註冊叢集。如果您是使用 --enable-fleet 旗標註冊叢集，請執行 gcloud container clusters update 指令並加上 --clear-fleet-project 旗標，而非 gcloud container fleet memberships unregister 指令。詳情請參閱「取消註冊叢集」。

後續步驟

• 請參閱 Kubernetes 說明文件中的驗證許可政策。
• 瞭解如何使用 PodSecurity 套用預先定義的 Pod 層級安全性政策。
• 請參閱 Gatekeeper 說明文件。