Esegui la migrazione da Policy Controller

Questo documento spiega come eseguire la migrazione delle policy di ammissione da Policy Controller per ridurre il rischio di lacune nell'applicazione delle policy. Policy Controller è deprecato dal 12 novembre 2026 e il supporto terminerà il 31 dicembre 2027. Nella versione 1.39 e successive, i cluster Google Kubernetes Engine (GKE) non supportano Policy Controller.

Puoi eseguire la migrazione delle policy di ammissione che applichi utilizzando Policy Controller ai ValidatingAdmissionPolicies di Kubernetes o a Open Policy Agent (OPA) Gatekeeper autogestito. La migrazione non influisce sui workload già in esecuzione. Policy Controller valuta le richieste di creazione o aggiornamento delle risorse, pertanto la sua rimozione non riavvia né modifica i workload in esecuzione.

Questo documento è rivolto agli operatori e agli esperti di sicurezza che gestiscono Policy Controller in un parco risorse. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti diGoogle Cloud , consulta Ruoli e attività comuni degli utenti GKE.

Upgrade alla versione 1.39 di GKE bloccati

GKE blocca gli upgrade alla versione 1.39 e successive per i cluster in cui è installato Policy Controller. Prima di eseguire l'upgrade di un cluster alla versione 1.39, esegui la migrazione delle policy e rimuovi Policy Controller dal cluster. Non rimuovere Policy Controller solo per sbloccare l'upgrade prima di eseguire la migrazione delle policy, perché in questo modo il cluster rimane senza applicazione delle policy.

Scegli un prodotto sostitutivo

Valuta ogni policy di ammissione in Policy Controller e scegli un'opzione sostitutiva per la policy dalla tabella seguente. Non è necessario scegliere un'unica sostituzione per un intero cluster. Puoi combinare le opzioni sullo stesso cluster in base ai requisiti di ciascuna policy:

Confronto delle opzioni di sostituzione di Policy Controller
Opzione Quando utilizzarlo Funzionamento e assistenza
ValidatingAdmissionPolicy (consigliato) Policy che controllano una singola risorsa quando viene creata o aggiornata. La maggior parte dei modelli nella libreria di modelli di Policy Controller funziona in questo modo. I criteri ValidatingAdmissionPolicy sono integrati in Kubernetes e disponibili in GKE versione 1.30 e successive senza costi aggiuntivi. L'assistenza clienti Google Cloud supporta ValidatingAdmissionPolicies nell'ambito di GKE.
Pod Security Admission (consigliato per i bundle di sicurezza dei pod) Controlli di sicurezza dei pod predefiniti dal bundle pss-baseline-v2022, pss-restricted-v2022 o psp-v2022. Per saperne di più, consulta Utilizza Pod Security Admission per i bundle di sicurezza dei pod. Pod Security Admission è integrato in Kubernetes e abilitato per impostazione predefinita in GKE senza costi aggiuntivi. L'assistenza clienti supporta Pod Security Admission come parte di GKE.
Gatekeeper OPA autogestito Policy che non possono essere espresse da ValidatingAdmissionPolicies, ad esempio policy referenziali che leggono altre risorse nel cluster, policy che vuoi mantenere in Rego e audit delle risorse esistenti. Puoi anche aggiungere regole Common Expression Language (CEL) ai ConstraintTemplate di Gatekeeper in modo che Gatekeeper generi ValidatingAdmissionPolicies per l'applicazione del server API e il suo controller di controllo verifichi le risorse esistenti. Sei tu a installare, eseguire l'upgrade e gestire Gatekeeper. L'assistenza clienti non supporta Gatekeeper open source. La community di Gatekeeper fornisce assistenza tramite GitHub.

Inventaria e classifica le policy

