Data la velocità di sviluppo in Kubernetes, spesso sono disponibili nuove funzionalità di sicurezza. Questo documento descrive come migliorare la protezione dei cluster Google Distributed Cloud.
Questo documento dà la priorità alle mitigazioni della sicurezza di alto valore che richiedono un tuo intervento al momento della creazione del cluster. Le funzionalità meno critiche, le impostazioni sicure per impostazione predefinita e quelle che possono essere abilitate dopo la creazione del cluster sono indicate 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 evidenzia le best practice per la protezione del deployment della piattaforma dei cluster GKE. Per ulteriori informazioni su ogni esercitazione, vedi le sezioni di questo documento.
| Elenco di controllo del deployment | Descrizione |
|---|---|
| Controllo di identità e accessi | Utilizza i privilegi dell'account vSphere: Proteggere 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 su come controllare l'accesso ai cluster.
Utilizza i privilegi dell'account vSphere
L'account utente vCenter che utilizzi per installare Google Distributed Cloud deve avere privilegi sufficienti. Ad esempio, un account utente a cui è assegnato il ruolo di amministratore di vCenter dispone dei privilegi per l'accesso completo a tutti gli oggetti vCenter e fornisce l'accesso completo a un amministratore di cluster Google Distributed Cloud.
Si consiglia il principio del privilegio minimo, che concede solo i privilegi necessari per installare correttamente GKE Enterprise. Abbiamo predefinito un 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 account di servizio Google Cloud:
- Un account di servizio predefinito per accedere al software Google Distributed Cloud. Lo crei al momento dell'acquisto di GKE Enterprise.
- Un account di servizio registrato che Connect deve utilizzare per registrare i cluster Google Distributed Cloud con Google Cloud.
- Un account di servizio Cloud Logging per la raccolta dei log del cluster che verranno utilizzati da Cloud Logging.
Durante l'installazione, associa i ruoli 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 durante l'installazione.
Configura l'autenticazione per gli utenti del cluster
Per configurare l'autenticazione utente per il tuo cluster, puoi utilizzare OpenID Connect (OIDC) o Lightweight Directory Access Protocol (LDAP).
Per ulteriori informazioni, vedi Servizio di identità GKE.
Utilizza gli spazi dei nomi Kubernetes e RBAC per limitare l'accesso
Per concedere ai team l'accesso minimo a Kubernetes, crea spazi dei nomi Kubernetes o cluster specifici dell'ambiente. Assegna centri di costo ed etichette appropriate a ciascun spazio dei nomi per responsabilità e storno di addebito. Concedi agli sviluppatori solo il livello di accesso agli spazi dei nomi necessario per il deployment e la gestione delle applicazioni, soprattutto in produzione.
Mappa le attività che gli utenti devono completare rispetto al cluster e definisci le autorizzazioni necessarie per completare ciascuna attività. Per concedere autorizzazioni a livello di cluster e spazio dei nomi, utilizza Kubernetes RBAC.
Oltre alle autorizzazioni per gli account di servizio Google Cloud utilizzate per installare Google Distributed Cloud, IAM non si applica ai cluster Google Distributed Cloud.
Per saperne di più, consulta la seguente documentazione:
Protezione dei dati
Questa sezione fornisce informazioni sulla protezione dei dati.
Cripta le macchine virtuali vSphere
I nodi dei 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 protezione 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.
Gestisci i secret
Per fornire un ulteriore livello di protezione per i dati sensibili, ad esempio i secret di Kubernetes archiviati in etcd, configura un Secret Manager 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 che per Google Distributed Cloud. Se scegli di utilizzare un gestore di secret esterno, ad esempio HashiCorp Vault, configuralo prima di integrare i cluster Google Distributed Cloud.
Hai a disposizione diverse opzioni per la gestione dei secret:
- Puoi utilizzare i secret di Kubernetes 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 dalla crittografia at-rest per i secret. I secret non sono ulteriormente criptati per impostazione predefinita.
- Puoi utilizzare un Secret Manager esterno, come HashiCorp Vault. Puoi eseguire l'autenticazione in HashiCorp utilizzando un account di servizio Kubernetes o un account di servizio Google Cloud.
Per saperne di più, consulta la seguente documentazione:
Protezione della rete
Questa sezione fornisce informazioni sulla protezione della rete.
Limita l'accesso di rete al piano di controllo 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 utilizzando indirizzi RFC 1918 ed è consigliabile non modificare questa impostazione. 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 Service-to-Service in base alle esigenze dei tuoi carichi di lavoro, consulta le sezioni seguenti.
Limitare l'accesso di rete ai servizi rende molto più difficile per gli aggressori muoversi lateralmente all'interno del cluster e offre ai servizi una certa protezione contro il denial of service accidentale o intenzionale. 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 bilanciamento del carico, autorizzazione del servizio, limitazione, quota e 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 controllo dell'accesso di base gestite da Kubernetes.
Puoi abilitare i criteri di rete Istio e Kubernetes dopo aver creato i tuoi cluster Google Distributed Cloud. Se necessario, potete usarli insieme.
Per saperne di più, 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 della difesa in profondità per rafforzare il cluster.
La best practice consiste nell'utilizzare Policy Controller. Policy Controller utilizza il framework dei vincoli di OPA per descrivere e applicare i criteri come CRD. I vincoli che applichi al cluster sono definiti nei modelli di vincolo 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 Utilizzo dei vincoli per applicare la sicurezza dei pod.
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 per la modifica automatica. Ad esempio, alcuni carichi di lavoro si adeguano automaticamente verticalmente. Anche se conveniente, questo può consentire a un utente malintenzionato che ha già compromesso un nodo di scalare ulteriormente nel cluster. Ad esempio, un utente malintenzionato potrebbe far cambiare il carico di lavoro sul nodo in modo che venga eseguito come account di servizio con privilegi più elevati che esiste nello stesso spazio dei nomi.
Idealmente, ai carichi di lavoro non dovrebbe essere concessa l'autorizzazione a modificare se stessi. 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 ignorare i criteri e le pipeline di logging e monitoraggio. Ciò è necessario affinché i controller possano apportare modifiche al cluster, ad esempio applicandone gli upgrade. Ad esempio, se esegui il deployment del criterio NoUpdateServiceAccount su Google Distributed Cloud, devi impostare i parametri seguenti 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. Per ogni release, consulta le note di rilascio. Inoltre, prevedi di eseguire l'aggiornamento alle nuove patch ogni mese e alle versioni secondarie ogni tre mesi. Scopri come eseguire l'upgrade dei cluster.
Sei inoltre responsabile dell'upgrade e della protezione dell'infrastruttura vSphere:
- Stabilisci un processo per eseguire patch e upgrade tempestivi delle VM
- Resta al passo con le ultime consigli sulla sicurezza VMware
- Segui le indicazioni sull'applicazione di patch agli host
Monitorare i bollettini sulla sicurezza
Il team di sicurezza di GKE Enterprise pubblica bollettini sulla sicurezza per le vulnerabilità con gravità alta e critica.
Questi bollettini seguono uno schema comune di numerazione delle vulnerabilità di Google Cloud 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 che consente agli utenti di iscriversi agli aggiornamenti.
Quando è necessario un intervento da parte del cliente per affrontare queste vulnerabilità elevato e critico, Google contatta i clienti via email. Inoltre, Google potrebbe anche contattare 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 e il monitoraggio dei cluster, tra cui servizi gestiti basati su cloud, strumenti open source e compatibilità comprovata con soluzioni commerciali di terze parti:
- Cloud Logging e Cloud Monitoring, abilitati dagli agenti nel cluster distribuiti con Google Distributed Cloud
- Configurazioni convalidate con soluzioni di terze parti
Qualunque soluzione di logging tu scelga in base ai requisiti aziendali, consigliamo vivamente di registrare eventi e avvisi rilevanti per il futuro in un servizio centralizzato di gestione degli eventi e delle informazioni di sicurezza (SIEM) 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 Elastic Stack
- Raccogli i log su GKE Enterprise con Splunk Connect