Criteri del firewall per la protezione del traffico tra cluster Kubernetes Antrea e macchine virtuali in una rete NSX

È possibile creare gruppi generici con tipi di membri Kubernetes nei criteri di appartenenza dinamica in modo che corrispondano al traffico in entrata o in uscita dai cluster Antrea Kubernetes.

È quindi possibile utilizzare questi gruppi generici nelle regole del firewall distribuito o nelle regole del firewall del gateway per proteggere il traffico tra le macchine virtuali nell'ambiente NSX e i pod nei cluster Kubernetes Antrea.

Importante: In un ambiente NSX multi-tenant, le risorse del cluster Kubernetes non sono esposte all'inventario del progetto. Pertanto, all'interno di un progetto, non è possibile creare gruppi generici con tipi di membri Kubernetes nei criteri di appartenenza dinamica. È necessario creare i gruppi nella vista Predefinita (spazio predefinito) di NSX e quindi utilizzarli nelle regole del firewall distribuito o nelle regole del firewall del gateway nello spazio predefinito.

Prerequisiti

• I cluster Kubernetes Antrea sono registrati in NSX.
• Nella distribuzione di NSX applicare una licenza di sicurezza appropriata che autorizzi il sistema a configurare criteri di sicurezza del firewall distribuito.

Protezione del traffico dai cluster Kubernetes Antrea alle macchine virtuali in NSX

Per associare il traffico dai cluster Kubernetes Antrea a NSX è possibile aggiungere gruppi generici in base ai seguenti tipi di membri (risorse) Kubernetes nelle regole del firewall:

• Nodo Kubernetes
• Uscita Antrea
• Pool IP Antrea

Il diagramma seguente illustra i flussi di traffico tipici dal cluster Kubernetes Antrea alle macchine virtuali nella rete logica di NSX.

Come illustrato in questo diagramma di flusso del traffico, per associare il traffico in uscita dal cluster Kubernetes Antrea sono possibili gli scenari seguenti:

Scenario 1: SNAT tramite uscita (nodi gateway)

È possibile distribuire una risorsa di uscita nel cluster Kubernetes Antrea. Nel file manifesto della risorsa di uscita, selezionare i criteri di raggruppamento dei pod a cui si applica la risorsa di uscita. È possibile specificare manualmente l'IP di uscita nel file manifesto oppure la CNI di Antrea può allocare un IP in uscita da una risorsa ExternalIPPool personalizzata.

Importante: Gli indirizzi IP in uscita devono essere instradabili nella rete fisica e devono essere raggiungibili da tutti i nodi nel cluster K8s.

La CNI di Antrea invia il traffico in uscita dai pod selezionati ai nodi del gateway. I nodi del gateway eseguono una conversione indirizzo di origine (SNAT) per convertire l'IP di origine (IP pod) nell'IP di uscita.

Ad esempio, nel diagramma di flusso del traffico precedente, il traffico in uscita da pod1 e pod2, che sono in esecuzione in node1, viene inviato ai nodi del gateway. Il nodo del gateway converte gli indirizzi IP del pod in indirizzi IP di egress1.

Per ulteriori informazioni sulla risorsa di uscita, vedere la Guida all'uscita nel portale della documentazione di Antrea.

I nodi del cluster che possono essere utilizzati come nodi del gateway dipendono dalla topologia di rete del nodo, che è controllata dall'amministratore di rete fisico o dall'amministratore di rete IaaS. I nodi del gateway hanno le due caratteristiche seguenti:

• La rete fisica consente ai nodi di disporre di un IP instradabile come IP di origine per accedere alla rete esterna.
• Facoltativamente, viene configurato un firewall fisico nel gateway fisico per filtrare il traffico in uscita dai nodi del gateway.

Si considerino gli esempi seguenti:

