Con la velocità di sviluppo in Kubernetes, spesso ci sono nuove le funzionalità di machine learning. Questo documento descrive come rafforzare i cluster Google Distributed Cloud.
Questo documento dà la priorità alle misure di mitigazione della sicurezza di alto valore che richiedono al momento della creazione del cluster. Le funzionalità meno critiche, le impostazioni sicure per impostazione predefinita e quelle che possono essere attivate dopo la creazione del cluster sono menzionate più avanti nel documento. Per una panoramica generale degli argomenti relativi alla 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: Proteggi gli account di servizio Google Cloud: Configura OpenID Connect (OIDC): Utilizza gli spazi dei nomi Kubernetes e RBAC per limitare l'accesso: |
| Protezione dei dati | Cripta le macchine virtuali vSphere: Gestisci i secret: |
| Protezione della rete | Limita l'accesso di rete al piano di controllo e ai nodi: Utilizza i criteri di rete per limitare il traffico: |
| Sicurezza dichiarativa | Utilizza Policy Controller: |
| Manutenzione | Esegui l'upgrade di GKE Enterprise: Monitora i bollettini sulla sicurezza: |
| Monitoraggio e logging | Imposta le opzioni per il logging dei cluster GKE: |
Controllo dell'identità e dell'accesso
Questa sezione fornisce informazioni sul controllo dell'accesso ai cluster.
Utilizza 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 è 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.
Il principio del privilegio minimo è consigliata, concedendo solo i privilegi necessari per installare correttamente con GKE Enterprise. Abbiamo predefinito l'insieme minimo di privilegi necessari per eseguire l'installazione, nonché i comandi necessari per concedere queste autorizzazioni.
Proteggere gli account di servizio Google Cloud
Google Distributed Cloud richiede tre servizi Google Cloud account:
- Un account di servizio predefinito per accedere 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 in Google Cloud.
- Un account di servizio Cloud Logging per la raccolta dei log del cluster che devono essere utilizzati da 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 generate 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 di cui hanno bisogno per eseguire il deployment e gestire le loro applicazioni, in particolare in produzione.
Mappa le attività che gli utenti devono completare rispetto al cluster e definisci autorizzazioni necessarie per completare ogni attività. Per concedere autorizzazioni a livello di cluster e spazio dei nomi, utilizza Kubernetes RBAC.
Oltre alle autorizzazioni per gli account servizio Google Cloud 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 dati.
Cripta 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 su e riposare. 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, ad esempio Kubernetes Secret archiviati in etcd, configurare un Secret Manager integrato con Google Distributed Cloud cluster.
Se esegui carichi di lavoro in più ambienti, potresti preferire una che funziona sia per Google Kubernetes Engine che 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 i secret di Kubernetes in modo nativo Google Distributed Cloud. Prevediamo che i cluster utilizzino vSphere la crittografia per le VM come descritto in precedenza, che fornisce la crittografia at-rest per i secret. Per impostazione predefinita, i secret non vengono sottoposti a crittografia aggiuntiva.
- Puoi utilizzare un gestore dei secret esterno, come HashiCorp Vault. Puoi autenticarti su HashiCorp utilizzando un account di servizio Kubernetes o un account di servizio Google Cloud.
Per ulteriori informazioni, consulta la seguente documentazione:
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 dei cluster Google Distributed Cloud vengono creati negli indirizzi RFC 1918 e è una best practice di non modificare questo valore. 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 comunicare tra loro. Per informazioni sul controllo Comunicazione da service-to-service in base alle esigenze dei tuoi carichi di lavoro, vedi quanto segue sezioni.
Limitare l'accesso di rete ai servizi complica molto agli aggressori di muoversi lateralmente all'interno del cluster e offre ai servizi una protezione contro denial of service accidentale o deliberato. Esistono due metodi metodi consigliati per controllare il traffico:
- Per controllare il traffico L7 verso le applicazioni utilizzare endpoint di Google, utilizzare 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 stai cercando le funzionalità di base per il controllo dell'accesso gestiti da Kubernetes.
Puoi abilitare sia il criterio di rete Istio che quello di Kubernetes dopo aver creato il tuo di Google Distributed Cloud. Potete utilizzarli insieme se avete bisogno di a.
Per ulteriori informazioni, consulta la seguente documentazione:
Sicurezza dichiarativa
Questa sezione fornisce suggerimenti per la protezione dei cluster.
Utilizza 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 framework di vincoli OPA per descrivere e applicare i criteri come CRD. I vincoli che applichi ai criteri sono definiti in modelli di vincolo, il cui deployment viene eseguito cluster.
Per informazioni su come usare i vincoli di Policy Controller per ottenere delle stesse protezioni PodSecurityPolicies, con la possibilità di testare i criteri prima di applicarli, consulta Utilizzare i vincoli per applicare i pod sicurezza.
Per saperne di più, consulta la seguente documentazione:
Limitare la possibilità di automodifica dei carichi di lavoro
Alcuni carichi di lavoro Kubernetes, in particolare quelli di sistema, hanno l'autorizzazione si automodifica. Ad esempio, alcuni carichi di lavoro si adeguano automaticamente verticalmente. 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 utente malintenzionato potrebbe avere sul nodo stesso cambia in modo che venga eseguito come un account di servizio con privilegi nello stesso spazio dei nomi.
Idealmente, ai carichi di lavoro non dovrebbe essere concessa l'autorizzazione in primo luogo. Quando è necessaria l'automodifica, puoi limitare le autorizzazioni applicando vincoli di Gatekeeper o Policy Controller, come NoUpdateServiceAccount dalla libreria open source Gatekeeper, che offre diversi criteri.
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. Questa operazione è necessaria per consentire ai controller di apportare modifiche
al cluster, ad esempio applicando upgrade del cluster. Ad esempio, se esegui il deployment
il criterio NoUpdateServiceAccount su Google Distributed Cloud, devi impostare il
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.
Esegui l'upgrade di GKE Enterprise
Kubernetes introduce regolarmente nuove funzionalità di sicurezza e fornisce patch di sicurezza.
È tua responsabilità mantenere aggiornati i cluster Google Distributed Cloud ad oggi. Per ogni release, esamina il 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 di vSphere dell'infrastruttura:
- Stabilire un processo per applicare patch e upgrade delle tue VM
- Resta al passo con le ultime novità sulla sicurezza VMware avvertenze
- Segui le indicazioni per l'applicazione delle patch agli host
Monitorare i bollettini sulla sicurezza
Il team di sicurezza di GKE Enterprise pubblica bollettini sulla sicurezza per le vulnerabilità con gravità elevata e critica.
Questi bollettini seguono una numerazione comune di vulnerabilità di Google Cloud e sono collegati dalla pagina principale dei bollettini Google Cloud e Note di rilascio di Google Distributed Cloud. Ogni pagina del bollettino sulla sicurezza include Feed RSS a cui gli utenti possono iscriversi per ricevere aggiornamenti.
Quando è necessario un intervento del cliente per far fronte a questi aspetti critici e vulnerabilità, Google contatta i clienti via email. Inoltre, Google potrebbe contatta anche i clienti con contratti di assistenza tramite i canali di assistenza.
Per saperne di più, consulta la seguente documentazione:
Monitoraggio e logging
Google Distributed Cloud include diverse opzioni per il logging dei cluster e il monitoraggio, inclusi servizi gestiti basati su cloud, strumenti open source e compatibilità convalidata con soluzioni commerciali di terze parti:
- Cloud Logging e Cloud Monitoring, abilitati dagli agenti nel cluster distribuito con Google Distributed Cloud
- Configurazioni convalidate con soluzioni di terze parti
Qualunque sia la soluzione di logging scelta 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 saperne di più, consulta la seguente documentazione:
- Logging e monitoraggio
- Utilizzo del logging e del monitoraggio
- Logging e monitoraggio delle applicazioni
- Monitoraggio di Google Distributed Cloud con lo stack Elastic
- Raccogliere i log su GKE Enterprise con Splunk Connect