Per impostazione predefinita, la libreria di modelli di Policy Controller installa ogni modello e le raccolte di policy installano i relativi vincoli con il provvedimento dryrun. Di conseguenza, i template e i vincoli di un cluster non corrispondono necessariamente alle policy che applichi. Per scoprire quali criteri applichi, segui questi passaggi:

  1. Identifica i cluster nel tuo parco risorse che eseguono Policy Controller:

    gcloud container fleet policycontroller describe \
    --project=PROJECT_ID

    Sostituisci PROJECT_ID con l'ID del progetto host del parco risorse.

  2. In ogni cluster identificato, elenca i vincoli:

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

    L'output mostra il provvedimento di ogni vincolo, il numero di violazioni dell'audit più recente e l'eventuale bundle che lo ha installato. Un vincolo che non ha un valore nella colonna ACTION utilizza il provvedimento deny predefinito.

  3. Esegui il backup dei ConstraintTemplate e dei vincoli in file separati:

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

  4. (Facoltativo) Esegui le seguenti operazioni di backup aggiuntive:

    • Se hai attivato le regole referenziali in Policy Controller, esegui il backup della configurazione di sincronizzazione:

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

    • Se hai attivato la mutazione in Policy Controller, esegui il backup dei mutatori:

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

Conserva questi file di backup in un luogo sicuro. La rimozione di Policy Controller elimina ogni ConstraintTemplate, vincolo, configurazione di sincronizzazione e mutatore nel cluster, inclusi quelli che hai creato. I backup sono necessari per tradurre o ricreare le policy.

Dopo aver eseguito il backup delle policy, determina il percorso di migrazione per ogni vincolo controllando il tipo di vincolo nella tabella seguente:

Percorsi di migrazione per tipo di vincolo
Tipo di vincolo Percorso di migrazione
Vincolo di risorsa singola Se un vincolo valuta i campi solo sulla risorsa in entrata senza leggere data.inventory o appartenere a un bundle di sicurezza dei pod, utilizza un ValidatingAdmissionPolicy.
Vincolo dryrun non applicato Se un vincolo utilizza l'azione di applicazione dryrun e non prevedi di applicarlo, elimina il vincolo.
Vincolo del bundle di sicurezza dei pod Se un vincolo proviene dal bundle pss-baseline-v2022, pss-restricted-v2022 o psp-v2022, utilizza Pod Security Admission. Utilizza ValidatingAdmissionPolicies per tutti i controlli non coperti dall'ammissione di sicurezza dei pod.
Vincolo referenziale Se un vincolo utilizza un template referenziale che legge altre risorse nel cluster, utilizza Gatekeeper autogestito. Per trovare i template referenziali, cerca il riferimento data.inventory nel file di backup.
Vincolo Cloud Service Mesh, Istio o Google Cloud Esamina il vincolo singolarmente per verificare se una funzionalità GKE integrata sostituisce la policy o se il ConstraintTemplate nel file di backup legge data.inventory. La maggior parte di questi modelli controlla solo la risorsa in entrata e funziona in ValidatingAdmissionPolicies, ad eccezione dei modelli referenziali AsmAuthzPolicyDefaultDeny e AsmPeerAuthnMeshStrictMtls, che richiedono Gatekeeper autogestito. Per le sostituzioni integrate, attiva Autorizzazione binaria anziché utilizzare ConstraintTemplate K8sRequireBinAuthZ e configura l'immagine nodo dei tuoi node pool anziché utilizzare ConstraintTemplate K8sRequireCosNodeImage.

Esegui la migrazione a ValidatingAdmissionPolicy

Un ValidatingAdmissionPolicy contiene la logica della policy, come un ConstraintTemplate. Un ValidatingAdmissionPolicyBinding applica la policy, come un vincolo. Un ValidatingAdmissionPolicy utilizza espressioni CEL anziché Rego e il server API valuta le espressioni direttamente, senza un webhook.

Esempio: repository di immagini consentiti

Il seguente vincolo di Policy Controller richiede che i pod utilizzino immagini di un repository Artifact Registry. Esclude lo spazio dei nomi 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/"

I seguenti ValidatingAdmissionPolicy e ValidatingAdmissionPolicyBinding applicano la stessa regola. ValidatingAdmissionPolicyBinding utilizza le azioni Warn e Audit in modo da poter confrontare i risultati prima di applicare 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"]

In questo esempio, la variabile repos contiene il valore del campo parameters del vincolo. L'espressione di convalida restituisce un valore true per i pod che rispettano il ValidatingAdmissionPolicy, che è l'opposto di una regola di violazione di Rego. Per riutilizzare un ValidatingAdmissionPolicy in più ValidatingAdmissionPolicyBindings che forniscono valori diversi, utilizza una risorsa parametro anziché una variabile. Per ulteriori informazioni sulle risorse dei parametri, consulta Risorse dei parametri nella documentazione di Kubernetes.

