Rafforzamento della sicurezza del cluster

Con la velocità di sviluppo di Kubernetes, spesso sono disponibili nuove funzionalità di sicurezza. Questo documento descrive come rafforzare i cluster Google Distributed Cloud.

Questo documento dà la priorità alle mitigazioni di sicurezza di alto valore che richiedono un intervento al momento della creazione del cluster. Le funzionalità meno critiche, le impostazioni predefinite sicure e quelle che possono essere attivate dopo la creazione del cluster sono menzionate più avanti nel documento. Per una panoramica generale degli argomenti sulla sicurezza, consulta Sicurezza.

Elenco di controllo

Il seguente elenco di controllo per il deployment mette in evidenza le best practice per il rafforzamento del deployment della piattaforma dei cluster GKE. Per ulteriori informazioni su ciascuna pratica, consulta le sezioni di questo documento.

Elenco di controllo per il deployment Descrizione
Controllo di identità e accessi

Utilizza i privilegi dell'account vSphere:
Utilizza un account amministratore vSphere con privilegi minimi.

Proteggi Google Cloud gli account di servizio:
Riduci al minimo Google Cloud i privilegi degli account di servizio.

Configura OpenID Connect (OIDC):
Configura OpenID Connect per l'autenticazione degli utenti.

Utilizza gli spazi dei nomi Kubernetes e RBAC per limitare l'accesso:
Utilizza gli spazi dei nomi con RBAC per l'isolamento amministrativo e i ruoli e i diritti del privilegio minimo.

Protezione dei dati

Crittografia delle macchine virtuali vSphere:
imposta vSphere in modo che cripti i volumi utilizzati da Google Distributed Cloud.

Gestisci i secret:
Crittografa i secret inattivi.

Protezione della rete

Limita l'accesso di rete al piano di controllo e ai nodi:
Configura i controlli per isolare e proteggere le reti e i nodi del piano di controllo.

Utilizza i criteri di rete per limitare il traffico:
Implementa i criteri di rete per limitare il traffico all'interno del cluster.

Sicurezza dichiarativa

Utilizza Policy Controller:
installa Policy Controller per i criteri di sicurezza dichiarativi all'interno dei tuoi cluster.

Manutenzione

Esegui l'upgrade di GKE Enterprise:
assicurati di utilizzare la versione più recente di GKE Enterprise per la tua piattaforma.

Monitora i bollettini sulla sicurezza:
consulta i bollettini sulla sicurezza di GKE Enterprise per ricevere i consigli e le indicazioni più recenti sul versionamento.

Monitoraggio e logging

Imposta le opzioni per il logging dei cluster GKE:
assicurati che il logging sia abilitato e integrato in una soluzione SIEM.

Controllo dell'accesso e dell'identità

Questa sezione fornisce informazioni sul controllo dell'accesso ai cluster.

Utilizzare i privilegi dell'account vSphere

L'account utente vCenter che utilizzi per installare Google Distributed Cloud deve disporre di privilegi sufficienti. Ad esempio, un account utente a cui è stato assegnato il ruolo Amministratore di vCenter ha i privilegi per l'accesso completo a tutti gli oggetti vCenter e fornisce un accesso completo a un amministratore del cluster Google Distributed Cloud.

È consigliato seguire il principio del privilegio minimo, concedendo solo i privilegi necessari per installare correttamente GKE Enterprise. Abbiamo predefinito l'insieme minimo di privilegi necessari per eseguire l'installazione, nonché i comandi necessari per concedere queste autorizzazioni.

Account di servizio Google Cloud sicuri

Google Distributed Cloud richiede tre Google Cloud account di servizio:

  • Un account di servizio predefinito per accedere al software Google Distributed Cloud. Viene creato quando acquisti GKE Enterprise.
  • Un account di servizio registrato da utilizzare da Connect per registrare i cluster Google Distributed Cloud con Google Cloud.
  • Un account di servizio Cloud Logging per raccogliere i log del cluster da utilizzare da parte di Cloud Logging.

Durante l'installazione, vincoli i ruoli di Identity and Access Management a questi account di servizio. Questi ruoli concedono agli account di servizio privilegi specifici all'interno del progetto e possono essere generati automaticamente durante l'installazione.

Configurare l'autenticazione per gli utenti del cluster

Per configurare l'autenticazione utente per il cluster, puoi utilizzare OpenID Connect (OIDC) o Lightweight Directory Access Protocol (LDAP).

Per ulteriori informazioni, consulta Servizio di identità GKE.

Utilizzare gli spazi dei nomi e RBAC di Kubernetes per limitare l'accesso

