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 di GKE sono l'isolamento dei carichi di lavoro e il multi-tenancy sicuro. Per raggiungere questi obiettivi, devi applicare i principi del privilegio minimo e della difesa in profondità e utilizzare dati utili per prendere decisioni in merito alla 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 tutti gli altri pod.

GKE ora supporta un approccio gerarchico alla sicurezza di rete utilizzando ClusterNetworkPolicy per l'applicazione a livello amministrativo in tutti gli spazi dei nomi.

Questo documento fornisce le informazioni necessarie agli operatori, agli specialisti di networking e agli specialisti di sicurezza per comprendere e implementare la sicurezza di rete all'interno dei cluster GKE. Per ulteriori informazioni sui ruoli comuni e sulle attività di esempio, consulta Ruoli e attività comuni degli utenti GKE. Google Cloud

Prima di leggere questo documento, assicurati di conoscere i seguenti concetti:

  • 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 policy di sicurezza di rete. Consulta la documentazione di Kubernetes.
  • Il principio del privilegio minimo: questo principio di sicurezza è un concetto fondamentale applicato in tutto il documento.

Obiettivi della sicurezza di rete di GKE

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

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 le policy che operano su etichette e spazi dei nomi dei pod.

    • In qualità di sviluppatore di applicazioni, utilizza la NetworkPolicy standard di Kubernetes NetworkPolicy per definire le regole di ingresso e uscita per la tua applicazione all'interno del suo spazio dei nomi.
    • In qualità di amministratore del cluster, utilizza la ClusterNetworkPolicy standard di Kubernetes ClusterNetworkPolicy per applicare le barriere di sicurezza obbligatorie (Admin tier) o stabilire impostazioni predefinite Zero Trust (Baseline tier) in tutti gli spazi dei nomi. Questa risorsa è supportata sui cluster che eseguono GKE versione 1.36.1-gke.1067000 o successive.
    • In qualità di amministratore del cluster, utilizza la CiliumClusterwideNetworkPolicy proprietaria CiliumClusterwideNetworkPolicy per il controllo del traffico specializzato a livello di cluster. Per i nuovi deployment, utilizza la ClusterNetworkPolicy nativa di Kubernetes anziché questa policy proprietaria.
  • 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 Cloud Service Mesh per implementare mTLS (mutual TLS), che gestisce automaticamente la crittografia.

Livelli di valutazione delle policy

GKE valuta le policy di sicurezza di rete in tre livelli gerarchici.

  1. Livello Admin (ClusterNetworkPolicy): il livello di precedenza più alto. Utilizza questo livello per applicare i mandati di sicurezza obbligatori. Le regole Deny in questo livello sostituiscono tutte le altre policy. Le regole Accept consentono il traffico e interrompono la valutazione per quel pacchetto.
  2. Livello NetworkPolicy: il livello in cui gli sviluppatori definiscono la sicurezza specifica dell'applicazione. Le policy includono le risorse standard NetworkPolicy, FQDNNetworkPolicy, e CiliumClusterwideNetworkPolicy.
  3. Livello Baseline (ClusterNetworkPolicy): il livello di precedenza più basso. Utilizza questo livello per impostare le barriere di sicurezza predefinite "deny-by-default" che gli sviluppatori possono sostituire selettivamente nel livello NetworkPolicy.

Se nessuna policy corrisponde a un livello, GKE utilizza per impostazione predefinita un comportamento "consenti tutto" implicito.

Riepilogo delle scelte delle policy

La tabella seguente riassume la policy da utilizzare in base all'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 servizio a servizio. Istio o Anthos Cloud Service Mesh (per mTLS)
Applica barriere di sicurezza obbligatorie e non sostituibili. ClusterNetworkPolicy (livello Admin)
Stabilisci barriere di sicurezza "Zero Trust" predefinite che gli sviluppatori possono sostituire. ClusterNetworkPolicy (livello Baseline)
Configura policy proprietarie a livello di cluster (non consigliate per i nuovi deployment). CiliumClusterwideNetworkPolicy
Controlla e registra le connessioni consentite o negate dalle policy. Logging delle policy di rete (abilitato per qualsiasi policy)

Controllare e risolvere i problemi relativi alle policy di rete

Dopo aver implementato le policy di rete, verifica che funzionino come previsto e diagnostica eventuali problemi di connettività. Puoi utilizzare il logging delle policy di rete come strumento principale per questa operazione.

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

A differenza delle policy standard che sono "solo consentite", le risorse ClusterNetworkPolicy supportano azioni Deny esplicite. Se una policy amministrativa elimina il traffico, il record di log attribuisce la negazione alla policy specifica responsabile del blocco.

Passaggi successivi