Il livello di networking virtuale sull'appliance Google Distributed Cloud (GDC) con air gap regola la connettività, i firewall, l'Service Discovery, il bilanciamento del carico e l'osservabilità tra le macchine virtuali e i pod in esecuzione in un'organizzazione GDC.
Modello di networking GDC
GDC è costituito da un solo livello di tenancy: i progetti.
Networking di progetti
Esegui il deployment di tutte le macchine virtuali (VM) e dei carichi di lavoro containerizzati in un progetto. I progetti forniscono un limite di segmentazione di rete all'interno dell'organizzazione.
I carichi di lavoro all'interno di un progetto possono comunicare direttamente tra loro. Tuttavia, la policy di rete predefinita impedisce la comunicazione tra i carichi di lavoro in progetti diversi. Se la policy di rete del progetto lo consente, i workload dell'organizzazione possono raggiungersi a vicenda al livello di rete L3 utilizzando i rispettivi indirizzi IP. Devi abilitare esplicitamente i vincoli in entrata e in uscita da e verso l'organizzazione per ogni carico di lavoro che richiede traffico in entrata o in uscita.
Configura i bilanciatori del carico
I bilanciatori del carico distribuiscono il traffico tra i carichi di lavoro di backend dell'applicazione, garantendo stabilità e disponibilità. Crea bilanciatori del carico esterni e interni per i carichi di lavoro di pod e VM. GDC fornisce tre metodi per configurare i bilanciatori del carico. Per saperne di più, consulta Gestire i bilanciatori del carico.
Vincoli di ingresso
Il meccanismo utilizzato per esporre i carichi di lavoro all'esterno dell'organizzazione varia a seconda che il carico di lavoro sia basato su VM o container.
Esporre i carichi di lavoro basati su VM all'esterno dell'organizzazione utilizzando la funzionalità di accesso esterno alle VM. Puoi attivare questa funzionalità per ogni VM. Ogni VM riceve il proprio indirizzo IP dall'intervallo esterno dell'organizzazione.
D'altra parte, esponi i carichi di lavoro containerizzati all'esterno dell'organizzazione utilizzando la funzionalità di bilanciatore del carico esterno. Puoi creare un bilanciatore del carico esterno e GDC assegna un indirizzo IP esterno. Il traffico può quindi essere bilanciato del carico su un insieme di carichi di lavoro dei pod di backend.
Vincoli di uscita
Devi attivare esplicitamente il traffico in uscita per ogni progetto e carico di lavoro per comunicare al di fuori dell'organizzazione. L'attivazione del traffico in uscita modifica l'IP dai carichi di lavoro a un IP esterno utilizzando Network Address Translation (NAT) quando la connessione avviene al di fuori dell'organizzazione. Per saperne di più su come consentire il traffico in uscita, vedi Gestire il traffico in uscita da un'organizzazione.
Modello di applicazione dei criteri di rete
La postura di sicurezza per i carichi di lavoro all'interno di un'organizzazione è l'unione dei criteri di rete del progetto predefiniti e creati dall'utente.
L'applicazione dei criteri si basa sui flussi di traffico di livello 3 e livello 4. Un flusso descrive una connessione a 5 tuple nel seguente modo:
- Indirizzo IP di origine
- Indirizzo IP di destinazione
- Porta di origine
- Porta di destinazione
- Protocollo, ad esempio
TCPoUDP
I criteri di rete applicano il traffico in uscita al traffico nel nodo che ospita il carico di lavoro di origine e il traffico in entrata quando il traffico arriva al nodo che ospita il carico di lavoro di destinazione. Pertanto, per stabilire una connessione, devi consentire al criterio di lasciare l'origine per la destinazione e di arrivare alla destinazione dall'origine.
Il traffico di risposta, ad esempio il segmento SYN-ACK (synchronize-acknowledge) che risponde a un segmento SYN, non è soggetto all'applicazione. Pertanto, il traffico di risposta è sempre consentito se il traffico iniziale è consentito. Per questo motivo, osservi solo i timeout di connessione dovuti all'applicazione dei criteri da parte del client che avvia la connessione. Il traffico negato viene eliminato durante il trasferimento di dati in uscita dal nodo di origine o il trasferimento di dati in entrata nel nodo di destinazione. Il workload di ricezione non osserva mai la connessione.
L'applicazione si basa su regole dei criteri basate su elenchi consentiti che sono cumulative. L'applicazione risultante per un carico di lavoro è una "corrispondenza di qualsiasi tipo" per il flusso di traffico rispetto all'unione di tutte le norme applicate a quel carico di lavoro. Quando sono presenti più criteri, le regole applicate a ogni carico di lavoro vengono combinate in modo additivo, consentendo il traffico se corrisponde ad almeno una delle regole. Non hai regole di negazione, solo regole di autorizzazione.
Quando un criterio di rete nega un flusso, non ricevi un pacchetto di risposta e osservi un timeout della connessione. Per questo motivo, le connessioni a livello di protocollo rifiutate o ripristinate o gli errori HTTP non sono il risultato diretto dell'applicazione delle norme di rete.
Per ulteriori informazioni sui criteri di rete di Kubernetes, consulta https://kubernetes.io/docs/concepts/services-networking/network-policies/#the-two-sorts-of-pod-isolation.