Per concedere ai team l'accesso minimo a Kubernetes, crea spazi dei nomi Kubernetes o cluster specifici per l'ambiente. Assegna centri di costo ed etichette appropriate a ogni spazio dei nomi per responsabilità e riaddebito. Concedi agli sviluppatori solo il livello di accesso ai loro spazi dei nomi necessario per eseguire il deployment e gestire le loro applicazioni, in particolare in produzione.

Mappa le attività che gli utenti devono completare nel cluster e definisci le autorizzazioni richieste per completare ogni attività. Per concedere autorizzazioni a livello di cluster e spazio dei nomi, utilizza Kubernetes RBAC.

Oltre alle autorizzazioni per gli Google Cloud account servizio utilizzati per installare Google Distributed Cloud, IAM non si applica ai cluster Google Distributed Cloud.

Per ulteriori informazioni, consulta la seguente documentazione:

Protezione dei dati

Questa sezione fornisce informazioni sulla protezione dei tuoi dati.

Crittografa le macchine virtuali vSphere

I nodi del cluster Google Distributed Cloud vengono eseguiti su macchine virtuali (VM) nel tuo cluster vSphere. Google consiglia vivamente di criptare tutti i dati at-rest. Per farlo su vSphere, segui la guida alla configurazione e al rafforzamento della sicurezza di VMware vSphere 7 e le indicazioni sulle best practice per la crittografia delle VM.

Questa operazione deve essere eseguita prima dell'installazione di GKE Enterprise.

Gestire i secret

Per fornire un ulteriore livello di protezione per i dati sensibili, come i secret Kubernetes archiviati in etcd, configura un gestore dei secret integrato con i cluster Google Distributed Cloud.

Se esegui carichi di lavoro in più ambienti, potresti preferire una soluzione che funzioni sia per Google Kubernetes Engine sia per Google Distributed Cloud. Se scelgo di utilizzare un gestore dei segreti esterno, come HashiCorp Vault, configuralo prima di integrare i tuoi cluster Google Distributed Cloud.

Hai a disposizione diverse opzioni per la gestione dei secret:

  • Puoi utilizzare Kubernetes Secrets in modo nativo in Google Distributed Cloud. Prevediamo che i cluster utilizzino la crittografia vSphere per le VM, come descritto in precedenza, che fornisce una protezione di base della crittografia a riposo per i secret. Per impostazione predefinita, i secret non vengono sottoposti a crittografia aggiuntiva.
  • Puoi utilizzare un gestore dei secret esterno, ad esempio HashiCorp Vault. Puoi eseguire l'autenticazione su HashiCorp utilizzando un account di servizio Kubernetes o un Google Cloud account di servizio.

Protezione della rete

Questa sezione fornisce informazioni sulla protezione della rete.

Limita l'accesso di rete al control plane e ai nodi

Limita l'esposizione a internet del piano di controllo e dei nodi del cluster. Queste scelte non possono essere modificate dopo la creazione del cluster. Per impostazione predefinita, i nodi del cluster Google Distributed Cloud vengono creati utilizzando indirizzi RFC 1918 e è buona prassi non modificarli. Implementa regole firewall nella rete on-premise per limitare l'accesso al piano di controllo.

Utilizzare i criteri di rete per limitare il traffico

Per impostazione predefinita, tutti i servizi in un cluster Google Distributed Cloud possono comunicare tra loro. Per informazioni su come controllare la comunicazione tra servizi in base alle esigenze dei tuoi carichi di lavoro, consulta le sezioni seguenti.

La limitazione dell'accesso di rete ai servizi rende molto più difficile per gli aggressori spostarsi lateralmente all'interno del cluster e offre ai servizi una certa protezione contro i denial of service accidentali o deliberati. Esistono due modi consigliati per controllare il traffico:

  • Per controllare il traffico L7 verso gli endpoint delle tue applicazioni, utilizza Istio. Scegli questa opzione se ti interessano il bilanciamento del carico, l'autorizzazione dei servizi, il throttling, la quota e le metriche.
  • Per controllare il traffico L4 tra i pod, utilizza i criteri di rete di Kubernetes. Scegli questa opzione se cerchi le funzionalità di controllo dell'accesso di base gestite da Kubernetes.

Puoi abilitare i criteri di rete Istio e Kubernetes dopo aver creato i cluster Google Distributed Cloud. Se necessario, puoi usarli insieme.

Per ulteriori informazioni, consulta la seguente documentazione:

Sicurezza dichiarativa

Questa sezione fornisce consigli per proteggere i cluster.

Utilizzare Policy Controller

I controller di ammissione Kubernetes sono plug-in che regolano e applicano le modalità di utilizzo di un cluster Kubernetes. I controller di ammissione sono una parte importante dell'approccio di difesa in profondità per il rafforzamento del cluster.

