La nuova versione 1.13 della piattaforma container Kubernetes rimuove le vulnerabilità critiche (CVE-2018-1002105), che consente a qualsiasi utente di ottenere il controllo completo su un gruppo di contenitori isolati. Il problema è stato risolto anche negli aggiornamenti 1.10.11, 1.11.5 e 1.12.3.
Nella vulnerabilità riscontrata in Kubernetes, per effettuare l'attacco, è sufficiente inviare una richiesta appositamente progettata tramite API per determinare i backend disponibili (discovery request).
Informazioni sulla vulnerabilità Kubernetes
A causa di un errore, questo tipo di richiesta lascia aperta la connessione di rete, consentendo l'utilizzo del server API (kube-apiserver) come intermediario per inviare richieste a qualsiasi server utilizzando la connessione stabilita con il server API.
di conseguenza, le richieste inoltrate tramite tali connessioni verranno elaborate dal backend come richieste del server API interno, inviato utilizzando i parametri di autenticazione del server API.
Per impostazione predefinita, tutti gli utenti Kubernetes autenticati e non hanno la possibilità di inviare richieste tramite l'API di rilevamento, che sono sufficienti per lanciare un attacco.
Pertanto, qualsiasi utente Kubernetes non privilegiato che ha accesso all'API può ottenere il controllo completo sull'intera infrastruttura, ad esempio inviando una richiesta per eseguire il proprio codice sull'host.
Oltre a ottenere il controllo dell'infrastruttura Kubernetes, la vulnerabilità può essere applicata anche agli attacchi mirati ai clienti attraverso la manipolazione dei servizi clienti situati nel cloud.
Il problema si manifesta in tutte le versioni di Kubernetes, a partire dalla versione 1.0.
Pertanto, tutti gli amministratori di Kubernetes sono incoraggiati ad aggiornare urgentemente i loro sistemi ai problemi attuali, nonché a controllare i log di sistema per potenziali attività dannose.
Come soluzione per proteggersi dagli attacchi di utenti non autorizzati, possono disabilitare l'accesso anonimo all'API utilizzando l'opzione "–anonymous-auth = false" e revocare i diritti per eseguire operazioni exec / attach / portforward.
Si segnala separatamente che nei log di Kubernetes l'attacco che utilizza richieste non autorizzate non viene affatto loggato, pertanto è stato possibile determinare se la compromissione fosse possibile solo tramite segni indiretti.
Informazioni sulla nuova versione 1.13 di Kubernetes e sulle novità
In questa nuova versione di Kubernetes 1.13 L'interfaccia CSI (Container Storage Interface) è stata stabilizzata, consentendo di creare plug-in per supportare più sistemi di archiviazione.
CSI fornisce un'unica interfaccia per l'allocazione, il collegamento e il montaggio di repository, consentendo di fornire plug-in per l'integrazione con vari servizi di archiviazione senza la necessità di modifiche alla base di codice Kubernetes.
Per impostazione predefinita, viene utilizzato il server DNS CoreDNS.
CoreDNS è scritto nella lingua Go e si distingue per un'architettura flessibile basata su plugin.
Ad esempio, funzionalità specifiche come il rilevamento del servizio Kubernetes, l'accumulo di metriche per il sistema di monitoraggio Prometheus e l'integrazione con il sistema di archiviazione della configurazione, ecc. sono implementati tramite plugin.
Kubeadm è stato stabilizzato come interfaccia semplificata per la gestione del cluster Kubernetes, che consente di eseguire operazioni come creare e distribuire un cluster sulla macchina esistente, configurare i componenti di base di Kubernete, connettere e rimuovere nodi, eseguire operazioni di upgrade;
Viene presentata un'interfaccia sperimentale per la creazione di plugin per l'integrazione con sistemi di monitoraggio di terze parti.
Il registro dei plug-in del dispositivo Kubelet stabilizzato dal servizio, che fornisce i mezzi per accedere a Kubelet dai plug-in.
Lo scheduler di distribuzione del contenitore TAVS (Topology Aware Volume Scheduling) è stato stabilizzato, tenendo conto della topologia delle sezioni del pod (tenendo conto delle restrizioni impostate per i nodi e le zone).
Siamo passati alla fase di beta testing di APIServer DryRun, al team di Kubectl Diff e alla possibilità di utilizzare dispositivi a blocchi grezzi come sorgenti di dati persistenti (sorgente di volume persistente).
Se vuoi saperne di più su questa nuova versione pueden visitare il seguente collegamento.