Informazioni sulla sicurezza di rete in GKE

Questo documento spiega i concetti di base della sicurezza di rete di GKE, come il principio del privilegio minimo, e ti aiuta a scegliere gli strumenti giusti per proteggere il tuo cluster. Gli obiettivi principali dell'implementazione della sicurezza di rete GKE sono l'isolamento dei workload e il multi-tenancy sicuro. Per raggiungere questi obiettivi, devi applicare i principi dei privilegi minimi e della difesa in profondità e utilizzare dati utilizzabili per prendere decisioni in materia di sicurezza.

In Google Kubernetes Engine (GKE), l'applicazione del principio del privilegio minimo al traffico di rete significa limitare la comunicazione solo a ciò che è necessario per il funzionamento delle applicazioni. Per impostazione predefinita, la rete all'interno di un cluster GKE è aperta, il che significa che ogni pod può comunicare con ogni altro pod.

Questo documento aiuta operatori, specialisti di networking e specialisti della sicurezza a comprendere e implementare la sicurezza di rete all'interno dei cluster GKE. Per maggiori informazioni sui ruoli comuni e sulle attività di esempio in Google Cloud, consulta Ruoli e attività comuni degli utenti GKE.

Prima di leggere questo documento, verifica di avere familiarità con quanto segue:

  • Concetti di networking GKE: per una panoramica, consulta Informazioni sul networking GKE.
  • Pod, servizi e spazi dei nomi Kubernetes: queste risorse Kubernetes fondamentali sono essenziali per definire le norme di sicurezza di rete. Consulta la documentazione di Kubernetes.
  • Principio del privilegio minimo: questo principio di sicurezza è un concetto fondamentale applicato in tutto il documento.

Obiettivi della sicurezza di rete di GKE

I criteri di sicurezza di rete GKE forniscono un controllo del traffico granulare e consapevole di Kubernetes all'interno del cluster. Queste norme sono un elemento fondamentale della tua strategia di sicurezza complessiva. Per implementare una sicurezza di rete robusta, prendi in considerazione questi principi fondamentali:

  • Privilegio minimo: concedi a sistemi e servizi solo i privilegi minimi necessari per svolgere le loro funzioni. Questo principio riduce il potenziale impatto di una compromissione. I criteri di rete di Kubernetes ti aiutano a passare da una rete aperta per impostazione predefinita a una in cui sono consentite solo le connessioni necessarie.
  • Difesa in profondità: applica più controlli di sicurezza indipendenti. Un errore in un controllo non comporta la compromissione totale del sistema. Ad esempio, utilizzi un criterio di rete per isolare un database, anche se il database stesso richiede l'autenticazione.
  • Dati strategici: basa le decisioni di sicurezza sui dati. La modellazione delle minacce e la valutazione dei rischi definiscono la tua condizione di sicurezza. Funzionalità come la registrazione dei criteri di rete forniscono i dati per verificare i criteri e rilevare potenziali violazioni.

Scegliere una policy di sicurezza di rete

Per scegliere la policy giusta, identifica il tipo e l'ambito del traffico che devi controllare.

Tipi di traffico

Per scegliere la policy giusta, considera l'origine e la destinazione del traffico che vuoi gestire:

  • Comunicazione tra i pod all'interno del cluster: per controllare il modo in cui i microservizi comunicano tra loro, utilizza criteri che operano su etichette e spazi dei nomi dei pod.

    • In qualità di sviluppatore di applicazioni, utilizza l'NetworkPolicy Kubernetes standard per definire le regole in entrata e in uscita per la tua applicazione all'interno del suo spazio dei nomi.
    • In qualità di amministratore del cluster, utilizza CiliumClusterwideNetworkPolicy per applicare le misure di salvaguardia della sicurezza che si applicano all'intero cluster. Le regole di negazione in NetworkPolicy hanno la precedenza sulle regole di autorizzazione CiliumClusterwideNetworkPolicy.

  • Traffico in uscita dai pod verso servizi esterni: per controllare il traffico in uscita dai pod verso servizi esterni in base ai nomi di dominio, utilizza FQDNNetworkPolicy. Questa policy è utile quando gli indirizzi IP dei servizi esterni non sono statici, perché risolve e aggiorna automaticamente gli indirizzi IP consentiti in base al DNS.

  • Crittografia per tutto il traffico da servizio a servizio: per garantire che tutte le comunicazioni tra i servizi siano criptate e autenticate, utilizza un service mesh. Utilizza Istio o Anthos Service Mesh per implementare TLS reciproco (mTLS), che gestisce automaticamente la crittografia.

Riepilogo delle scelte relative alle norme

La tabella seguente riepiloga la policy da utilizzare in base al tuo obiettivo di sicurezza.

Obiettivo Policy consigliata
Controlla il traffico tra i pod utilizzando etichette e spazi dei nomi. Kubernetes NetworkPolicy
Controlla il traffico in uscita verso servizi esterni in base al nome di dominio. FQDNNetworkPolicy
Cripta e autentica tutto il traffico da un servizio all'altro. Istio o Anthos Service Mesh (per mTLS)
Applica regole obbligatorie a livello di cluster come amministratore. CiliumClusterwideNetworkPolicy
Controlla e registra le connessioni consentite o negate dai criteri. Logging dei criteri di rete (attivato per qualsiasi criterio)

Controllare e risolvere i problemi relativi ai criteri di rete

Dopo aver implementato i criteri di rete, verifica che funzionino come previsto e diagnostica eventuali problemi di connettività. A questo scopo, puoi utilizzare Network Policy Logging come strumento principale.

Quando abiliti la registrazione dei criteri di rete, GKE genera un record di log in Cloud Logging per ogni connessione consentita o negata da un criterio di rete. Questi log sono essenziali per eseguire l'auditing della sicurezza e risolvere i problemi relativi a comportamenti imprevisti. La revisione di questi log ti consente di visualizzare gli effetti concreti delle tue regole, confermando che il traffico legittimo scorre come previsto e che il traffico non autorizzato viene bloccato.

Passaggi successivi