La tabella seguente mostra come i campi dei vincoli vengono mappati ai campi ValidatingAdmissionPolicy e ValidatingAdmissionPolicyBinding:

Mappatura dei campi dei vincoli di Policy Controller ai campi ValidatingAdmissionPolicy e ValidatingAdmissionPolicyBinding
Campo del vincolo Campo ValidatingAdmissionPolicy o ValidatingAdmissionPolicyBinding
spec.enforcementAction Il campo validationActions in ValidatingAdmissionPolicyBinding, che mappa le azioni deny, warn e dryrun ai valori ["Deny"], ["Warn"] e ["Audit"]
spec.parameters Il campo variables in ValidatingAdmissionPolicy o una risorsa parametro a cui ValidatingAdmissionPolicyBinding fa riferimento nel campo paramRef
spec.match.kinds Il campo matchConstraints.resourceRules in ValidatingAdmissionPolicy, che utilizza gruppi di API e nomi di risorse, come la risorsa pods, anziché i tipi
spec.match.namespaces e spec.match.excludedNamespaces Il campo matchResources.namespaceSelector in ValidatingAdmissionPolicyBinding, utilizzando l'operatore In o NotIn sull'etichetta kubernetes.io/metadata.name
spec.match.labelSelector Il campo matchResources.objectSelector in ValidatingAdmissionPolicyBinding
spec.match.namespaceSelector Il campo matchResources.namespaceSelector in ValidatingAdmissionPolicyBinding
spec.match.scope Il campo scope di ogni regola della risorsa

Per saperne di più su come scrivere espressioni, consulta CEL in Kubernetes nella documentazione di Kubernetes.

Testa le policy insieme a Policy Controller

Per sostituire un vincolo senza interruzioni nell'applicazione, esegui ValidatingAdmissionPolicy accanto al vincolo prima di applicare ValidatingAdmissionPolicy:

  1. Applica ValidatingAdmissionPolicy e un ValidatingAdmissionPolicyBinding con l'impostazione validationActions: ["Warn", "Audit"]. Lascia invariato il vincolo di Policy Controller.
  2. Confronta i risultati utilizzando la query del log di controllo in Sostituisci i report sulle violazioni. Se ValidatingAdmissionPolicy segnala richieste consentite da Policy Controller o viceversa, correggi ValidatingAdmissionPolicy. Per i ValidatingAdmissionPolicies che corrispondono ai pod, non fare affidamento sugli avvisi. I controller creano i pod per i deployment e altri workload, quindi il controller riceve l'avviso.
  3. Dopo che i risultati corrispondono, modifica ValidatingAdmissionPolicyBinding in modo che utilizzi l'impostazione validationActions: ["Deny"].
  4. Elimina il vincolo di Policy Controller.

Pianifica le differenze di comportamento

Le risorse ValidatingAdmissionPolicy si comportano in modo diverso da Policy Controller nei seguenti modi, che possono bloccare le richieste o lasciare lacune nell'applicazione:

  • Policy di errore: il webhook di Policy Controller non riesce ad aprirsi, il che significa che il server API ammette una richiesta se Policy Controller non risponde. Un oggetto ValidatingAdmissionPolicy con l'impostazione failurePolicy: Fail nega una richiesta se un'espressione restituisce un errore o supera il limite di costo CEL. ValidatingAdmissionPolicy rifiuta una richiesta anche se una risorsa del parametro di riferimento non esiste e il valore del campo paramRef.parameterNotFoundAction in ValidatingAdmissionPolicyBinding è Deny. Se il valore è Allow, il server API ignora una risorsa del parametro mancante indipendentemente dall'impostazione failurePolicy. Testa ogni ValidatingAdmissionPolicy e scegli i valori per entrambi i campi.
  • Campi mancanti: Rego considera un campo mancante come nessuna violazione, ma CEL restituisce un errore. Prima di leggere un campo facoltativo, utilizza la macro has() per verificare se il campo esiste.
  • Esenzioni: un ValidatingAdmissionPolicy non esenta gli spazi dei nomi per impostazione predefinita né utilizza l'etichetta admission.gatekeeper.sh/ignore. Nei cluster GKE Standard, un ValidatingAdmissionPolicyBinding si applica a ogni spazio dei nomi del cluster, inclusi gli spazi dei nomi di sistema come lo spazio dei nomi kube-system, a meno che non li escludi nel campo matchResources.namespaceSelector del ValidatingAdmissionPolicyBinding o nei campi matchConstraints.namespaceSelector o matchConditions del ValidatingAdmissionPolicy. Sui cluster Autopilot, GKE esclude automaticamente gli spazi dei nomi gestiti e rifiuta i ValidatingAdmissionPolicy che corrispondono alle risorse nodes, persistentVolumes, certificatesigningrequests o tokenreviews. Per saperne di più, consulta Misure di sicurezza di GKE Autopilot.
  • Risorse secondarie: Policy Controller controlla gli aggiornamenti dei pod che aggiungono container temporanei. Per mantenere questa copertura, includi la sottorisorsa pods/ephemeralcontainers nelle regole delle risorse, come nell'esempio.
  • Nessun controllo delle risorse esistenti: un ValidatingAdmissionPolicy valuta solo le richieste in entrata del server API. Non segnala le risorse esistenti che violano un ValidatingAdmissionPolicy.
  • Un messaggio per ogni richiesta: un ValidatingAdmissionPolicy segnala la prima convalida non riuscita, non ogni violazione.

Utilizza Pod Security Admission per i bundle di sicurezza dei pod

Se utilizzi i bundle pss-baseline-v2022 o pss-restricted-v2022, sostituisci il bundle con Pod Security Admission anziché tradurre ogni vincolo. Pod Security Admission utilizza il controller di ammissione PodSecurity Kubernetes integrato per applicare regole predefinite degli standard di sicurezza dei pod Kubernetes in base alle etichette degli spazi dei nomi. Il bundle pss-baseline-v2022 corrisponde al livello baseline, mentre il bundle pss-restricted-v2022 corrisponde al livello restricted.

Pod Security Admission non copre tutti i controlli nel bundle psp-v2022, come le liste consentite per percorsi host, utenti, funzionalità e sysctl. Utilizza ValidatingAdmissionPolicies per questi controlli. Inoltre, Pod Security Admission non può esentare immagini specifiche, come i vincoli di Policy Controller che utilizzano il parametro exemptImages. GKE non supporta la configurazione delle esenzioni di Pod Security Admission. Se hai bisogno di eccezioni, utilizza ValidatingAdmissionPolicies per le policy interessate.

Per saperne di più su come configurare Pod Security Admission, consulta Applica policy di sicurezza predefinite a livello di pod utilizzando PodSecurity.

Esegui la migrazione a OPA Gatekeeper autogestito

Scegli Gatekeeper per le policy che ValidatingAdmissionPolicies non può esprimere. Policy Controller si basa su Gatekeeper, quindi i tuoi ConstraintTemplate e i tuoi vincoli utilizzano le stesse API in Gatekeeper. Tutti i modelli della libreria di modelli di Policy Controller funzionano in Gatekeeper senza modifiche alla logica. Tuttavia, Gatekeeper utilizza un motore Rego più recente e una convalida più rigorosa che può rifiutare un ConstraintTemplate personalizzato.

Quando utilizzi Gatekeeper autogestito, diventi responsabile delle attività cheGoogle Cloud esegue per Policy Controller, come l'installazione, l'upgrade, la scalabilità e il monitoraggio di Gatekeeper su ogni cluster. L'assistenza clienti non supporta Gatekeeper open source. Per assistenza, utilizza il tracker dei problemi di Gatekeeper su GitHub.

Gatekeeper non include la libreria di modelli o i bundle di policy di Policy Controller. I file di backup contengono i ConstraintTemplate e i vincoli dei tuoi cluster. Per i template provenienti dalla libreria Gatekeeper open source, puoi utilizzare i template nella libreria delle policy di Gatekeeper. I nomi dei template rimangono invariati, ma i parametri e i messaggi possono variare tra le versioni.

