Comprendere le opzioni di applicazione delle politiche di rete con Calico

Il plugin di rete Calico offre un'ampia gamma di politiche di rete con una sintassi unificata per proteggere gli host su hardware, macchine virtuali e pod. Queste politiche possono essere applicate a livello di namespace o essere politiche di rete globali, applicabili a host endpoint (per proteggere le applicazioni che operano direttamente sull'host — l'host può essere un server fisico o una macchina virtuale) o a workload endpoint (per proteggere le applicazioni che operano all'interno di contenitori o macchine virtuali ospitate sull'host). Le politiche Calico consentono di implementare misure di sicurezza per diversi punti di percorso dei pacchetti utilizzando opzioni come preDNAT, unraracked e applyOnForward. Comprendere il funzionamento di queste opzioni può contribuire a migliorare la sicurezza e le prestazioni del sistema nel suo insieme. In questo articolo vengono spiegati i parametri delle politiche Calico (preDNAT, unraracked e applyOnForward) applicati a host endpoints, con un focus su cosa accade nei percorsi di elaborazione dei pacchetti (catene iptables).

Questo articolo presuppone che tu abbia una comprensione dei principi di base delle politiche di rete di Kubernetes e Calico. Se non è così, ti consigliamo di provare il tutorial di base sulle politiche di rete e tutorial di protezione dell'host utilizzando Calico, prima di leggere questo articolo. Ci aspettiamo anche che tu abbia una conoscenza di base del funzionamento iptables in Linux.

Calico politica di rete globale ti consente di applicare un insieme di regole di accesso basate su etichette (a gruppi di host e workloads/pods). Questo è molto utile se utilizzi insieme sistemi eterogenei — macchine virtuali, sistemi fisici o infrastrutture kubernetes. Inoltre, puoi proteggere il tuo cluster (nodi) tramite un insieme di politiche dichiarative e applicare politiche di rete al traffico in entrata (ad esempio, attraverso il servizio NodePorts o gli IP esterni).

A livello fondamentale, quando Calico collega un pod alla rete (vedi diagramma sottostante), lo connette all'host tramite un'interfaccia Ethernet virtuale (veth). Il traffico inviato dal pod arriva all'host da questa interfaccia virtuale e viene gestito come se provenisse da un'interfaccia di rete fisica. Per impostazione predefinita, Calico chiama queste interfacce caliXXX. Poiché il traffico passa attraverso l'interfaccia virtuale, attraversa iptables, come se il pod fosse a una sola hop. Pertanto, quando il traffico arriva/parte dal pod, viene inoltrato (forwarded) dal punto di vista dell'host.

Sulla node di Kubernetes su cui è in esecuzione Calico, puoi mappare l'interfaccia virtuale (veth) con il workload nel seguente modo. Nell'esempio sottostante puoi vedere che veth#10 (calic1cbf1ca0f8) è connesso a cnx-manager-* nel namespace calico-monitoring.

[centos@ip-172-31-31-46 K8S]$ sudo ip a
...
10: calic1cbf1ca0f8@if4:  mtu 1440 qdisc noqueue state UP group default
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 5
    inet6 fe80::ecee:eeff:feee:eeee/64 scope link
       valid_lft forever preferred_lft forever
...

[centos@ip-172-31-31-46 K8S]$ calicoctl get wep --all-namespaces
...
calico-monitoring cnx-manager-8f778bd66-lz45m ip-172-31-31-46.ec2.internal 192.168.103.134/32
calic1cbf1ca0f8
...

Dato che Calico crea un'interfaccia veth per ogni workload, come applica le politiche? A questo scopo, Calico crea degli hook in diverse catene di elaborazione dei pacchetti, utilizzando iptables.

Nel diagramma sottostante sono mostrate le catene coinvolte nell'elaborazione dei pacchetti in iptables (o nel sottosistema netfilter). Quando un pacchetto arriva tramite l'interfaccia di rete, passa prima attraverso la catena PREROUTING. Dopodiché si prende una decisione di instradamento e, in base a questo, il pacchetto passa o attraverso INPUT (diretto ai processi dell'host) o attraverso FORWARD (diretto al pod o a un'altra node nella rete). Dal processo locale, il pacchetto passa attraverso la catena OUTPUT e poi POSTROUTING prima di essere inviato tramite cavo.

Nota che il pod è anche un oggetto esterno (collegato a veth) dal punto di vista dell'elaborazione di iptables. Riassumiamo:

• Il traffico inoltrato (forwarded) (NAT, instradato o in / da pod) passa attraverso le catene PREROUTING — FORWARD — POSTROUTING.
• Il traffico verso il processo locale dell'host passa attraverso la catena PREROUTING — INPUT.
• Il traffico dal processo locale dell'host passa attraverso la catena OUTPUT — POSTROUTING.