• Esempio 1: si supponga che il cluster Kubernetes Antrea disponga di tre nodi: node1, node2 e node3. Si supponga che node1 e node2 nel cluster siano nodi speciali perché a essi sono assegnate due interfacce di rete. Un'interfaccia per la comunicazione del cluster K8s e un'altra interfaccia per la connessione alla rete esterna. A node3 viene assegnata una sola interfaccia di rete per la comunicazione cluster. In questo scenario, solo node1 e node2 possono essere utilizzati come nodi gateway.
• Esempio 2: si supponga che a tutti e tre i nodi nel cluster K8s sia assegnata una sola interfaccia di rete e che l'amministratore di rete abbia configurato il firewall fisico in modo da consentire solo agli indirizzi MAC di node1 e node2 di accedere a Internet. In questo scenario, node1 e node2 possono essere utilizzati come nodi del gateway.
• Esempio 3: di supponga che tutti e tre i nodi possano visitare Internet. L'amministratore di rete ha configurato un firewall fisico nel gateway fisico e il firewall desidera filtrare il traffico da un IP di uscita specifico. In questo scenario, tutti e tre i nodi possono essere utilizzati come nodi gateway.

Il paragrafo seguente illustra una limitazione specifica dell'implementazione:

Nessun host fisico o macchina virtuale esterni al cluster Kubernetes Antrea possono essere utilizzati come nodo del gateway per il tunneling del traffico in uscita del pod. Questo avviene poiché Agente Antrea gestisce gli indirizzi IP di uscita e questo agente viene eseguito come pod in ogni nodo del cluster K8s. Pertanto, l'host fisico o una macchina virtuale che si desidera utilizzare come nodo del gateway deve far parte del cluster K8s.

Scenario 2: SNAT tramite nodi

In questo scenario, i pod non vengono selezionati esplicitamente nel file manifesto di qualsiasi risorsa di uscita.

Il traffico in uscita del pod viene mascherato dall'IP del nodo e quindi il traffico viene inviato alla rete IaaS. Ad esempio, nel diagramma di flusso del traffico precedente, una regola SNAT converte l'IP di origine (IP pod3, IP pod4) nell'IP node2 e quindi il traffico in uscita del pod viene inviato alla rete IaaS.

Scenario 3: pod instradabili con bridge direttamente alla rete IaaS

I pod instradabili indicano che ai pod vengono assegnati indirizzi IP instradabili nella rete underlay. In genere, ai pod vengono assegnati indirizzi IP privati dalla proprietà PodCIDR, che è configurata nel nodo. Quando i pod desiderano accedere a una rete esterna al cluster K8s, il traffico richiede un'operazione SNAT per convertire l'IP di origine (IP del pod) in un IP instradabile.

Se il cluster Kubernetes Antrea viene distribuito nella rete di overlay NSX con Servizio Tanzu Kubernetes Grid (TKGS), esiste un meccanismo per consentire ai nodi del cluster Tanzu Kubernetes (TKC) di richiedere subnet instradabili da NSX e utilizzare questa subnet instradabile come proprietà PodCIDR del nodo. I pod possono quindi ottenere indirizzi IP instradabili. Per ulteriori informazioni sulla configurazione di TKC con una rete di pod instradabili, vedere la documentazione di VMware vSphere with Tanzu.

Se il cluster Kubernetes Antrea non viene distribuito nella rete di overlay di NSX, l'amministratore Kubernetes può assicurarsi che nella rete underlay sia riservata una subnet instradabile o un intervallo di indirizzi IP instradabili. L'amministratore di può configurare la subnet o un intervallo di IP nel file manifesto della risorsa personalizzata IPPool. Quindi, la CNI di Antrea può allocare indirizzi IP instradabili ai pod.

Ad esempio, nel diagramma di flusso del traffico precedente, pod5 in esecuzione su node5 ottiene un IP instradabile da una risorsa personalizzata IPPool.

Per ulteriori informazioni sulla risorsa personalizzata IPPool, vedere la Guida a IPAM Antrea nel portale della documentazione di Antrea.

Protezione del traffico dalle macchine virtuali in NSX ai cluster Kubernetes Antrea

Per associare il traffico da NSX ai cluster Kubernetes Antrea è possibile aggiungere gruppi generici in base ai seguenti tipi di membri (risorse) Kubernetes nelle regole del firewall:

• Servizio Kubernetes
• Ingresso Kubernetes
• Gateway Kubernetes
• Pool IP Antrea