La best practice è utilizzare Policy Controller. Policy Controller utilizza il OPA Constraint Framework per descrivere e applicare i criteri come CRD. I vincoli che applichi al tuo cluster sono definiti nei modelli di vincoli, che vengono di cui viene eseguito il deployment nei cluster.

Per informazioni su come utilizzare i vincoli di Policy Controller per ottenere molte delle stesse protezioni di PodSecurityPolicies, con la possibilità aggiuntiva di testare i criteri prima di applicarli, consulta Utilizzare i vincoli per applicare la sicurezza dei pod.

Per ulteriori informazioni, consulta la seguente documentazione:

Limitare la capacità dei carichi di lavoro di automodificarsi

Alcuni carichi di lavoro Kubernetes, in particolare quelli di sistema, hanno l'autorizzazione per automodificarsi. Ad esempio, alcuni carichi di lavoro eseguono la scalabilità automatica verticale. Sebbene sia comodo, questo può consentire a un malintenzionato che ha già compromesso un nodo di eseguire un'ulteriore riassegnazione nel cluster. Ad esempio, un malintenzionato potrebbe modificare un carico di lavoro sul nodo in modo che venga eseguito come account di servizio con privilegi maggiori esistente nello stesso spazio dei nomi.

Idealmente, ai carichi di lavoro non dovrebbe essere concessa l'autorizzazione per modificarsi. Quando è necessaria l'automodifica, puoi limitare le autorizzazioni applicando vincoli di Gatekeeper o Policy Controller, ad esempio NoUpdateServiceAccount dalla libreria open source Gatekeeper, che fornisce diversi criteri di sicurezza utili.

Quando esegui il deployment dei criteri, in genere è necessario consentire ai controller che gestiscono il ciclo di vita del cluster di bypassare i criteri e le pipeline di logging e monitoraggio. Questo è necessario affinché i controller possano apportare modifiche al cluster, ad esempio applicare gli upgrade del cluster. Ad esempio, se esegui il deployment del criterio NoUpdateServiceAccount su Google Distributed Cloud, devi impostare i seguenti parametri in Constraint:

parameters:
  allowedGroups:
  - system:masters
  allowedUsers:
  - system:serviceaccount:kube-system:monitoring-operator
  - system:serviceaccount:kube-system:stackdriver-operator
  - system:serviceaccount:kube-system:metrics-server-operator
  - system:serviceaccount:kube-system:logmon-operator

Manutenzione

Questa sezione fornisce informazioni sulla manutenzione dei cluster.

Eseguire l'upgrade di GKE Enterprise

Kubernetes introduce regolarmente nuove funzionalità di sicurezza e fornisce patch di sicurezza.

Sei responsabile dell'aggiornamento dei tuoi cluster Google Distributed Cloud. Per ogni release, consulta le note di rilascio. Inoltre, pianifica di eseguire l'aggiornamento alle nuove release delle patch ogni mese e alle versioni minori ogni tre mesi. Scopri come eseguire l'upgrade dei cluster.

Sei inoltre responsabile dell'upgrade e della protezione dell'infrastruttura vSphere:

Monitorare i bollettini sulla sicurezza

Il team di sicurezza di GKE Enterprise pubblica bollettini sulla sicurezza per le vulnerabilità di gravità elevata e critica.

Questi bollettini seguono uno schema di Google Cloud numerazione delle vulnerabilità Google Cloud comune e sono collegati dalla pagina principale dei bollettini Google Cloud e dalle note di rilascio di Google Distributed Cloud. Ogni pagina del bollettino sulla sicurezza ha un feed RSS a cui gli utenti possono iscriversi per ricevere gli aggiornamenti.

Quando è necessaria un'azione da parte del cliente per risolvere queste vulnerabilità gravi e critiche, Google contatta i clienti via email. Inoltre, Google potrebbe anche contattare i clienti con contratti di assistenza tramite i canali di assistenza.

Per ulteriori informazioni, consulta la seguente documentazione:

Monitoraggio e logging

Google Distributed Cloud include più opzioni per il logging e il monitoraggio dei cluster, tra cui servizi gestiti basati su cloud, strumenti open source e compatibilità convalidata con soluzioni commerciali di terze parti:

  • Cloud Logging e Cloud Monitoring, abilitati da agenti in-cluster implementati con Google Distributed Cloud
  • Configurazioni convalidate con soluzioni di terze parti

Qualunque sia la soluzione di logging che scegli in base ai requisiti aziendali, ti consigliamo vivamente di registrare gli avvisi e gli eventi pertinenti in un servizio SIEM (Security Information and Event Management) centralizzato per la gestione degli incidenti di sicurezza.

Per ulteriori informazioni, consulta la seguente documentazione: