Ritiro e chiusura della convalida continua legacy

I Termini di servizio di Google Cloud Platform (sezione 1.4(d) "Interruzione dei servizi") definiscono le norme sul ritiro che si applicano a Binary Authorization. Le norme sul ritiro si applicano solo ai servizi, alle funzionalità o ai prodotti ivi elencati.

Dopo essere stato ufficialmente deprecato, un servizio, una funzionalità o un prodotto continuano a essere disponibili per almeno il periodo di tempo definito nei Termini di servizio. Dopo questo periodo di tempo, viene pianificato l'arresto del servizio.

Autorizzazione binaria non supporta più la convalida continua legacy (CV legacy) con criteri di singolo progetto per GKE.

• A partire dal 15 aprile 2024, non puoi abilitare l'CV precedente per Google Kubernetes Engine (GKE) nei nuovi progetti.
• Il CV legacy continuerà a monitorare Pod GKE tramite criteri di singolo progetto per gli account i progetti per i quali è già abilitato fino al 1° maggio 2025. Dopo il 1° maggio 2025, il CV legacy non monitorerà più i pod Non verranno più prodotte voci Cloud Logging per le immagini pod che non sono conformi al criterio di Autorizzazione binaria per progetto-singleton.

Sostituzione: convalida continua (CV) con criteri della piattaforma basati su controlli

Monitora i pod utilizzando la continuazione continua (CV) con criteri della piattaforma basati sui controlli.

Oltre al supporto per le attestazioni, i criteri della piattaforma basati su controlli ti consentono monitorare i metadati delle immagini container associate ai tuoi pod per e ridurre i potenziali problemi di sicurezza. Criteri basati sul controllo CV effettuare controlli che includono quanto segue:

• Controllo di vulnerabilità: l'immagine viene controllata per verificare la presenza di vulnerabilità di sicurezza a un livello di gravità che definisci.
• Controllo Sigstore. L'immagine è le attestazioni firmate da sigstore.
• Controllo SLSA: l'immagine è stata creata dall'origine in una directory attendibile e da un builder attendibile.
• Controllo delle directory attendibili: L'immagine deve trovarsi in una directory attendibile all'interno di un'immagine attendibile repository Git.

Come la convalida continua legacy, anche le variabili personalizzate con criteri basati su controllo registrano Pod con immagini non conformi a Logging.

Se utilizzi la convalida continua legacy (CV legacy), consulta Migrazione.

Per ulteriori informazioni su come utilizzare CV con criteri della piattaforma basati sui controlli, consulta Panoramica della convalida continua.

Migrazione

Per eseguire la migrazione da un criterio legacy per singoli progetti CV a un criterio della piattaforma basato su controllo equivalente, procedi nel seguente modo:

• Per un criterio di singolo progetto ALWAYS_ALLOW, crea una piattaforma basata su controlli criterio senza alcun blocco checkSet.
• Per un criterio di singolo progetto ALWAYS_DENY, crea una piattaforma basata su controlli criterio con un singolo blocco checkSet che presenta un controllo alwaysDeny.
• Per un criterio di singolo progetto che richiede attestazioni, crea un'istanza un unico criterio basato su controlli e per ogni attestatore nel singolo progetto aggiungi un criterio SimpleSigningAttestationCheck al criterio basato su controlli. Utilizzando la stessa coppia di chiavi, il controllo funzionano con le attestazioni esistenti e registra solo le immagini dei pod che non hanno attestazioni valide.

I criteri della piattaforma basati sui controlli hanno come ambito un cluster GKE, rispetto a un progetto Google Cloud. Dopo aver creato una piattaforma basata su controlli puoi applicarlo a uno o più cluster.

Per abilitare la verifica delle conversioni con criteri della piattaforma basati sui controlli su un cluster, le impostazioni di Autorizzazione binaria del cluster devono essere configurate durante il processo di creazione o aggiornamento del cluster.