Per spostare le policy in Gatekeeper, segui questi passaggi:

  1. (Facoltativo) Se non puoi accettare un'interruzione dell'applicazione delle policy durante la sostituzione di Policy Controller, esegui prima la migrazione delle policy più importanti a ValidatingAdmissionPolicies. Assicurati che questi ValidatingAdmissionPolicyBinding escludano lo spazio dei nomi gatekeeper-system in modo che non blocchino i job di installazione di Gatekeeper. Dopo aver rimosso Policy Controller, il cluster smette di applicare le policy di Gatekeeper finché non applichi i vincoli di Gatekeeper corrispondenti. Le risorse ValidatingAdmissionPolicy continuano l'applicazione perché non dipendono da Policy Controller o Gatekeeper.

  2. Se utilizzi ConstraintTemplate personalizzati, testa ogni manifest del modello personalizzato utilizzando lo strumento a riga di comando gator della versione di Gatekeeper che prevedi di installare:

    gator test --filename=TEMPLATE_FILE

    Sostituisci TEMPLATE_FILE con il percorso del file manifest ConstraintTemplate. Prima di rimuovere Policy Controller, correggi eventuali ConstraintTemplate personalizzati rifiutati da Gatekeeper.

  3. Se esegui il deployment dei vincoli da un repository Git utilizzando uno strumento GitOps, prepara i ConstraintTemplate utilizzati dai vincoli e aggiungili al repository quando installi Gatekeeper. In caso contrario, i vincoli non verranno applicati dopo la rimozione di Policy Controller perché i relativi ConstraintTemplate non esistono più.

  4. Rimuovi Policy Controller seguendo i passaggi descritti in Rimuovi Policy Controller. Non installare Gatekeeper su un cluster in cui è ancora in esecuzione Policy Controller. Entrambi utilizzano lo spazio dei nomi gatekeeper-system, le stesse CustomResourceDefinition e gli stessi nomi dei webhook.

  5. Installa Gatekeeper utilizzando Helm e le impostazioni che scegli dalla tabella nella sezione successiva, Impostazioni di Gatekeeper diverse da quelle di Policy Controller. Per maggiori informazioni su come installare Gatekeeper, consulta Installazione nella documentazione di Gatekeeper.

    Sui cluster Autopilot, l'installazione predefinita del grafico Helm non riesce perché GKE rifiuta le regole con caratteri jolly nei webhook di mutazione. Imposta il valore Helm disableMutation: true o il valore Helm mutatingWebhookCustomRules per elencare solo le risorse specifiche scelte come target dai mutatori. Non includere le risorse nodes, persistentvolumes, certificatesigningrequests o tokenreviews.

  6. Nei file di backup, rimuovi i seguenti campi, etichette e annotazioni da ogni risorsa che prevedi di applicare di nuovo:

    • Il campo status.
    • I campi resourceVersion, uid, creationTimestamp, generation, managedFields e ownerReferences nella sezione metadata.
    • L'annotazione kubectl.kubernetes.io/last-applied-configuration.
    • L'etichetta app.kubernetes.io/managed-by: anthospolicycontroller.googleapis.com. Se Policy Controller viene abilitato di nuovo sul cluster, ad esempio tramite una configurazione predefinita a livello di parco risorse, gestisce le risorse che hanno questa etichetta e può modificarle o eliminarle.
    • Etichette e annotazioni le cui chiavi hanno il prefisso policycontroller..

  7. Applica i ConstraintTemplate utilizzati dai vincoli, quindi verifica che Gatekeeper abbia creato una CustomResourceDefinition per ogni template:

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

    Quando ogni modello mostra un valore true nella colonna CREATED, applica i vincoli.

Impostazioni di Gatekeeper diverse da quelle di Policy Controller

Prima di installare Gatekeeper, esamina le impostazioni nella tabella seguente, in cui i valori predefiniti del grafico Helm di Gatekeeper differiscono da quelli di Policy Controller:

