Con la velocità di sviluppo di Kubernetes, spesso sono disponibili nuove funzionalità di sicurezza da utilizzare. Questo documento descrive come rafforzare la sicurezza dei 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 abilitate 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 del deployment evidenzia le best practice per la protezione del deployment della piattaforma dei cluster GKE. Per ulteriori informazioni su ogni pratica, consulta le sezioni di questo documento.
| Elenco di controllo del deployment | Descrizione |
|---|---|
| Controllo dell'identità e dell'accesso | Utilizza i privilegi dell'account vSphere: Proteggi Google Cloud i service account: 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 control plane e ai nodi: Utilizza i criteri di rete per limitare il traffico: |
| Sicurezza dichiarativa | Utilizza Policy Controller: |
| Manutenzione | Upgrade: Monitora i bollettini sulla sicurezza: |
| Monitoraggio e logging | Imposta le opzioni per il logging: |
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 di amministratore di vCenter dispone dei privilegi per l'accesso completo a tutti gli oggetti vCenter e fornisce a un amministratore del cluster Google Distributed Cloud l'accesso completo.
È consigliabile seguire il principio del privilegio minimo, concedendo solo i privilegi necessari per installare correttamente {product_name}}. Abbiamo predefinito il set minimo di privilegi necessari per eseguire l'installazione, nonché i comandi necessari per concedere queste autorizzazioni.
Proteggi i Google Cloud service account
Google Distributed Cloud richiede diversi Google Cloud service account. Durante l'installazione, associ i ruoli Identity and Access Management a questi service account. Questi ruoli concedono ai service account privilegi specifici all'interno del progetto. Alcuni service account 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 ulteriori informazioni, consulta GKE Identity Service.
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 per l'ambiente. Assegna centri di costo ed etichette appropriate a ogni spazio dei nomi per la responsabilità e il chargeback. Concedi agli sviluppatori solo il livello di accesso agli 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 rispetto al cluster e definisci le autorizzazioni necessarie per completare ogni attività. Per concedere autorizzazioni a livello di cluster e spazio dei nomi, utilizza Kubernetes RBAC.
Oltre alle autorizzazioni per Google Cloud service accounts utilizzati per installare Google Distributed Cloud, IAM non si applica ai cluster Google Distributed Cloud.
Per ulteriori informazioni, leggi la seguenti 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 cluster vSphere. Google consiglia vivamente di criptare tutti i dati at-rest. Per farlo su vSphere, consulta la pagina Rafforzamento e conformità di VMware vSphere e le indicazioni sulle best practice per la crittografia delle VM.
Questa operazione deve essere eseguita prima dell'installazione di Google Distributed Cloud.
Gestisci 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 scegli di utilizzare un gestore dei secret esterno, come HashiCorp Vault, configuralo prima di integrare i cluster Google Distributed Cloud.
Sono disponibili diverse opzioni per la gestione dei secret:
- Puoi utilizzare i secret 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 dei secret at-rest. Per impostazione predefinita, i secret non vengono criptati ulteriormente.
- Puoi utilizzare un gestore dei secret esterno, come HashiCorp Vault. Puoi eseguire l'autenticazione a HashiCorp utilizzando un account di servizio Kubernetes o un Google Cloud service account.
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 control plane 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 ed è una best practice non modificarli. Implementa regole firewall nella rete on-premise per limitare l'accesso al control plane.
Utilizza 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 sul controllo della comunicazione da servizio a servizio in base alle esigenze dei carichi di lavoro, consulta le sezioni seguenti.
La limitazione dell'accesso di rete ai servizi rende molto più difficile per gli utenti malintenzionati spostarsi 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 applicazioni, utilizza Istio. Scegli questa opzione se ti interessano il bilanciamento del carico, l'autorizzazione dei servizi, la limitazione, la quota e le metriche.
- Per controllare il traffico L4 tra i pod, utilizza i criteri di rete Kubernetes. Scegli questa opzione se cerchi le funzionalità di controllo dell'accesso di base gestite da Kubernetes.
Puoi abilitare sia Istio sia i criteri di rete Kubernetes dopo aver creato i cluster Google Distributed Cloud. Puoi utilizzarli insieme, se necessario.
Per ulteriori informazioni, leggi la seguenti documentazione:
Sicurezza dichiarativa
Questa sezione fornisce consigli per proteggere i cluster.
Utilizza Policy Controller
I controller di ammissione Kubernetes sono plug-in che regolano e applicano la modalità di utilizzo di un cluster Kubernetes. I controller di ammissione sono una parte importante dell'approccio di difesa in profondità per rafforzare la sicurezza 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 cluster sono definiti nei modelli di vincolo, che vengono sottoposti a 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 ulteriori informazioni, leggi la seguenti documentazione:
Limita la possibilità per i carichi di lavoro di modificarsi autonomamente
Alcuni carichi di lavoro Kubernetes, in particolare i carichi di lavoro di sistema, hanno l'autorizzazione a modificarsi autonomamente. Ad esempio, alcuni carichi di lavoro si scalano automaticamente in verticale. Sebbene sia comodo, questo può consentire a un utente malintenzionato che ha già compromesso un nodo di aumentare ulteriormente i privilegi nel cluster. Ad esempio, un utente malintenzionato potrebbe avere un carico di lavoro sul nodo che si modifica per essere eseguito come un account di servizio con più privilegi esistente nello stesso spazio dei nomi.
Idealmente, ai carichi di lavoro non dovrebbe essere concessa l'autorizzazione a modificarsi autonomamente. Quando è necessaria l'automodifica, puoi limitare le autorizzazioni applicando vincoli Gatekeeper o Policy Controller, come NoUpdateServiceAccount dalla libreria Gatekeeper open source, 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. Questa operazione è necessaria 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 nel 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 Google Distributed Cloud
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, pianifica di eseguire l'aggiornamento alle nuove patch release ogni mese e alle versioni secondarie ogni tre mesi. Scopri come eseguire l' upgrade dei cluster.
È anche tua responsabilità eseguire l'upgrade e proteggere l'infrastruttura vSphere:
- Stabilisci una procedura per eseguire in modo tempestivo l'applicazione di patch e gli upgrade delle VM
- Tieniti al corrente con gli ultimi avvisi di sicurezza di VMware
- Segui le indicazioni sull'applicazione di patch agli host
Monitora i bollettini sulla sicurezza
Il team di sicurezza di GKE pubblica bollettini sulla sicurezza per le vulnerabilità di gravità elevata e critica.
Questi bollettini seguono uno schema di numerazione delle vulnerabilità comune Google Cloud e sono collegati dalla pagina principale dei bollettini Google Cloud e dalle note di rilascio di Google Distributed Cloud. Ogni pagina bollettino sulla sicurezza ha un feed RSS a cui gli utenti possono iscriversi per ricevere gli aggiornamenti.
Quando è necessario un intervento del cliente per risolvere queste vulnerabilità di gravità elevata e critica, 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, leggi la seguenti documentazione:
Monitoraggio e logging
Google Distributed Cloud include diverse opzioni per il logging e il monitoraggio dei cluster, tra cui servizi gestiti basati sul cloud, strumenti open source e compatibilità convalidata con soluzioni commerciali di terze parti:
- Cloud Logging e Cloud Monitoring, abilitati dagli agent in-cluster sottoposti a deployment 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 eventi e gli avvisi pertinenti in un servizio di gestione delle informazioni e degli eventi di sicurezza (SIEM) centralizzato per la gestione degli incidenti di sicurezza.
Per ulteriori informazioni, leggi la seguenti documentazione:
- Logging e monitoraggio
- Utilizzo di Logging e Monitoring
- Logging e monitoraggio delle applicazioni
- Monitoraggio di Google Distributed Cloud con Elastic Stack
- Trasmetti i log da Google Cloud a Splunk