Il livello di rete virtuale su Google Distributed Cloud (GDC) air-gapped gestisce la connettività, i firewall, l'individuazione dei servizi, 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 contiene due livelli di concetti di multi-tenancy: organizzazioni e progetti. I progetti esistono all'interno delle organizzazioni e tu esegui il deployment di tutti i workload virtualizzati e containerizzati in un progetto specifico all'interno di un'organizzazione.
Networking dell'organizzazione
Ogni organizzazione in GDC ha la propria rete virtuale isolata. La rete virtuale all'interno dell'organizzazione è uno spazio IP flat, il che significa che tutti i carichi di lavoro nell'organizzazione hanno una connettività diretta tramite indirizzo IP tra loro. Utilizzando i criteri di rete del progetto, puoi controllare l'accesso tra i workload in progetti diversi dell'organizzazione.
GDC isola ogni organizzazione a livello di rete da tutte le altre organizzazioni. I carichi di lavoro di un'organizzazione non hanno connettività diretta all'indirizzo IP con i carichi di lavoro di un'altra organizzazione.
Un'organizzazione ha due intervalli IP diversi: un intervallo interno e un intervallo esterno. L'intervallo IP esterno è raggiungibile dall'esterno dell'organizzazione, mentre l'intervallo IP interno è accessibile solo dall'interno dell'organizzazione. Ai carichi di lavoro viene sempre assegnato un indirizzo IP dall'intervallo interno dell'organizzazione, il che significa che non sono accessibili dall'esterno dell'organizzazione per impostazione predefinita. Devi attivare esplicitamente il traffico in entrata e in uscita per i carichi di lavoro utilizzando i vincoli di ingresso e uscita descritti nella sezione Networking del progetto.
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. Le norme di rete del progetto (ProjectNetworkPolicy) consentono di configurare i progetti dell'organizzazione che possono comunicare tra loro. 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 workload 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.