Confronto tra i valori predefiniti di Policy Controller e i valori predefiniti del grafico Helm di Gatekeeper
Impostazione Policy Controller predefinito Valore predefinito del grafico Helm di Gatekeeper Suggerimento
Mutazione Off, a meno che tu non l'abbia attivata On Se non utilizzi la mutazione, imposta il valore Helm disableMutation: true. Nei cluster Autopilot, devi impostare il valore Helm disableMutation: true o configurare il valore Helm mutatingWebhookCustomRules senza caratteri jolly o risorse limitate. Se non specifichi uno di questi valori, GKE rifiuta l'installazione.
Spazi dei nomi esenti Lo spazio dei nomi gatekeeper-system e gli spazi dei nomi nell'elenco exemptableNamespaces Lo spazio dei nomi in cui è installato Gatekeeper Aggiungi gli spazi dei nomi esenti al valore Helm controllerManager.exemptNamespaces. Gatekeeper rifiuta le modifiche agli spazi dei nomi con l'etichetta admission.gatekeeper.sh/ignore, a meno che questi spazi dei nomi non siano esenti.
Dati referenziali Sincronizzazione automatica per i bundle di riferimento Non sincronizzato Crea un oggetto Config o SyncSet di Gatekeeper che elenchi i tipi letti dai tuoi template referenziali. Finché questi tipi non vengono sincronizzati nell'oggetto data.inventory, i controlli dei conflitti consentono le richieste in violazione e i controlli di esistenza, come ConstraintTemplate K8sRequireNamespaceNetworkPolicies, negano ogni richiesta con corrispondenza anche quando la risorsa richiesta esiste.
Generazione di ValidatingAdmissionPolicy Non disponibile On per i modelli che contengono codice CEL I template di Policy Controller contengono solo Rego, quindi Gatekeeper genera ValidatingAdmissionPolicies solo se aggiungi CEL ai tuoi ConstraintTemplate. Per mantenere l'applicazione nel webhook, imposta i valori Helm defaultCreateVAPForTemplates: false e defaultCreateVAPBindingForConstraints: false. Per saperne di più, consulta Integrazione con la policy di ammissione di convalida di Kubernetes nella documentazione di Gatekeeper.
Repliche e risorse Una replica per ogni componente, con un limite di memoria di 1024 MiB Tre repliche del webhook, con limiti di risorse diversi Configura il numero di repliche e i limiti delle risorse in base all'utilizzo attuale.
Immagini Estratta da un registry gestito da Google Estratte da Docker Hub (le immagini openpolicyagent/gatekeeper, openpolicyagent/gatekeeper-crds e curlimages/curl) Per i cluster privati o i cluster che applicano l'Autorizzazione binaria, esegui il mirroring di tutte e tre le immagini in Artifact Registry e sostituisci i relativi valori delle immagini nel grafico. Se non esegui il mirroring dell'immagine curlimages/curl, disabilita il job del probe del webhook.

Per impostazione predefinita, Gatekeeper espone solo le metriche di Prometheus e i nomi delle metriche sono diversi da quelli che Policy Controller invia a Cloud Monitoring. Aggiorna le dashboard e gli avvisi che utilizzano le metriche di Policy Controller.

Esegui la migrazione delle policy di mutazione

Se hai attivato la mutazione in Policy Controller, elenca i mutatori:

kubectl get assign,assignmetadata,assignimage,modifyset

Per ogni mutatore, scegli una delle seguenti opzioni:

  • MutatingAdmissionPolicy: puoi utilizzare un MutatingAdmissionPolicy in GKE versione 1.36 e successive. Come un ValidatingAdmissionPolicy, un MutatingAdmissionPolicy utilizza espressioni CEL e viene eseguito nel server API senza un webhook. Kubernetes esegue tutti i MutatingAdmissionPolicy prima dei ValidatingAdmissionPolicy, quindi testali insieme per assicurarti che una mutazione non causi il rifiuto di un manifest valido da parte di un ValidatingAdmissionPolicy. Nei cluster Autopilot, GKE esclude gli spazi dei nomi gestiti da MutatingAdmissionPolicies. Per saperne di più sulle policy di mutazione, consulta Policy di ammissione di mutazione nella documentazione di Kubernetes.
  • Gatekeeper autogestito: sui cluster Standard, i mutatori funzionano senza modifiche perché Gatekeeper attiva la mutazione per impostazione predefinita. Nei cluster Autopilot, devi impostare il valore Helm mutatingWebhookCustomRules nel grafico Gatekeeper per elencare le risorse specifiche scelte come target dai mutatori anziché le regole con caratteri jolly. Per saperne di più, consulta Misure di sicurezza di GKE Autopilot. Dopo aver installato Gatekeeper, rimuovi i metadati di Policy Controller dal file di backup del mutatore e applica nuovamente i mutatori, come fai per i vincoli.

