Ritiro e disattivazione della convalida continua precedente

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

Una volta ritirato ufficialmente, un servizio, una funzionalità o un prodotto continuerà a essere disponibile per almeno il periodo di tempo definito nei Termini di servizio. Al termine di questo periodo di tempo, è prevista la disattivazione del servizio.

Autorizzazione binaria sta terminando il supporto della convalida continua legacy (CV legacy) con criteri di progetto singleton per GKE.

• A partire dal 15 aprile 2024, non potrai attivare i CV legacy per Google Kubernetes Engine (GKE) nei nuovi progetti.
• La CV legacy continuerà a monitorare i pod GKE tramite i criteri di progetto-singleton per i progetti esistenti per i quali è già attivata fino al 1° maggio 2025. Dopo il 1° maggio 2025, la versione precedente di CV non monitorerà più i pod e le voci di Cloud Logging non verranno più prodotte per le immagini dei pod che non sono conformi alle norme di autorizzazione binaria del progetto-singleton.

Sostituzione: convalida continua (CV) con norme della piattaforma basate su controlli

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

Oltre a supportare le attestazioni, i criteri della piattaforma basati su controlli ti consentono di monitorare i metadati delle immagini dei contenitori associate ai tuoi pod per aiutarti a mitigare potenziali problemi di sicurezza. I criteri basati sul controllo del CV prevedono controlli che includono quanto segue:

• Controllo delle vulnerabilità: viene controllata la presenza di vulnerabilità di sicurezza con un livello di gravità definito da te.
• Controllo Sigstore: l'immagine contiene attestazioni firmate da Sigstore.
• Controllo SLSA: l'immagine è stata creata da codice sorgente in una directory attendibile e da un compilatore attendibile.
• Controllo della directory attendibile: l'immagine deve trovarsi in una directory attendibile all'interno di un repository di immagini attendibili.

Come per la convalida continua precedente, la convalida continua con criteri basati su controlli registra anche i pod con immagini non conformi in Logging.

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

Per ulteriori informazioni su come utilizzare la convalida continua con le norme della piattaforma basate su controlli, consulta la Panoramica della convalida continua.

Migrazione

Per eseguire la migrazione da un criterio project-singleton del CV precedente a un criterio della piattaforma basato su controlli equivalente:

• Per un criterio ALWAYS_ALLOW project-singleton, crea un criterio di piattaforma basato su controlli senza blocchi checkSet.
• Per un criterio project-singleton ALWAYS_DENY, crea un criterio della piattaforma basato su controlli con un singolo blocco checkSet contenente un controllo alwaysDeny.
• Per un criterio progetto singolo che richiede attestazioni, crea un singolo criterio basato su controlli e, per ogni attestatore nel criterio progetto singolo, aggiungi un SimpleSigningAttestationCheck al criterio basato su 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 dispongono di attestazioni valide.

I criteri della piattaforma basati su controlli hanno come ambito un cluster GKE, anziché un progetto Google Cloud. Dopo aver creato un criterio della piattaforma basato su controlli, puoi applicarlo a uno o più cluster.

Per attivare la verifica del codice con criteri della piattaforma basati su controlli su un cluster, le impostazioni di Autorizzazione binaria del cluster devono essere configurate durante la procedura di creazione o aggiornamento del cluster.