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 a livello di singolo progetto per GKE.
- A partire dal 15 aprile 2024, non è possibile abilitare CV legacy per Google Kubernetes Engine (GKE) nei nuovi progetti.
- Il CV legacy continuerà a monitorare i tuoi pod GKE tramite criteri a livello di singolo progetto per i progetti esistenti per i quali è già abilitato fino al 1° maggio 2025. Dopo il 1° maggio 2025, il CV legacy non monitorerà più i pod e non verranno più generate voci di Cloud Logging per le immagini dei pod non conformi al criterio di Autorizzazione binaria project-singleton.
Sostituzione: convalida continua (CV) con i criteri della piattaforma basati su controlli
Monitorare 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 consentono di monitorare i metadati delle immagini container associate ai tuoi pod per ridurre i potenziali problemi di sicurezza. I criteri basati su controlli CV forniscono controlli che includono quanto segue:
- Controllo delle vulnerabilità: l'immagine viene controllata per verificare la presenza di vulnerabilità di sicurezza al livello di gravità da te definito.
- Controllo Sigstore: l'immagine contiene attestazioni firmate da sigstore.
- Controllo SLSA: l'immagine è stata creata da un'origine in una directory attendibile e da un builder affidabile.
- Controllo directory attendibile: l'immagine deve trovarsi in una directory attendibile all'interno di un repository di immagini attendibile.
Come la convalida continua legacy, i CV con criteri basati su controlli registrano 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 la CV con i criteri della piattaforma basati su controlli, consulta Panoramica della convalida continua.
Migrazione
Per eseguire la migrazione da un criterio precedente a livello di singolo progetto CV a un criterio della piattaforma equivalente basato su controlli:
- Per un criterio a livello di singolo progetto
ALWAYS_ALLOW, crea un criterio della piattaforma basato su controlli senza alcun bloccocheckSet. - Per un criterio a livello di singolo progetto
ALWAYS_DENY, crea un criterio della piattaforma basato su controlli con un singolo bloccocheckSetche abbia un controlloalwaysDeny. - Per un criterio a livello di singolo progetto che richiede attestazioni, crea un singolo criterio basato su controllo e, per ogni attestatore nel criterio singleton del progetto, aggiungi un SimpleSigningAttestationCheck al criterio basato su controlli. Utilizzando la stessa coppia di chiavi, il controllo continua a funzionare con le attestazioni esistenti e registra solo le immagini pod che non hanno 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 abilitare la 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.