Benchmark CIS


Questa pagina descrive l'approccio adottato da Google Kubernetes Engine (GKE) per migliorare la conformità ai benchmark del Center for Internet Security (CIS) per Kubernetes e GKE. Questa pagina include le seguenti informazioni:

  • Come configuriamo il piano di controllo GKE gestito per conformarsi al benchmark CIS
  • Configurare nodi e carichi di lavoro GKE per renderli conformi al benchmark CIS Google Kubernetes Engine (GKE)

Informazioni su CIS Benchmarks

CIS rilascia i seguenti benchmark che contengono linee guida per la configurazione sicura per Kubernetes:

  • Benchmark CIS per Kubernetes: si applica al progetto Kubernetes open source. È destinata a fornire indicazioni per una serie di implementazioni Kubernetes autogestite e ospitate.
  • Benchmark GKE per CIS: stabilisce le linee guida per la configurazione sicura dei componenti che puoi controllare nei cluster GKE. Include suggerimenti specifici per GKE su Google Cloud.

Ti consigliamo di dare la priorità al CIS GKE Benchmark, poiché è specifico di GKE su Google Cloud. Il benchmark CIS per Kubernetes contiene molti suggerimenti per i controlli che non puoi visualizzare o modificare in GKE. Il nostro approccio alla sicurezza dei cluster include mitigazioni che vanno oltre l'ambito del benchmark open source Kubernetes e potrebbero causare conflitti con questi suggerimenti.

Altri benchmark applicabili a GKE

Oltre al CIS GKE Benchmark e al CIS Kubernetes Benchmark, i seguenti benchmark si applicano ai sistemi operativi disponibili in GKE. Anche se un benchmark specifico del sistema operativo non riguarda in modo esplicito l'utilizzo di Kubernetes, devi comunque fare riferimento a quel benchmark per avere ulteriori indicazioni sulla sicurezza.

Il runtime del container predefinito, containerd, non ha un benchmark.

Modello di responsabilità condivisa

In base al modello di responsabilità condivisa di GKE, gestiamo per te i seguenti componenti:

  • Il piano di controllo, inclusi le VM del piano di controllo, il server API e componenti come etcd, kube-controller-manager e kube-scheduler.
  • Il sistema operativo del nodo.

Questi componenti esistono in un progetto di proprietà di GKE, pertanto non puoi modificarli o valutarli rispetto ai controlli CIS Benchmark corrispondenti. Tuttavia, puoi valutare e risolvere qualsiasi controllo di CIS Benchmark che si applica ai tuoi nodi worker e ai tuoi carichi di lavoro. In base al modello di responsabilità condivisa di GKE, questi componenti sono la tua responsabilità.

Il nostro approccio alla protezione di GKE per il benchmark CIS

GKE è un'implementazione gestita di Kubernetes open source. Gestiamo completamente il piano di controllo e siamo responsabili della sicurezza della configurazione dei relativi componenti. La seguente tabella descrive alcune delle nostre decisioni che potrebbero influire sul punteggio dei benchmark CIS:

Approccio alla sicurezza di GKE
Autenticazione
  • Alcuni componenti di monitoraggio di GKE utilizzano l'autenticazione anonima per ottenere le metriche. GKE consente l'autenticazione anonima per il kubelet, ma questa esposizione è identica alla porta di sola lettura perché disabilitiamo i gestori di debug aggiuntivi.
  • Il bootstrapping di alcuni componenti del piano di controllo viene eseguito tramite token statici, che vengono poi utilizzati per l'autenticazione al server API. Questi token vengono generati a ogni avvio o riavvio di una VM.
Controller di ammissione

GKE disabilita i seguenti controller di ammissione:

  • EventRateLimit: una funzionalità alpha di Kubernetes
  • AlwaysPullImages: questo controller fornisce una certa protezione per le immagini del registro private nei cluster multitenant non cooperativi, al costo di rendere i registry di immagini un single point of failure per la creazione di nuovi pod nel cluster.
  • SecurityContextDeny: il controller di ammissione della sicurezza dei pod è il preferito ed è disponibile in tutte le versioni di GKE. Se utilizzi GKE Enterprise, puoi anche abilitare l'applicazione degli standard di sicurezza dei pod utilizzando Policy Controller.
  • ImagePolicyWebhook: GKE disabilita ImagePolicyWebhook per impostazione predefinita perché ha meccanismi propri per la gestione e la sicurezza delle immagini. In questo modo GKE può mantenere un controllo più rigoroso sull'ambiente e garantire che le sue pratiche di sicurezza vengano applicate in modo coerente. Tuttavia, puoi utilizzare Autorizzazione binaria o Policy Controller per la gestione dei criteri.
Audit logging GKE acquisisce gli audit log utilizzando il criterio di controllo di GKE. Di conseguenza, non è necessario impostare alcun flag di audit logging del server API Kubernetes.
Debug GKE utilizza la profilazione per il debug.
Crittografia
kubelet
  • GKE abilita la porta di sola lettura kubelet non autenticata.
  • La modalità GKE Standard consente ai carichi di lavoro di modificare i valori predefiniti del kernel, se necessario.
  • GKE limita il numero di eventi Kubernetes nel kubelet per ridurre il rischio di attacchi denial-of-service.
  • GKE utilizza mTLS per proteggere il traffico tra kubelet e server API.
  • GKE ruota i certificati server per impostazione predefinita e ruota i certificati client quando sono abilitati i nodi GKE schermati.
  • GKE utilizza il set di crittografia predefinito consentito per golang, che è anche il valore predefinito per Kubernetes.

Valuta GKE in base ai benchmark CIS

Puoi automatizzare la valutazione dei cluster rispetto ai benchmark utilizzando uno dei seguenti metodi:

  • Benchmark CIS GKE:
    • Versione di GKE Enterprise: utilizza la dashboard Conformità per valutare la conformità di tutti i tuoi cluster al benchmark CIS GKE. Per maggiori dettagli, consulta Informazioni sulla dashboard di conformità di GKE.
    • Tutte le versioni di GKE:
    • Esegui kube-bench per valutare i nodi worker rispetto al benchmark. Per maggiori dettagli, consulta il repository GitHub di kube-bench.
    • Utilizza uno strumento di terze parti come Twistlock Defender per valutare i nodi rispetto al benchmark.
  • Benchmark CIS per Kubernetes: esegui kube-bench per valutare i nodi worker rispetto al benchmark.

Passaggi successivi