Aggiorna i controlli delle policy nelle pipeline di build

La pipeline di build potrebbe controllare i manifest rispetto ai vincoli di Policy Controller prima del deployment. Ad esempio, la pipeline potrebbe utilizzare la funzione gatekeeper in kpt o lo strumento a riga di comando gator. Per saperne di più, consulta Convalida le app in base alle policy aziendali in una pipeline CI.

Se la pipeline controlla i manifest, aggiornala per la sostituzione:

  • Se utilizzi Gatekeeper, puoi mantenere la tua pipeline. Aggiorna i percorsi dei file o delle directory nel comando gator o kpt per fare riferimento al repository o alla directory che contiene i manifest ConstraintTemplate e dei vincoli di Gatekeeper puliti.

  • Se utilizzi ValidatingAdmissionPolicies, questi strumenti non valutano le tue policy. Esegui invece un dry run lato server su un cluster di test che contiene i tuoi ValidatingAdmissionPolicy e ValidatingAdmissionPolicyBinding che utilizzano l'azione Deny:

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

    Sostituisci MANIFEST_DIRECTORY con la directory che contiene i manifest. Il comando non va a buon fine se un ValidatingAdmissionPolicy rifiuta un manifest.

Sostituzione della segnalazione delle violazioni

Un ValidatingAdmissionPolicy non include una dashboard e non controlla le risorse già esistenti nel cluster. Utilizza invece i seguenti metodi:

  • Avvisi: se un ValidatingAdmissionPolicyBinding utilizza l'azione Warn, il server API restituisce un avviso al client che ha inviato la richiesta, ad esempio lo strumento a riga di comando kubectl. Per i pod creati da un controller, ad esempio i pod in un deployment, il controller riceve l'avviso.

  • Log di controllo: se un ValidatingAdmissionPolicyBinding utilizza l'azione Audit, il server API annota la voce di log per ogni convalida non riuscita. GKE scrive le richieste di creazione, aggiornamento ed eliminazione negli audit log delle attività di amministrazione in Cloud Logging. Per trovare le convalide non riuscite, esegui questa query in Esplora log:

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

Se utilizzi vincoli con il provvedimento dryrun come report di conformità sulle risorse esistenti, ValidatingAdmissionPolicies non può sostituire il report. Mantieni queste policy su Gatekeeper autogestito, il cui controller di audit controlla le risorse esistenti in base a una pianificazione.

Rimuovi Policy Controller

Prima di rimuovere Policy Controller da un cluster, completa le seguenti attività:

  • Verifica che tutte le policy di cui hai eseguito la migrazione a ValidatingAdmissionPolicies o Pod Security Admission siano applicate e di avere un backup di ConstraintTemplate, vincoli e mutatori. La rimozione di Policy Controller elimina le relative CustomResourceDefinition, il che elimina ogni ConstraintTemplate, vincolo e mutatore nel cluster, inclusi quelli che hai creato.
  • Se esegui il deployment dei vincoli da un repository Git utilizzando uno strumento GitOps come Config Sync o Argo CD, rimuovi i vincoli sostituiti dal repository. Verifica che i vincoli siano stati rimossi dai tuoi cluster.
  • (Facoltativo) Per verificare che non ci siano dipendenze dal webhook di Policy Controller, sospendi prima Policy Controller. La sospensione rimuove solo le configurazioni dei webhook, che puoi ripristinare.

Per rimuovere Policy Controller, segui questi passaggi:

  1. Disinstalla Policy Controller dai cluster:

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

    Sostituisci quanto segue:

    • MEMBERSHIP_NAME: il nome dell'appartenenza del cluster registrato da cui vuoi disinstallare Policy Controller. Per disinstallare Policy Controller da più cluster, specifica un elenco di nomi di appartenenza separati da virgole o sostituisci il flag --memberships=MEMBERSHIP_NAME con il flag --all-memberships.
    • PROJECT_ID: l'ID del progetto host del parco risorse.

  2. Verifica che la disinstallazione di Policy Controller dai tuoi cluster sia stata completata:

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

    Attendi finché il valore del campo policycontroller.state di primo livello per ogni iscrizione non è NOT_INSTALLED, non DECOMMISSIONING. Le singole voci componentStates raggiungono lo stato NOT_INSTALLED prima del completamento della pulizia di CustomResourceDefinition.

    Se prevedi di installare Gatekeeper autogestito, verifica che lo spazio dei nomi gatekeeper-system non esista più:

    kubectl get namespace gatekeeper-system

    Attendi finché l'output non indica che lo spazio dei nomi gatekeeper-system non è stato trovato.

  3. (Facoltativo) Per impedire ai cluster che registri in un secondo momento di ricevere Policy Controller, rimuovi la configurazione predefinita a livello di parco risorse:

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

    Questo comando rimuove solo la configurazione predefinita. Non installa Policy Controller su nessun cluster.