Calico offre opzioni per le politiche, grazie alle quali è possibile applicare politiche a tutte le catene. Tenendo presente ciò, esaminiamo le varie opzioni di configurazione delle politiche disponibili in Calico. I numeri nell'elenco delle opzioni qui sotto corrispondono ai numeri nel diagramma sopra.

1. Politica dell'endpoint di workload (pod)
2. Politica dell'endpoint host
3. Opzione ApplyOnForward
4. Politica PreDNAT
5. Politica Untracked

Iniziamo esaminando come le politiche vengono applicate agli endpoint di workload (pod di Kubernetes o macchine virtuali OpenStack), per poi considerare le opzioni di politiche per gli endpoint host.

Endpoints di Workload

Politica dell'Endpoint di Workload (1)

Questa è un'opzione per proteggere i tuoi pod di Kubernetes. Calico supporta l'uso di Kubernetes NetworkPolicy, ma offre anche politiche aggiuntive: Calico NetworkPolicy e GlobalNetworkPolicy. Calico crea una catena per ogni pod (workload) e agganci nei chain INPUT e OUTPUT per il workload nella tabella dei filtri della catena FORWARD.

Endpoints Host

Politica dell'Endpoint Host (2)

Oltre al CNI (container network interface), le politiche di Calico forniscono la possibilità di proteggere direttamente l'host. In Calico puoi creare un endpoint host definendo una combinazione dell'interfaccia host e, se necessario, dei numeri di porta. L'applicazione delle politiche per questa entità si ottiene tramite la tabella dei filtri nelle catene INPUT e OUTPUT. Come si può vedere dal diagramma, (2) queste vengono applicate ai processi locali sul nodo/host. Quindi, se hai creato una politica che viene applicata a un endpoint host, non influenzerà il traffico che va e viene dai tuoi pod. Tuttavia, offre un'interfaccia/sintassi uniforme per bloccare il traffico per il tuo host e i pod tramite le politiche di Calico. Questo semplifica notevolmente il processo di gestione delle politiche per una rete eterogenea. Configurare le politiche degli endpoint host per migliorare la protezione del cluster è un ulteriore importante caso d'uso.

Politica ApplyOnForward (3)

L'opzione ApplyOnForward è disponibile nella politica di rete globale di Calico per consentire l'applicazione delle politiche a tutto il traffico che passa attraverso l'endpoint host, incluso il traffico che sarà inoltrato dall'host. Questo traffico include quello inviato al pod locale o altrove nella rete. Calico richiede che questo parametro sia attivato per le politiche che utilizzano PreDNAT e untracked, vedi le sezioni successive. Inoltre, ApplyOnForward può essere utilizzato per monitorare il traffico dell'host in caso di utilizzo di un router virtuale o di NAT software.

Si prega di notare che se è necessario applicare la stessa politica di rete sia per i processi host che per i pod, non è necessario utilizzare l'opzione ApplyOnForward. È sufficiente creare un label per gli endpoint host e gli endpoint di workload (pod) desiderati. Calico è abbastanza intelligente da applicare la politica sulla base delle label, indipendentemente dal tipo di endpoint (hostendpoint o workload).

Politica PreDNAT (4)

In Kubernetes, le porte dell'entità service possono essere esposte all'esterno utilizzando l'opzione NodePorts oppure, facoltativamente (se si utilizza Calico), dichiarandole attraverso le opzioni Cluster IPs o External IPs. Kube-proxy bilancia il traffico in ingresso, legato al service, ai pod corrispondenti, utilizzando DNAT. Considerando questo, come è possibile applicare le politiche per il traffico che arriva tramite NodePorts? Affinché queste politiche siano applicate prima che il traffico venga elaborato dal DNAT (che rappresenta la corrispondenza host:porta e il relativo service), Calico fornisce un parametro per globalNetworkPolicy chiamato "preDNAT: true".

Quando il pre-DNAT è attivato, queste politiche vengono implementate in (4) nel diagramma — nella tabella mangle nella catena PREROUTING — direttamente prima del DNAT. L'ordine delle politiche (order) non è qui rispettato, poiché l'applicazione di queste politiche avviene molto prima nel percorso di elaborazione del traffico. Tuttavia, le politiche preDNAT rispettano l'ordine di applicazione (order) tra di loro.

