Questo documento descrive come Google gestisce le vulnerabilità e le patch di sicurezza per Google Kubernetes Engine (GKE). Queste informazioni potrebbero essere utili agli specialisti della sicurezza che supportano la risoluzione di problemi o vulnerabilità di sicurezza che richiedono assistenza strategica, come incidenti e problemi di cui è stato eseguito l'escalation dall'assistenza.
Responsabilità condivisa per l'applicazione di patch
L'applicazione di patch è una responsabilità condivisa tra Google e il cliente, come descritto in Responsabilità condivisa di GKE.
Come scopriamo le vulnerabilità
Google ha investito molto nella progettazione e nella protezione proattiva della sicurezza, ma anche i sistemi software meglio progettati possono presentare vulnerabilità. Per trovare queste vulnerabilità e applicare le patch prima che possano essere sfruttate, Google ha effettuato investimenti significativi su più fronti.
Ai fini dell'applicazione di patch, GKE è un livello del sistema operativo (OS) con container in esecuzione sopra. I sistemi operativi, Container-Optimized OS o Ubuntu, sono protetti e contengono la quantità minima di software necessaria per eseguire i container. Le funzionalità di GKE vengono eseguite come container sopra le immagini di base. GKE si impegna costantemente a ridurre il numero di dipendenze dei componenti di sistema, il che contribuisce a ridurre la superficie di attacco e a migliorare l'efficienza della gestione delle vulnerabilità. Ad esempio, i componenti di sistema GKE potrebbero utilizzare immagini di base minime, se possibile.
Google identifica e corregge le vulnerabilità e le patch mancanti nei seguenti modi:
Container-Optimized OS: Google esegue la scansione delle immagini per identificare potenziali vulnerabilità e patch mancanti. Il team di Container-Optimized OS esamina e risolve i problemi.
Ubuntu: Canonical fornisce a Google build del sistema operativo a cui sono state applicate tutte le patch di sicurezza disponibili.
Google esegue la scansione dei container utilizzando Artifact Analysis di Container Registry per scoprire vulnerabilità e patch mancanti in Kubernetes e nei container gestiti da Google. Se sono disponibili correzioni, lo scanner avvia automaticamente il processo di applicazione di patch e rilascio.
Oltre alla scansione automatica, Google scopre e applica patch alle vulnerabilità sconosciute agli scanner nei seguenti modi.
Google esegue audit, test di penetrazione e rilevamento delle vulnerabilità su tutte le piattaforme. Per un elenco delle piattaforme, consulta la sezione precedente Responsabilità condivisa per l'applicazione di patch.
Team specializzati di Google e fornitori di sicurezza di terze parti di fiducia conducono le proprie ricerche sugli attacchi. Google ha anche collaborato con la CNCF per fornire gran parte delle competenze di consulenza organizzativa e tecnica per l' audit di sicurezza di Kubernetes.
Google collabora attivamente con la comunità di esperti sulla sicurezza attraverso diversi programmi di ricompense per la segnalazione di vulnerabilità. Un programma di ricompense per la segnalazione di vulnerabilità dedicato Google Cloud offre ricompense significative, tra cui 133.337 $per la migliore vulnerabilità cloud trovata ogni anno. Per GKE, esiste un programma che premia gli esperti di sicurezza se riescono a violare i nostri controlli di sicurezza. Il programma copre tutte le dipendenze software di GKE.
Google collabora con altri partner del settore e di software open source che condividono vulnerabilità, ricerche sulla sicurezza e patch prima del rilascio pubblico della vulnerabilità. L'obiettivo di questa collaborazione è applicare patch a grandi parti dell'infrastruttura internet prima che la vulnerabilità venga annunciata pubblicamente. In alcuni casi, Google contribuisce a questa comunità con le vulnerabilità trovate. Ad esempio, Project Zero di Google ha scoperto e reso pubbliche le vulnerabilità Spectre e Meltdown. Il Google Cloud team di sicurezza trova e corregge regolarmente anche le vulnerabilità nella macchina virtuale basata su kernel (KVM).
La collaborazione di Google in materia di sicurezza avviene a molti livelli. A volte avviene formalmente tramite programmi in cui le organizzazioni si registrano per ricevere notifiche di pre-rilascio sulle vulnerabilità software per prodotti come Kubernetes ed Envoy. La collaborazione avviene anche in modo informale grazie al nostro coinvolgimento in molti progetti open source come il kernel Linux, i runtime dei container, la tecnologia di virtualizzazione e altri.
Per Kubernetes, Google è un membro attivo e fondatore del Security Response Committee (SRC) e ha scritto gran parte del processo di rilascio della sicurezza. Google è un membro del Kubernetes Distributors List che riceve una notifica preventiva delle vulnerabilità ed è stato coinvolto nel la valutazione, nell'applicazione di patch, nello sviluppo della mitigazione e nella comunicazione di quasi tutte le vulnerabilità di sicurezza gravi di Kubernetes. Google ha anche scoperto diverse vulnerabilità di Kubernetes, come CVE-2019-11254, CVE-2019-11255 e CVE-2021-25741.
Sebbene le vulnerabilità meno gravi vengano scoperte e corrette al di fuori di questi processi, la maggior parte delle vulnerabilità di sicurezza critiche viene segnalata privatamente tramite uno dei canali elencati in precedenza. La segnalazione anticipata consente a Google di avere tempo prima che la vulnerabilità diventi pubblica per studiare in che modo influisce su GKE, sviluppare patch o mitigazioni e preparare consigli e comunicazioni per i clienti. Quando possibile, Google applica patch a tutti i cluster prima del rilascio pubblico della vulnerabilità.
Come vengono classificate le vulnerabilità
GKE investe molto nella protezione della sicurezza dell'intero stack, inclusi i livelli di sistema operativo, container, Kubernetes e rete, oltre a impostare valori predefiniti validi, configurazioni con protezione avanzata e componenti gestiti. Insieme, questi sforzi contribuiscono a ridurre l'impatto e la probabilità di vulnerabilità.
Il team di sicurezza di GKE classifica le vulnerabilità in base al sistema di punteggio delle vulnerabilità di Kubernetes. Le classificazioni tengono conto di molti fattori, tra cui la configurazione e la protezione avanzata della sicurezza di GKE. A causa di questi fattori e degli investimenti di GKE nella sicurezza, le classificazioni delle vulnerabilità di GKE potrebbero differire da altre fonti di classificazione.
La tabella seguente descrive le categorie di gravità delle vulnerabilità:
| Gravità | Descrizione |
|---|---|
| Critico | Una vulnerabilità facilmente sfruttabile in tutti i cluster da un utente malintenzionato remoto non autenticato che porta alla compromissione completa del sistema. |
| Alta | Una vulnerabilità facilmente sfruttabile per molti cluster che porta alla perdita di riservatezza, integrità o disponibilità. |
| Media | Una vulnerabilità sfruttabile per alcuni cluster in cui la perdita di riservatezza, integrità o disponibilità è limitata da configurazioni comuni, dalla difficoltà dello sfruttamento stesso, dall'accesso richiesto o dall'interazione dell'utente. |
| Bassa | Tutte le altre vulnerabilità. Lo sfruttamento è improbabile o le conseguenze dello sfruttamento sono limitate. |
Consulta i bollettini sulla sicurezza per esempi di vulnerabilità, correzioni e mitigazioni e le relative valutazioni.
Come vengono applicate le patch alle vulnerabilità per i cluster GKE
L'applicazione di patch a una vulnerabilità comporta l'upgrade a un nuovo numero di versione di GKE. Le versioni di GKE includono componenti con controllo delle versioni per il sistema operativo, i componenti di Kubernetes e altri container che compongono la piattaforma GKE. La correzione di alcune vulnerabilità richiede solo un upgrade del piano di controllo, eseguito automaticamente da Google su GKE, mentre altre richiedono upgrade sia del piano di controllo sia dei nodi.
Per mantenere i cluster protetti dalle vulnerabilità di tutte le gravità, ti consigliamo di seguire le best practice per gli upgrade dei cluster GKE per assicurarti che il cluster riceva le patch di sicurezza in modo tempestivo.
Google consiglia di eseguire l'upgrade dei cluster Kubernetes almeno una volta al mese. Per un elenco delle piattaforme, consulta la sezione precedente Responsabilità condivisa per l'applicazione di patch.
Alcuni scanner di sicurezza o controlli manuali delle versioni potrebbero presupporre erroneamente che un componente come runc o containerd non abbia una patch di sicurezza upstream specifica. GKE applica regolarmente patch ai componenti ed esegue l'upgrade delle versioni dei pacchetti solo quando necessario, il che significa che i componenti GKE sono funzionalmente simili alle loro controparti upstream anche se il numero di versione del componente GKE non corrisponde al numero di versione upstream. Per i dettagli su un CVE specifico, consulta i bollettini sulla sicurezza di GKE.
Tempistiche per l'applicazione di patch
L'obiettivo di Google è mitigare le vulnerabilità rilevate entro un periodo di tempo appropriato per i rischi che rappresentano. GKE è incluso nell' Google Cloud's ATO provvisorio FedRAMP che richiede che le vulnerabilità note vengano corrette entro tempistiche specifiche in base al livello di gravità specificato nel controllo RA-5(d) del record di valutazione del rischio (RA) RA-5, "Scansione delle vulnerabilità", nel foglio di lavoro FedRAMP Security Controls Baseline.
Per ogni vulnerabilità nota, l'obiettivo di GKE è rilasciare versioni patch che la correggono entro la tempistica corrispondente. Dopo che GKE ha reso disponibili le versioni patch per correggere una vulnerabilità nota, esegui l'upgrade dei cluster a queste versioni per rispettare le tempistiche di applicazione di patch della tua organizzazione.
Come vengono comunicate le vulnerabilità e le patch
A partire dal 1° giugno 2026, GKE non pubblicherà bollettini sulla sicurezza per Google Distributed Cloud (solo software), GKE su AWS o GKE su Azure. Per visualizzare i bollettini sulla sicurezza e le correzioni delle vulnerabilità più recenti per questi prodotti, consulta i seguenti documenti:
A volte le vulnerabilità vengono mantenute private in base a embargo per un periodo di tempo limitato. Gli embargo contribuiscono a impedire la pubblicazione anticipata di vulnerabilità che potrebbero portare a tentativi di sfruttamento diffusi prima che vengano adottate misure per risolverle. Nelle situazioni di embargo, le note di rilascio fanno riferimento agli "aggiornamenti della sicurezza" fino a quando l'embargo non sarà stato revocato. Dopo la revoca dell'embargo, Google aggiorna le note di rilascio per includere le vulnerabilità specifiche.
Il team di sicurezza di GKE pubblica bollettini sulla sicurezza per le vulnerabilità di gravità alta e critica. Quando è richiesta un'azione del cliente per risolvere queste vulnerabilità di gravità alta e critica, Google contatta i clienti via email. Inoltre, Google potrebbe contattare i clienti con contratti di assistenza anche tramite i canali di assistenza.
Qual è il modo più rapido per installare una patch di sicurezza?
Tutti i cluster rimarranno automaticamente aggiornati con gli upgrade automatici di GKE. Questa sezione descrive come applicare patch più velocemente degli upgrade automatici per correzioni di sicurezza specifiche o su base continuativa. Combinando ambienti di test, upgrade manuali cross-channel, impostazioni di patch accelerate e notifiche basate su eventi, puoi ridurre i tempi di consegna delle patch.
GKE gestisce le implementazioni delle versioni nei canali di rilascio per garantire che le nuove versioni siano qualificate e sottoposte a soak. Per ridurre i tempi di consegna delle patch, devi capire come funzionano queste implementazioni e poi personalizzare il comportamento predefinito in base alle tue esigenze specifiche.
Il soak di una versione con patch comporta l'esecuzione sui cluster nel tempo per osservarne la stabilità. Questo processo consente di rilevare i bug che vengono visualizzati solo dopo un uso prolungato in ambienti diversi. Per garantire un tempo di soak sufficiente, le release di patch GKE vengono introdotte prima nel canale rapido, poi in quello regolare e infine in quello stabile. Le release vengono sottoposte a soak anche in ogni canale prima di diventare la destinazione dell'upgrade per il canale.
Qualificare le patch in anticipo e gestire l'implementazione con la sequenza di implementazione
Per qualificare una patch di sicurezza di cui vuoi accelerare l'applicazione, utilizza la sequenza di implementazione per eseguirla negli ambienti, testando una patch in altri cluster GKE prima di eseguire l'upgrade dell'ambiente di produzione. Questo approccio ti consente di verificare la compatibilità dei carichi di lavoro e di rilevare eventuali problemi non appena Google rilascia una correzione di sicurezza. Dopodiché, puoi applicare la versione con patch al resto del parco risorse e controllare il tempo di soak rimanente.
Ridurre i ritardi di soak con gli upgrade automatici delle patch accelerati
In alternativa, puoi scegliere di utilizzare le patch più velocemente abilitando gli upgrade automatici delle patch accelerati per i tuoi cluster. Questa funzionalità indica a GKE di ignorare il tempo di soak nel canale per gli aggiornamenti delle patch, in particolare le patch di sicurezza. Se utilizzi questo approccio, Google consiglia di eseguire un cluster di test sul canale rapido (anche con gli upgrade automatici delle patch accelerati) per qualificare le patch.
Upgrade manuali alle versioni patch più recenti nei canali regolari e stabili
Se i carichi di lavoro di produzione si trovano su cluster registrati nei canali regolari o stabili, non devi abbandonare questi canali né attendere che l' implementazione automatica e graduale di una patch ti raggiunga se è presente un aggiornamento della sicurezza specifico a cui devi dare la priorità.
Se hai qualificato la versione con patch, puoi avviare manualmente gli upgrade sui cluster in versione regolare o stabile a quella versione patch esatta per controllare il tempo di soak rimanente.
Automatizzare la gestione delle patch con le notifiche dei cluster
Non è necessario monitorare la pagina web dei bollettini sulla sicurezza per informazioni sulle patch. Per ricevere notifiche programmatiche rapide delle patch disponibili e attivare le azioni di qualificazione e upgrade delle patch, puoi utilizzare le notifiche dei cluster cluster.
Per ricevere notifiche per i bollettini sulla sicurezza o gli upgrade pianificati, configura le notifiche in modo da filtrare in modo specifico i seguenti tipi di eventi:
Le notifiche dei cluster ti consentono di ricevere messaggi in tempo reale quando si verificano questi eventi. Puoi integrare queste notifiche nei sistemi di gestione degli eventi e delle informazioni di sicurezza (SIEM), nelle operazioni di chat o attivare pipeline di test automatizzate.