Il diagramma seguente illustra i flussi di traffico tipici dalle macchine virtuali nella rete logica di NSX al cluster Kubernetes Antrea.

Come illustrato in questo diagramma di flusso del traffico, per associare il traffico che entra nel cluster Kubernetes Antrea sono possibili i seguenti scenari:

Scenario 1: esposizione dei pod al traffico esterno tramite IP virtuale e porte

È possibile esporre pod al traffico esterno implementando una soluzione di bilanciamento del carico di terze parti con queste risorse Kubernetes native:

• Ingresso: funziona come un bilanciamento del carico di livello 7. Una risorsa in ingresso fornirà un indirizzo IP virtuale (VIP) ed esporrà alcune porte (TCP/UDP).
• Gateway: funziona come bilanciamento del carico di livello 4 e di livello 7. Una risorsa Gateway fornirà un VIP ed esporrà alcune porte (TCP/UDP).
• Servizio di tipo LoadBalancer: funziona come bilanciamento del carico di livello 4. Il servizio fornirà un VIP ed esporrà alcune porte (TCP/UDP).

Nota: Anche se le risorse di ingresso e gateway possono funzionare come bilanciamento del carico di livello 7, per le regole del firewall distribuito e le regole del firewall del gateway in NSX vengono visualizzate come bilanciamento del carico di livello 3 o di livello 4 utilizzando gli indirizzi IP e le porte in modo che corrispondano al traffico in entrata.

Scenario 2: esposizione dei pod al traffico esterno tramite l'IP e le porte del nodo

• Servizio Kubernetes di tipo NodePort: attiva tutti i nodi nel cluster K8s per aprire una porta nel nodo per ogni porta del servizio. Il servizio diventa raggiungibile tramite l'IP e la porta del nodo. Il nodo esegue SNAT e DNAT nel traffico.
• Servizio Kubernetes di tipo ClusterIP con la funzionalità NodePortLocal abilitata: richiede l'abilitazione della funzionalità NodePortLocal in Agente Antrea e l'aggiunta di un'annotazione nel file manifesto del servizio Kubernetes. La CNI di Antrea riconosce l'annotazione e apre una porta per ogni pod nel nodo in cui il pod è in esecuzione. NodePortlLocal evita di aprire una porta in tutti i nodi del cluster K8s, risparmiando in tal modo intervalli di porte disponibili. Evita inoltre un'operazione SNAT e conserva l'IP del client originale.

  Per ulteriori informazioni sulla funzionalità NodePortLocal, vedere la Guida a NodePortLocal nel portale della documentazione di Antrea.

Scenario 3: esposizione dei pod al traffico esterno tramite indirizzi IP dei pod instradabili

Antrea supporta l'assegnazione di indirizzi IP instradabili ai pod distribuendo la risorsa personalizzata IPPool nel cluster Kubernetes di Antrea. I pod ricevono l'indirizzo IP allocato da questo pool e vengono collegati direttamente alla rete IaaS.

Reti IaaS supportate

I cluster Kubernetes di Antrea possono essere distribuiti nelle seguenti piattaforme IaaS:

• Data center locale basato su vSphere: come cluster Tanzu Kubernetes che vengono creati utilizzando Servizio Tanzu Kubernetes Grid. I cluster sono gestiti da Tanzu Kubernetes Grid (TKG) 2.0 e vSphere.
• VMware Cloud: come cluster Tanzu Kubernetes gestiti da TKG 2.0 e VMC SDDC.
• Cloud pubblici: come cluster Kubernetes gestiti nelle piattaforme cloud pubbliche.
• Server fisici: come cluster Kubernetes su server bare-metal.
• OpenShift:
  • la CNI di Antrea distribuita nei cluster OpenShift e OpenShift viene distribuito in modalità IPI (Provisioned Infrastructure) del programma di installazione o in modalità UPI (User Provisioned Infrastructure).
  • I provider di infrastrutture possono essere uno dei seguenti: vSphere, Amazon Web Services (AWS), Azure, OpenStack, Google Cloud Platform (GCP), bare-metal.

