Con la velocità di sviluppo in Kubernetes, spesso esistono nuove funzionalità di sicurezza che puoi utilizzare. Questo documento descrive come rafforzare la protezione dei cluster GKE su VMware.
Questo documento dà la priorità alle mitigazioni di sicurezza di alto valore che richiedono un'azione da parte tua 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 menzionati 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 evidenzia le best practice per la protezione del deployment della piattaforma dei cluster GKE. Per ulteriori informazioni su ciascuna esercitazione, consulta le sezioni di questo documento.
| Elenco di controllo del deployment | Descrizione |
|---|---|
| Controllo di identità e accesso | Utilizza i privilegi dell'account vSphere: Account di servizio Google Cloud sicuri: 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
Utilizza i privilegi dell'account vSphere
L'account utente vCenter che utilizzi per installare GKE su VMware deve avere privilegi sufficienti. Ad esempio, un account utente a cui è assegnato il ruolo Amministratore di vCenter dispone dei privilegi per l'accesso completo a tutti gli oggetti vCenter e fornisce a un amministratore del cluster GKE su VMware l'accesso completo.
Ti consigliamo il principio del privilegio minimo, che concede 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.
Proteggere gli account di servizio Google Cloud
GKE su VMware richiede tre account di servizio Google Cloud:
- Un account di servizio predefinito per l'accesso al software GKE su VMware. Puoi crearlo quando acquisti GKE Enterprise.
- Un account di servizio per la registrazione che deve essere utilizzato da Connect per la registrazione di GKE su cluster VMware con Google Cloud.
- Un account di servizio Cloud Logging per la raccolta dei log del cluster per l'utilizzo da parte di Cloud Logging.
Durante l'installazione, associ 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.
Configura 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 saperne di più, consulta GKE Identity Service.
Usa gli spazi dei nomi Kubernetes e RBAC per limitare l'accesso
Per concedere ai team l'accesso minimo a Kubernetes, crea spazi dei nomi o cluster specifici per l'ambiente. Assegna i centri di costo e le etichette appropriate a ogni spazio dei nomi per responsabilità e storno di addebito. Fornisci agli sviluppatori solo il livello di accesso ai loro spazi dei nomi di cui hanno bisogno per eseguire il deployment e gestire le applicazioni, soprattutto in produzione.
Mappa le attività che gli utenti devono completare sul cluster e definisci le autorizzazioni necessarie per completare ogni attività. Per concedere autorizzazioni a livello di cluster e di spazio dei nomi, utilizza Kubernetes RBAC.
Oltre alle autorizzazioni per gli account di servizio Google Cloud utilizzate per installare GKE su VMware, IAM non si applica ai cluster GKE su VMware.
Per ulteriori informazioni, consulta la seguente documentazione:
Protezione dei dati
Cripta le macchine virtuali vSphere
I nodi dei cluster GKE su VMware vengono eseguiti su macchine virtuali (VM) nel 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 di installare GKE Enterprise.
Gestisci secret
Per fornire un ulteriore livello di protezione per i dati sensibili, come i secret di Kubernetes archiviati in etcd, configura un gestore dei secret integrato con i cluster GKE su VMware.
Se esegui carichi di lavoro in più ambienti, potresti preferire una soluzione adatta sia per Google Kubernetes Engine che per GKE su VMware. Se scegli di utilizzare un gestore dei secret esterno, ad esempio HashiCorp Vault, configuralo prima di integrare i tuoi cluster GKE su VMware.
Hai a disposizione diverse opzioni per la gestione dei secret:
- Puoi utilizzare i secret di Kubernetes in modo nativo in GKE su VMware. Prevediamo che i cluster utilizzino la crittografia vSphere per le VM, come descritto in precedenza, che offre una protezione di base dalla crittografia at-rest per i secret. I secret non vengono ulteriormente criptati per impostazione predefinita.
- Puoi utilizzare un gestore dei secret esterno, ad esempio HashiCorp Vault. Puoi eseguire l'autenticazione in HashiCorp utilizzando un account di servizio Kubernetes o un account di servizio Google Cloud.
Per ulteriori informazioni, consulta la seguente documentazione:
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 GKE su VMware vengono creati utilizzando indirizzi RFC 1918 ed è consigliabile non modificare questa impostazione. Implementa regole firewall nella tua 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 GKE su VMware possono comunicare tra loro. Per informazioni sul controllo della comunicazione service-to-service in base alle esigenze dei tuoi carichi di lavoro, consulta le sezioni seguenti.
Limitare l'accesso alla rete ai servizi rende molto più difficile per gli utenti malintenzionati spostarsi lateralmente all'interno del cluster e offre ai servizi una certa protezione da 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 dei servizi, 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 la funzionalità di controllo dell'accesso di base gestita da Kubernetes.
Puoi abilitare i criteri di rete sia Istio sia Kubernetes dopo aver creato i tuoi cluster GKE su VMware. Se necessario, potete usarli insieme.
Per ulteriori informazioni, consulta la seguente documentazione:
Sicurezza dichiarativa
Utilizzo di Policy Controller
I controller di ammissione di Kubernetes sono plug-in che regolano e applicano il modo in cui viene utilizzato un cluster Kubernetes. I controller di ammissione sono una parte importante dell'approccio di difesa in profondità alla protezione del cluster.
La best practice prevede l'utilizzo di Policy Controller. Policy Controller utilizza il framework del vincolo 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 Utilizzare i vincoli per applicare la sicurezza dei pod.
Per ulteriori informazioni, consulta la seguente documentazione:
Limita la capacità dei carichi di lavoro di auto-modificarsi
Alcuni carichi di lavoro Kubernetes, in particolare quelli di sistema, hanno l'autorizzazione alla modifica automatica. Ad esempio, alcuni carichi di lavoro scalano automaticamente verticalmente. Sebbene sia pratico, questo può consentire a un utente malintenzionato che ha già compromesso un nodo di eseguire un'ulteriore scalabilità nel cluster. Ad esempio, un utente malintenzionato potrebbe gestire automaticamente un 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 per modificare autonomamente. Se è necessaria l'automodifica, puoi limitare le autorizzazioni applicando i vincoli Gatekeeper o Policy Controller, ad esempio NoUpdateServiceAccount dalla libreria Gatekeeper open source, che offre 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. Questa operazione è necessaria per consentire ai controller
di apportare modifiche al cluster, ad esempio applicare upgrade del cluster. Ad esempio, se esegui il deployment del criterio NoUpdateServiceAccount su GKE su VMware, 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
Esegui l'upgrade di GKE Enterprise
Kubernetes introduce regolarmente nuove funzionalità e fornisce patch di sicurezza.
È tua responsabilità mantenere aggiornati i cluster GKE su VMware. Consulta le note di rilascio per ogni release. Inoltre, prevedi di eseguire l'aggiornamento ogni mese alle nuove patch e alle versioni secondarie ogni tre mesi. Scopri come eseguire l'upgrade dei cluster.
Sei anche responsabile dell'upgrade e della protezione dell'infrastruttura vSphere:
- Stabilisci un processo per eseguire patch e upgrade tempestivi delle tue VM
- Resta al passo con i più recenti consigli sulla sicurezza di VMware
- Segui le indicazioni sull'applicazione di patch agli host
Monitora i bollettini sulla sicurezza
Il team per la sicurezza di GKE Enterprise pubblica bollettini sulla sicurezza per le vulnerabilità con gravità alta e critica.
Questi bollettini seguono uno schema di numerazione delle vulnerabilità comune di Google Cloud e sono collegati dalla pagina principale dei bollettini di Google Cloud e dalle note di rilascio di GKE su VMware. Ogni pagina del bollettino sulla sicurezza ha un feed RSS da cui gli utenti possono iscriversi per ricevere gli aggiornamenti.
Quando è necessario un intervento per risolvere queste vulnerabilità critiche, Google contatta i clienti via email. Inoltre, Google potrebbe contattare i clienti con contratti di assistenza anche tramite i canali di assistenza.
Per ulteriori informazioni, consulta la seguente documentazione:
Monitoraggio e logging
Imposta le opzioni per il logging dei cluster GKE
GKE su VMware include molteplici 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 di cui è stato eseguito il deployment con GKE su VMware
- Prometheus e Grafana, disattivati per impostazione predefinita
- Configurazioni convalidate con soluzioni di terze parti
Qualunque sia la soluzione di logging scelta 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 informazioni di sicurezza (SIEM) per la gestione degli incidenti di sicurezza.
Per ulteriori informazioni, consulta la seguente documentazione:
- Logging e monitoraggio
- Utilizzo di logging e monitoraggio
- Logging e monitoraggio delle applicazioni
- Monitoraggio di Cluster Anthos su VMware con Elastic Stack
- Raccogli log su GKE Enterprise con Splunk Connect