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 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 Kubernetes open source. Ha lo scopo di fornire indicazioni per una varietà di implementazioni Kubernetes self-managed e ospitate.
  • Benchmark CIS GKE: stabilisce linee guida per la configurazione sicura dei componenti che puoi controllare nei cluster GKE. Include consigli 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 consigli 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 consigli.

Altri benchmark che si applicano a GKE

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

  • Il piano di controllo, incluse le VM del piano di controllo, il server API e componenti come il database dello 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 modificarli o valutarli rispetto ai controlli del benchmark CIS corrispondenti. Tuttavia, puoi valutare e correggere tutti i controlli del benchmark CIS che si applicano ai nodi worker e ai carichi di lavoro. In base al modello di responsabilità condivisa di 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 piano di controllo e siamo responsabili della protezione della configurazione dei componenti del piano di controllo. 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.
  • Alcuni componenti del control plane vengono sottoposti a bootstrap 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 disabilita i seguenti controller di ammissione:

  • EventRateLimit: si tratta di una funzionalità alpha di Kubernetes
  • AlwaysPullImages: questo controller fornisce una certa protezione per le immagini del registro privato nei cluster multi-tenant non cooperativi, al costo di rendere i registri delle immagini un singolo punto di errore per la creazione di nuovi pod nel cluster.
  • SecurityContextDeny: Il controller di ammissione alla sicurezza dei pod è preferibile ed è disponibile in tutte le edizioni di GKE. 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 audit 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
etcd

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

  • etcd: il cluster esegue le istanze etcd sul piano di controllo.
  • Spanner: GKE archivia lo stato del cluster in un database basato su Spanner separato dalle VM del piano di controllo.

Tutti i cluster GKE pubblicano l'API etcd nelle VM del piano di controllo. Tutte le interazioni client con l'API Kubernetes sono le stesse di Kubernetes open source. A seconda della tecnologia di database che funge da backend per l'API etcd nel cluster, potresti notare discrepanze in qualsiasi punteggio relativo a etcd nel benchmark CIS Kubernetes open source.
kubelet

Valutare GKE rispetto ai benchmark CIS

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

  • Benchmark CIS GKE:
    • Esegui kube-bench per valutare i nodi worker rispetto al benchmark. Per maggiori dettagli, consulta il repository GitHub kube-bench.
    • Utilizza uno strumento di terze parti come Twistlock Defender per valutare i nodi rispetto al benchmark.
  • Benchmark CIS Kubernetes: esegui kube-bench per valutare i nodi worker rispetto al benchmark. Non puoi valutare il piano di controllo gestito rispetto a questi consigli nel benchmark.

Passaggi successivi