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 per conformarlo al benchmark CIS Kubernetes
  • Come configurare i nodi e i workload GKE per la conformità 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:

  • CIS Kubernetes Benchmark: si applica al progetto Kubernetes open source. Fornisce indicazioni per una serie di implementazioni di Kubernetes self-managed e in hosting.
  • Benchmark CIS GKE: 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 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 entrare in conflitto con questi suggerimenti.

Altri benchmark applicabili a GKE

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

  • Il control plane, incluse le VM del control plane, il server API e i componenti come il database dello stato del cluster (etcd o basato su Spanner), 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 in base ai controlli del benchmark CIS corrispondenti. Tuttavia, puoi valutare e correggere eventuali controlli dei benchmark CIS che si applicano ai nodi worker e ai workload. 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. Noi 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 di 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 disabilita i seguenti controller di ammissione:

  • EventRateLimit: si tratta di una funzionalità alfa di Kubernetes
  • AlwaysPullImages: questo controller fornisce una certa protezione per le immagini dei registry privati in cluster multi-tenant non cooperativi, al costo di rendere i registry delle immagini un single point of failure per la creazione di nuovi pod nel cluster.
  • SecurityContextDeny: il controller Pod Security Admission è preferibile ed è disponibile in tutte le versioni di GKE. 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 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 delle policy.
Audit logging GKE acquisisce gli audit log utilizzando la policy 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 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 gestiscono l'API etcd nelle VM del control plane. Le interazioni dei 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 tuo cluster, potresti notare discrepanze nei punteggi relativi 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 aver concesso un po' di tempo per la migrazione.
  • La modalità GKE Standard consente ai workload di modificare le impostazioni predefinite 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 il kubelet e il server API.
  • GKE ruota i certificati server per impostazione predefinita e ruota i certificati client quando Shielded GKE Nodes è abilitato.
  • GKE utilizza il set di crittografia consentito predefinito di golang, che è anche l'impostazione predefinita per Kubernetes.

Valuta GKE rispetto ai benchmark CIS

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

  • Benchmark CIS 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.
  • Benchmark CIS Kubernetes: esegui kube-bench per valutare i nodi worker rispetto al benchmark. Non puoi valutare il control plane gestito in base a questi suggerimenti nel benchmark.

Passaggi successivi