Il livello di rete virtuale su Google Distributed Cloud (GDC) air-gapped regola la connettività, i firewall, il rilevamento dei servizi, il bilanciamento del carico e l'osservabilità tra le macchine virtuali e i pod in esecuzione in un'organizzazione GDC.
Modello di rete GDC
GDC contiene due livelli di concetti di multi-tenancy: organizzazioni e progetti. I progetti esistono all'interno delle organizzazioni e tutti i carichi di lavoro virtualizzati e containerizzati vengono distribuiti in un progetto specifico all'interno di un'organizzazione.
Rete 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 carichi di lavoro in progetti diversi dell'organizzazione.
GDC isola ogni organizzazione a livello di rete da tutte le altre organizzazioni. I carichi di lavoro in un'organizzazione non hanno una connettività diretta tramite indirizzo IP ai carichi di lavoro in 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 per impostazione predefinita non sono accessibili dall'esterno dell'organizzazione. Devi abilitare esplicitamente il traffico in entrata e in uscita per i carichi di lavoro utilizzando i vincoli in entrata e in uscita descritti nella sezione Rete del progetto.
Rete del progetto
Tutte le macchine virtuali (VM) e i carichi di lavoro containerizzati vengono distribuiti in un progetto. I progetti forniscono un limite di segmentazione della 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. I criteri 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 carichi di lavoro 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.
Configurare 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 offre tre metodi per configurare i bilanciatori del carico. Per ulteriori informazioni, consulta Gestire i bilanciatori del carico.
Vincoli in entrata
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.
I carichi di lavoro basati su VM vengono esposti all'esterno dell'organizzazione utilizzando la funzionalità di accesso esterno alle VM. Abilita questa funzionalità per ogni VM. A ogni VM viene assegnato un indirizzo IP dall'intervallo esterno dell'organizzazione.
D'altra parte, i carichi di lavoro containerizzati vengono esposti all'esterno dell'organizzazione utilizzando la funzionalità del 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 di pod di backend.
Vincoli in uscita
Devi abilitare esplicitamente il traffico in uscita per ogni progetto e carico di lavoro per comunicare all'esterno dell'organizzazione. L'abilitazione del traffico in uscita modifica l'IP dei carichi di lavoro in un IP esterno utilizzando la Network Address Translation (NAT) quando si connette all'esterno dell'organizzazione. Per ulteriori informazioni su come consentire il traffico in uscita, consulta la panoramica di NAT.
Modello di applicazione delle policy 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 project network policies.
L'applicazione dei criteri si basa sui flussi di traffico di livello 3 e livello 4. Un flusso descrive una connessione a 5 tuple come segue:
- Indirizzo IP di origine
- Indirizzo IP di destinazione
- Porta di origine
- Porta di destinazione
- Protocollo, ad esempio
TCP,UDPoIPIP
I criteri di rete applicano il traffico in uscita al traffico sul 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, come 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 di avvio è consentito. Per questo motivo, vengono osservati solo i timeout di connessione dovuti all'applicazione dei criteri dal client che avvia la connessione. Il traffico rifiutato viene eliminato durante il trasferimento dei dati in uscita dal nodo di origine o il trasferimento dei dati in entrata nel nodo di destinazione. Il carico di lavoro ricevente non osserva mai la connessione.
L'applicazione si basa su regole di criteri basate su consenti che sono additive. L'applicazione risultante per un carico di lavoro è una "corrispondenza qualsiasi" per il flusso di traffico rispetto all'unione di tutti i criteri applicati 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 rifiuto, solo regole di autorizzazione.
Quando una policy di rete nega un flusso, non ricevi un pacchetto di risposta e osservi un timeout di connessione. Per questo motivo, le connessioni a livello di protocollo o gli errori HTTP rifiutati o reimpostati non sono il risultato diretto dell'applicazione della 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.