Rimuovi Policy Controller dai cluster esterni a un parco risorse

Il comando gcloud container fleet policycontroller disable rimuove Policy Controller solo dai cluster gestiti dal parco risorse. Un cluster può eseguire Policy Controller senza gestione del parco risorse nei seguenti casi:

  • Hai installato Policy Controller utilizzando l'operatore ConfigManagement.
  • Hai annullato la registrazione del cluster dal relativo parco risorse o hai eseguito il comando gcloud container fleet policycontroller detach prima che la disinstallazione di Policy Controller fosse completata.

Per rimuovere Policy Controller da questi cluster, inserisci il cluster nella gestione del parco risorse, quindi disinstalla Policy Controller:

  1. Esegui il backup di ConstraintTemplate, vincoli, configurazione di sincronizzazione e mutatori, come descritto in Inventaria e classifica le policy. Quando pulisci i metadati dai backup eseguiti da un'installazione di ConfigManagement Operator, rimuovi anche le etichette configmanagement.gke.io/* e k8s-app: kubernetes-config-management, oltre al campo ownerReferences e ai metadati policycontroller.*.

  2. Se hai installato Policy Controller utilizzando l'operatore ConfigManagement, rimuovi il campo policyController dalla risorsa personalizzata ConfigManagement nel cluster. Attendi il completamento della riconciliazione. La riconciliazione può richiedere circa due minuti. Quindi, controlla se lo spazio dei nomi gatekeeper-system esiste ancora:

    kubectl get namespace gatekeeper-system

    In ConfigManagement Operator versione 1.17 e precedenti, la rimozione del campo policyController disinstalla automaticamente Policy Controller. Se lo spazio dei nomi gatekeeper-system non viene trovato, salta i passaggi rimanenti in questa sezione. In ConfigManagement Operator versione 1.18 e successive, lo spazio dei nomi gatekeeper-system rimane nel cluster, quindi vai al passaggio successivo.

  3. Se il cluster non è registrato in un parco risorse, registralo. Per saperne di più, consulta Registra un cluster su Google Cloud nel tuo parco risorse.

  4. Controlla se la mutazione è abilitata nel cluster:

    kubectl get mutatingwebhookconfiguration \
    gatekeeper-mutating-webhook-configuration

  5. Abilita Policy Controller sull'appartenenza del cluster in modo che il parco risorse assuma la gestione dell'installazione esistente. Se il comando precedente ha restituito la risorsa gatekeeper-mutating-webhook-configuration, includi il flag --mutation in modo che il parco risorse adotti e successivamente rimuova le risorse di mutazione con ambito cluster:

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

    Sostituisci quanto segue:

    • MEMBERSHIP_NAME: il nome della membership del tuo cluster registrato.
    • PROJECT_ID: l'ID del progetto host del parco risorse.

  6. Attendi finché il valore del campo policycontroller.state per la membership non è ACTIVE:

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

  7. Disinstalla Policy Controller seguendo i passaggi descritti in Rimuovi Policy Controller. Se non installi Gatekeeper autogestito, elimina tutte le CustomResourceDefinition dei vincoli rimanenti dopo la rimozione dello spazio dei nomi gatekeeper-system:

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

  8. (Facoltativo) Se hai registrato il cluster solo per completare questa procedura, annulla la registrazione dopo che il comando describe mostra lo stato NOT_INSTALLED per l'appartenenza. Per i cluster registrati utilizzando il flag --enable-fleet, esegui il comando gcloud container clusters update con il flag --clear-fleet-project anziché il comando gcloud container fleet memberships unregister. Per saperne di più, consulta Annullamento della registrazione di un cluster.

Passaggi successivi