Quando si creano politiche con pre-DNAT, è importante prestare attenzione al traffico che si desidera elaborare e consentire alla maggior parte di essere rifiutata. Il traffico contrassegnato come ‘allow’ nella politica pre-DNAT non sarà più controllato dalla politica hostendpoint, mentre il traffico che fallisce il passaggio della politica pre-DNAT continuerà il suo percorso attraverso le altre catene.
Calico ha reso obbligatoria l'attivazione dell'opzione applyOnForward quando si utilizza il preDNAT, poiché per definizione la destinazione del traffico non è ancora selezionata. Il traffico può essere diretto a un processo host oppure può essere reindirizzato a un pod o a un'altra nodo.

Politica Untracked (5)

Le reti e le applicazioni possono presentare grandi differenze nel comportamento. In alcuni casi estremi, le applicazioni possono generare molteplici connessioni brevi. Ciò può portare a una mancanza di memoria nel conntrack (il componente principale dello stack di rete di Linux). Tradizionalmente, per eseguire applicazioni di questo tipo in Linux è necessario configurare manualmente o disabilitare il conntrack, o scrivere regole iptables per aggirarlo. La policy Untracked in Calico è un'opzione più semplice ed efficace se desideri gestire le connessioni nel modo più rapido possibile. Ad esempio, se utilizzi un memcache o come misura di protezione aggiuntiva contro DDOS.

Leggi questo blog post (o la nostra traduzione) per ulteriori informazioni, inclusi i test delle prestazioni utilizzando la policy untracked.

Quando imposti l'opzione «doNotTrack: true» nella Calico globalNetworkPolicy, diventa una policy **non tracciata** e viene applicata nelle prime fasi della pipeline di elaborazione dei pacchetti di Linux. Se osservi il diagramma sopra, le policy untracked vengono applicate nelle catene PREROUTING e OUTPUT nella tabella raw, prima che venga avviato il tracciamento delle connessioni (conntrack). Quando un pacchetto è autorizzato dalla policy untracked, viene contrassegnato per disattivare il tracciamento della connessione per quel pacchetto. Ciò significa:

• La policy untracked è applicata a ogni pacchetto. Non esiste il concetto di connessione (o flusso). L'assenza di connessioni comporta alcune importanti conseguenze:
• Se desideri consentire sia il traffico delle richieste che quello delle risposte, è necessario avere una regola sia per il traffico in entrata che per quello in uscita (poiché Calico in genere utilizza la conntrack per contrassegnare il traffico di risposta come autorizzato).
• La policy untracked non funziona per i workload Kubernetes (pod), poiché in questo caso non c'è modo di tracciare la connessione in uscita da un pod.
• Il NAT non funziona correttamente con i pacchetti non tracciati (poiché il kernel memorizza il mapping NAT nel conntrack).
• Attraverso la regola «consenti tutto» nella policy untracked, tutti i pacchetti verranno contrassegnati come non tracciati. Questo non è quasi mai ciò di cui hai bisogno, quindi è importante essere molto selettivi rispetto ai pacchetti autorizzati dalle policy untracked (e consentire alla maggior parte del traffico di passare attraverso le normali policy tracciate).
• Le politiche non tracciate vengono applicate all'inizio del processo di elaborazione dei pacchetti. È molto importante tenerlo a mente quando si creano politiche Calico. Potresti avere una politica per un pod con order:1 e una politica non tracciata con order:1000. Questo non avrà importanza. La politica non tracciata verrà applicata prima della politica per il pod. Le politiche non tracciate rispettano l'ordine di esecuzione solo tra loro.

Poiché uno degli obiettivi della politica doNotTrack è forzare l'applicazione della politica nella fase più precoce del processo di elaborazione dei pacchetti Linux, Calico richiede di specificare l'opzione applyOnForward quando si utilizza doNotTrack. Guardando al diagramma di elaborazione dei pacchetti, si noti che la politica non tracciata (5) viene applicata prima di qualsiasi decisione di instradamento. Il traffico può essere indirizzato a un processo host, oppure può essere reindirizzato a un pod o a un'altra nodo.

Conclusioni

Abbiamo esaminato diverse opzioni di politiche (Host endpoint, ApplyOnForward, preDNAT e Untracked) in Calico e come vengono applicate durante il percorso di elaborazione dei pacchetti. Comprendere la loro essenza aiuta a sviluppare politiche efficaci e sicure. Con Calico puoi utilizzare politiche di rete globali, che vengono applicate a un'etichetta (un gruppo di nodi e pod) e applicare politiche con vari parametri. Ciò consente a esperti di sicurezza e progettazione di reti di proteggere comodamente "tutto" (tipi di endpoint), utilizzando un linguaggio uniforme di politiche con le politiche Calico.

Ringraziamenti: Vorrei ringraziare Sean Crampton e Alex Pollitt per la loro revisione e per le informazioni preziose.

Fonte: habr.com