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 è possibile abilitare CV legacy per Google Kubernetes Engine (GKE) nei nuovi progetti.
• CV legacy continuerà a monitorare i pod GKE tramite criteri di singolo progetto per i progetti esistenti per i quali è già abilitato fino al 1° maggio 2025. Dopo il 1° maggio 2025, i CV legacy non monitoreranno più i pod e le voci di Cloud Logging non verranno più prodotte per le immagini pod non conformi al criterio di Autorizzazione binaria project-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 delle attestazioni, i criteri della piattaforma basati su controlli consentono di monitorare i metadati delle immagini container associate ai pod per mitigare potenziali problemi di sicurezza. I criteri basati su controlli CV forniscono controlli che includono quanto segue:

• Controllo di vulnerabilità: l'immagine viene controllata per verificare la presenza di vulnerabilità di sicurezza con un livello di gravità da te definito.
• Controllo Sigstore: l'immagine contiene 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 repository di immagini attendibili.

Come la convalida continua legacy, CV con criteri basati su controllo registra anche i pod con immagini non conformi in Logging.

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

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

Migrazione

Per eseguire la migrazione da un criterio legacy per i singoli progetti di CV a un criterio della piattaforma equivalente basato su controllo, segui questi passaggi:

• Per un criterio di singolo progetto ALWAYS_ALLOW, crea un criterio della piattaforma basato su controllo senza alcun blocco checkSet.
• Per un criterio di singolo progetto ALWAYS_DENY, crea un criterio di piattaforma basato su controllo con un singolo blocco checkSet con un controllo alwaysDeny.
• Per un criterio del singleton progetto che richiede attestazioni, crea un singolo criterio basato su controllo e, per ogni attestatore nel criterio singleton progetto, aggiungi un SimpleSigningAttestationCheck al criterio basato sui controlli. Se utilizzi la stessa coppia di chiavi, il controllo continua a funzionare con le attestazioni esistenti e registra solo le immagini dei pod che non hanno attestazioni valide.

I criteri della piattaforma basati sui controlli sono limitati a un cluster GKE e non a un progetto Google Cloud. Dopo aver creato un criterio della piattaforma basato su controlli, puoi applicarlo a uno o più cluster.

Per abilitare CV con criteri della piattaforma basati su controllo su un cluster, le impostazioni di Autorizzazione binaria del cluster devono essere configurate durante il processo di creazione o aggiornamento del cluster.