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 per GKE. Questa pagina include le seguenti informazioni:

  • Come configuriamo il control plane GKE gestito in modo che sia conforme al benchmark CIS Kubernetes
  • Come configurare i nodi e i carichi di lavoro GKE in modo che siano conformi al benchmark CIS Google Kubernetes Engine (GKE)

Informazioni sui benchmark CIS

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

  • Benchmark CIS Kubernetes: si applica al progetto open source Kubernetes. Lo scopo è fornire indicazioni per una serie di implementazioni di Kubernetes autogestite e ospitate.
  • Benchmark CIS GKE: stabilisce 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 benchmark CIS GKE, perché è specifico per GKE su Google Cloud. Il benchmark CIS 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 Kubernetes open source e potrebbero comportare conflitti con questi suggerimenti.

Altri benchmark applicabili a GKE

Oltre al benchmark CIS GKE e al benchmark CIS Kubernetes, ai sistemi operativi disponibili in GKE si applicano i seguenti benchmark. Anche se un benchmark del sistema operativo specifico non riguarda esplicitamente l'utilizzo di Kubernetes, devi comunque farvi riferimento per 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 GKE, gestiamo per te i seguenti componenti:

  • Il control plane, incluse le VM del control plane, il server API e i componenti come il database di stato del cluster (basato su etcd o Spanner), kube-controller-manager e kube-scheduler.
  • Il sistema operativo del nodo.

Questi componenti esistono in un progetto di proprietà di GKE, quindi non puoi modificare o valutare nessuno di questi componenti in base ai controlli del benchmark CIS corrispondenti. Tuttavia, puoi valutare e correggere i controlli CIS Benchmark che si applicano ai nodi worker e ai carichi di lavoro. In base al modello di responsabilità condivisa GKE, questi componenti sono di tua responsabilità.

Il nostro approccio alla protezione di GKE per il benchmark CIS

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

Approccio alla sicurezza di GKE
Autenticazione
  • Alcuni componenti di monitoraggio GKE utilizzano l'autenticazione anonima per ottenere le metriche.
  • Alcuni componenti del control plane vengono avviati utilizzando token statici, che vengono poi utilizzati per l'autenticazione al server API. Questi token vengono generati ogni volta che una VM viene avviata o riavviata.
Controller di ammissione

GKE disattiva i seguenti controller di ammissione:

  • EventRateLimit: questa è una funzionalità alpha di Kubernetes
  • AlwaysPullImages: questo controller fornisce una certa protezione per le immagini del registro privato nei cluster multitenant non cooperativi, al costo di rendere i registri delle immagini un unico punto di errore per la creazione di nuovi pod nel cluster.
  • SecurityContextDeny: il controller di ammissione Pod Security è 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é dispone di meccanismi propri per la gestione e la sicurezza delle immagini. In questo modo, GKE mantiene un controllo più rigoroso sull'ambiente e garantisce 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 GKE. Di conseguenza, non è necessario impostare alcun flag di audit logging del server API Kubernetes.
Debug GKE utilizza la profilazione per il debug.
Crittografia
etcd

In Kubernetes open source, il database dello stato del cluster utilizza etcd. In GKE, il database di backend che memorizza lo stato del cluster è una delle seguenti tecnologie:

  • etcd: il cluster esegue istanze etcd sul control plane.
  • Spanner: GKE archivia lo stato del cluster in un database basato su Spanner separato dalle VM del control plane.

Tutti i cluster GKE pubblicano l'API etcd nelle VM del control plane. Qualsiasi interazione del client con l'API Kubernetes è la stessa di Kubernetes open source. A seconda della tecnologia di database che funge da backend per l'API etcd nel tuo cluster, potresti notare discrepanze in qualsiasi punteggio correlato a etcd nel benchmark CIS Kubernetes open source.
kubelet
  • GKE abilita la porta di sola lettura kubelet non autenticata. Puoi disattivare la porta impostando --no-autoprovisioning-enable-insecure-kubelet-readonly-port. La porta di sola lettura verrà disattivata per impostazione predefinita in una release futura dopo avervi concesso un po' di tempo per la migrazione.
  • 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 in kubelet per ridurre il rischio di attacchi Denial of Service.
  • GKE utilizza mTLS per proteggere il traffico tra kubelet e il server API.
  • GKE ruota i certificati del server per impostazione predefinita e ruota i certificati client quando sono abilitati i nodi GKE schermati.
  • GKE utilizza il set di cifrari consentiti predefinito di Go, che è anche il valore predefinito per Kubernetes.

Valuta GKE in base ai benchmark CIS

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

  • Benchmark CIS GKE:

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

  • Benchmark CIS Kubernetes: esegui kube-bench per valutare i nodi worker rispetto al benchmark. Non puoi valutare il piano di controllo gestito in base a questi suggerimenti nel benchmark.

Passaggi successivi