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 Kubernetes CIS
  • Come configurare i nodi e i carichi di lavoro GKE in modo che rispettino il 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 autogestite e ospitate.
  • CIS GKE Benchmark: stabilisce linee guida per la configurazione sicura di componenti che puoi controllare nei cluster GKE. Sono inclusi consigli specifici per GKE su Google Cloud.

Ti consigliamo di dare la priorità al benchmark CIS GKE, in quanto è specifico per GKE su Google Cloud. Il benchmark Kubernetes CIS contiene molti consigli per i controlli che non puoi visualizzare o modificare in GKE. Il nostro approccio alla sicurezza del cluster include misure di mitigazione che vanno oltre lo scopo del benchmark Kubernetes open source e potrebbero comportare conflitti con questi consigli.

Altri benchmark che si applicano a GKE

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

Il runtime del contenitore 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 piano di controllo, incluse 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 in base ai controlli del benchmark CIS corrispondenti. Tuttavia, puoi valutare e correggere eventuali controlli del benchmark CIS che si applicano ai tuoi nodi worker e ai tuoi 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 piano di controllo e siamo responsabili della protezione della configurazione dei relativi componenti. 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. GKE consente l'autenticazione anonima per kubelet, ma questa esposizione è identica alla porta di sola lettura perché disattiviamo gestori di debug aggiuntivi.
  • Alcuni componenti del piano di controllo 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.
Controllori di ammissione

GKE disattiva 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, a costo di rendere i registry delle immagini un punto di errore singolo per la creazione di nuovi pod nel cluster.
  • SecurityContextDeny: il controller di ammissione di sicurezza dei pod è preferito ed è disponibile in tutte le versioni di GKE. Se utilizzi GKE Enterprise, puoi anche attivare l'applicazione obbligatoria degli standard di sicurezza dei pod utilizzando Policy Controller.
  • ImagePolicyWebhook: GKE disattiva ImagePolicyWebhook per impostazione predefinita perché dispone di propri meccanismi 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 GKE. Di conseguenza, non è necessario impostare i flag di registrazione degli audit del server dell'API Kubernetes.
Debug GKE utilizza il profiling per il debug.
Crittografia
kubelet
  • GKE abilita la porta di sola lettura di 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 che avrai avuto il tempo di eseguire la migrazione.
  • La modalità GKE Standard consente ai carichi di lavoro di modificare le impostazioni predefinite del kernel, se necessario.
  • GKE limita il numero di eventi Kubernetes nel kubelet per ridurre il rischio di attacchi di denial-of-service.
  • GKE utilizza mTLS per proteggere il traffico tra il kubelet e il server API.
  • GKE esegue la rotazione dei certificati del server per impostazione predefinita e dei certificati client quando è abilitato Shielded GKE Nodes.
  • GKE utilizza l'insieme di crittografi consentiti predefiniti di Golang, che è anche quello predefinito per Kubernetes.

Valutare GKE in base ai benchmark CIS

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

  • CIS GKE Benchmark:

    • 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 in base al benchmark.
    • Versione GKE Enterprise: utilizza la dashboard Conformità per valutare la conformità di tutti i tuoi cluster al benchmark GKE CIS. 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 consigli nel benchmark.

Passaggi successivi