Importante: La rete IaaS è responsabile del traffico tra i cluster Kubernetes Antrea e le macchine virtuali. Il traffico tra siti diversi, ad esempio data center locali, VMware Cloud e cloud pubblico, potrebbe coinvolgere una VPN specifica di IaaS. In tutti i casi, potrebbero essere presenti operazioni SNAT applicate dalla rete IaaS. L'amministratore di NSX deve assicurarsi che gli indirizzi IP di origine o di destinazione siano instradabili in modo che possano essere utilizzati nelle regole del firewall per proteggere il traffico tra le macchine virtuali e i cluster Kubernetes.

Approcci consigliati per applicare i criteri firewall

Il firewall distribuito e il firewall del gateway consentono di specificare gruppi generici con tipi di membri Kubernetes nelle origini e nelle destinazioni delle regole del firewall. Pertanto, è possibile decidere se fare riferimento ai gruppi nel firewall distribuito o nel firewall gateway.

VMware fornisce il consiglio seguente:

• Utilizzare il firewall gateway NSX per consentire o bloccare il traffico da cluster Kubernetes Antrea alle macchine virtuali in una rete NSX.

  Questo approccio consente di filtrare il traffico nel momento in cui entra nella rete overlay NSX.

• Utilizzare il firewall distribuito NSX per consentire o bloccare il traffico dalle macchine virtuali in una rete NSX per cluster Kubernetes Antrea.

  Questo approccio consente di filtrare il traffico nel momento in cui il traffico lascia le macchine virtuali in una rete overlay NSX.

Riepilogo dei tipi di membri Kubernetes per l'utilizzo nei criteri del firewall

Nella tabella seguente sono riepilogati i tipi di membri Kubernetes che è possibile utilizzare in gruppi generici NSX in modo che corrispondano al traffico nelle regole firewall.

Tipo di membro	Ambito	Utilizzo nel criterio del firewall
Cluster Kubernetes	Cluster	Viene visualizzata come condizione AND nei criteri di gruppo dinamici per la corrispondenza delle risorse di cluster specifici.
Spazio dei nomi Kubernetes	Spazio dei nomi	Viene visualizzata come condizione AND nei criteri di gruppo dinamici per la corrispondenza delle risorse degli spazi dei nomi specifici.
Uscita Antrea	Cluster	Consente di associare il traffico in uscita dai cluster Kubernetes Antrea in cui IP di origine = IP di uscita.
Pool IP Antrea	Cluster	Consente di associare il traffico in uscita dai cluster Kubernetes Antrea in cui l'IP di origine si trova negli intervalli di IP. Consente di associare il traffico in entrata nei cluster Kubernetes Antrea in cui l'IP di destinazione si trova negli intervalli di IP.
Nodo Kubernetes	Cluster	Consente di associare il traffico in uscita dai cluster Kubernetes Antrea in cui l'IP di origine si trova tra gli indirizzi IP del nodo del cluster.
Ingresso Kubernetes	Spazio dei nomi	Consente di associare il traffico in entrata nei cluster Kubernetes Antrea in cui l'IP di destinazione si trova negli indirizzi IP in ingresso.
Gateway Kubernetes	Spazio dei nomi	Consente di associare il traffico in entrata nei cluster Kubernetes Antrea in cui l'IP di destinazione si trova negli indirizzi IP del gateway.
Servizio Kubernetes (type=LoadBalancer)	Spazio dei nomi	Consente di associare il traffico che entra nei cluster Kubernetes Antrea in cui l'IP di destinazione si trova negli indirizzi IP di LoadBalancer.
Servizio Kubernetes (type=NodePort)	Spazio dei nomi	Consente di verificare la corrispondenza con il traffico che entra nei cluster Kubernetes Antrea in cui l'IP + porta di destinazione si trova nell'intervallo IP del nodo + NodePort.
Servizio Kubernetes (type=ClusterIP)	Spazio dei nomi	Nessuno
Funzionalità Servizio Kubernetes (type=ClusterIP) e NodePortLocal abilitate	Spazio dei nomi	Consente di verificare la corrispondenza del traffico in entrata nei cluster Kubernetes Antrea in cui l'IP + porta di destinazione si trova nell'intervallo IP del nodo + NodePortLocal.