Il plugin di rete Calico offre un ampio set di politiche di rete con una sintassi unificata per proteggere gli host su hardware, macchine virtuali e pod. Queste politiche possono essere applicate all'interno di un namespace oppure essere politiche di rete globali applicabili a (per proteggere applicazioni che giacciono direttamente sull'host — l'host può essere un server o una macchina virtuale) oppure a (per proteggere applicazioni che operano in contenitori o macchine virtuali ospitate nell'host). Le politiche Calico permettono di implementare misure di sicurezza per vari punti di passaggio dei pacchetti con opzioni come preDNAT, unraracked e applyOnForward. Comprendere come funzionano queste opzioni può contribuire a migliorare la sicurezza e le prestazioni complessive del sistema. In questo articolo vengono spiegate le caratteristiche di queste opzioni di politiche Calico (preDNAT, unraracked e applyOnForward) applicate a endpoint host, ponendo l'accento su ciò che avviene nei percorsi di elaborazione dei pacchetti (catene iptables).
Questo articolo presuppone che abbiate una comprensione dei principi di base delle politiche di rete Kubernetes e Calico. Se non ne siete a conoscenza, vi consigliamo di provare e utilizzando Calico, prima di leggere questo articolo. Ci aspettiamo anche che tu abbia una comprensione di base del funzionamento in Linux.
Calico ti consente di applicare un insieme di regole di accesso per etichette (ai gruppi di host e workloads/pods). Questo è molto utile se utilizzi insieme sistemi eterogenei: macchine virtuali, sistema direttamente sull'hardware o infrastruttura Kubernetes. Inoltre, puoi proteggere il tuo cluster (nodi) utilizzando un insieme di politiche dichiarative e applicare politiche di rete al traffico in entrata (ad esempio, tramite i servizi NodePort o IP esterni).
A un livello fondamentale, quando Calico collega un pod alla rete (vedi diagramma qui sotto), lo connette a un host tramite un'interfaccia Ethernet virtuale (veth). Il traffico inviato dal pod arriva all'host da questa interfaccia virtuale e viene elaborato 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, viene trattato tramite iptables, come se il pod fosse a un solo hop di distanza. Pertanto, quando il traffico arriva/esce dal pod, viene inoltrato (forwarded) dal punto di vista dell'host.
Sulla nod Kubernetes su cui è in esecuzione Calico, puoi mappare l'interfaccia virtuale (veth) al workload nel seguente modo. Nell'esempio qui sotto, puoi vedere che veth#10 (calic1cbf1ca0f8) è collegata 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 hook in diverse catene del percorso di elaborazione dei pacchetti, utilizzando iptables.
Nella diagramma qui sotto sono mostrate le catene coinvolte nell'elaborazione dei pacchetti in iptables (o nel sottosistema netfilter). Quando un pacchetto arriva attraverso l'interfaccia di rete, passa prima attraverso la catena PREROUTING. Viene poi presa una decisione sul routing e, in base a questa, il pacchetto passa o attraverso INPUT (destinato ai processi dell'host) o attraverso FORWARD (destinato a un pod o a un'altra nodo nella rete). Da un processo locale, il pacchetto passa attraverso la catena OUTPUT e infine POSTROUTING prima di essere trasmesso.
Si noti che il pod è anche un oggetto esterno (collegato a veth) dal punto di vista dell'elaborazione iptables. Riassumendo:
- Il traffico inoltrato (forwarded) (nat, routable o in/da pod) passa attraverso le catene PREROUTING - FORWARD - POSTROUTING.
- Il traffico verso il processo host locale passa attraverso la catena PREROUTING - INPUT.
- Il traffico dal processo host locale passa attraverso la catena OUTPUT - POSTROUTING.
Calico offre opzioni per le politiche attraverso le quali è possibile applicare regole a tutti i flussi. Tenendo ciò a mente, esaminiamo le diverse configurazioni politiche disponibili in Calico. I numeri nell'elenco delle opzioni qui sotto corrispondono ai numeri nel diagramma sopra.
- Politica dell'endpoint workload (pod)
- Politica dell'endpoint host
- Opzione ApplyOnForward
- Politica PreDNAT
- Politica Untracked
Iniziamo esaminando come le politiche vengono applicate agli workload endpoints (pod di Kubernetes o VM OpenStack) e poi consideriamo le opzioni delle politiche per gli host endpoints.
Workload Endpoints
Politica Workload Endpoint (1)
Questa è un'opzione per proteggere i tuoi pod Kubernetes. Calico supporta l'uso di Kubernetes NetworkPolicy, ma fornisce anche politiche aggiuntive: Calico NetworkPolicy e GlobalNetworkPolicy. Calico crea una catena per ogni pod (workload) e implementa hook nelle catene INPUT e OUTPUT per il workload nella tabella dei filtri della catena FORWARD.
Host Endpoints
Politica Host Endpoint (2)
Oltre al CNI (container network interface), le politiche di Calico offrono la possibilità di proteggere direttamente l'host. In Calico, puoi creare un endpoint host specificando una combinazione dell'interfaccia dell'host e, se necessario, i numeri delle porte. L'applicazione delle politiche per questa entità avviene tramite la tabella dei filtri nelle catene INPUT e OUTPUT. Come mostrato nel diagramma, (2) vengono applicate ai processi locali nel nodo/host. Quindi, se hai creato una politica che si applica all'endpoint host, essa non influenzerà il traffico verso/da i tuoi pod. Tuttavia, essa fornisce un'interfaccia/sintassi unica per bloccare il traffico per il tuo host e i pod utilizzando le politiche di Calico. Questo semplifica notevolmente il processo di gestione delle politiche per una rete eterogenea. La configurazione delle politiche dell'endpoint host per rafforzare la protezione del cluster è un altro importante caso d'uso.
Politica ApplyOnForward (3)
L'opzione ApplyOnForward è disponibile nella politica di rete globale di Calico per consentire l'applicazione delle politiche su tutto il traffico che attraversa l'endpoint host, incluso il traffico che sarà inoltrato dall'host. Questo traffico comprende quello inviato a un pod locale o altrove nella rete. Calico richiede che questo parametro sia abilitato per le politiche che utilizzano PreDNAT e untracked, vedere i sezioni seguenti. Inoltre, ApplyOnForward può essere utilizzato per monitorare il traffico dell'host in caso di utilizzo di router virtuali o NAT software.
Si noti che se è necessario applicare la stessa politica di rete sia per i processi host che per i pod, non è obbligatorio utilizzare l'opzione ApplyOnForward. Basta creare un label per i relativi hostendpoint e workload endpoint (pod). Calico è sufficientemente intelligente da applicare la politica in base ai labels, indipendentemente dal tipo di endpoint (hostendpoint o workload).
Politica PreDNAT (4)
In Kubernetes, le porte delle entità service possono essere esposte all'esterno utilizzando l'opzione NodePorts oppure, facoltativamente (se si utilizza Calico), dichiarandole tramite le opzioni Cluster IPs o External IPs. Kube-proxy bilancia il traffico in entrata associato al service verso i pod del service corrispondente, utilizzando DNAT. Considerando ciò, come puoi applicare le politiche per il traffico in arrivo tramite NodePorts? Per fare in modo che queste politiche vengano applicate prima che il traffico venga elaborato da DNAT (che rappresenta il mapping host:porta e il relativo service), Calico fornisce un parametro per globalNetworkPolicy chiamato «preDNAT: true».
Quando pre-DNAT è attivato, queste politiche vengono attuate in (4) nel diagramma — nella catena mangle della tabella PREROUTING — immediatamente prima del DNAT. L'ordine normale delle politiche (order) non è rispettato qui, 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 il maggior numero possibile di rifiuti. Il traffico contrassegnato come ‘allow’ nella politica pre-DNAT non sarà più controllato dalla politica hostendpoint, mentre il traffico che non supera la politica pre-DNAT continuerà a passare attraverso le altre catene.
Calico ha reso obbligatoria l'inclusione dell'opzione applyOnForward quando si utilizza preDNAT, poiché per definizione la destinazione del traffico non è ancora stata selezionata. Il traffico può essere indirizzato a un processo host, oppure può essere reindirizzato a un pod o a un'altra nodo.
Politica non tracciata (5)
Le reti e le applicazioni possono presentare significative differenze nel comportamento. In alcuni casi estremi, le applicazioni possono generare moltissime connessioni temporanee. Questo può portare a una carenza di memoria in conntrack (il componente principale dello stack di rete di Linux). Tradizionalmente, per eseguire questo tipo di applicazioni su Linux è necessario configurare manualmente o disabilitare conntrack, oppure scrivere regole iptables per bypassare conntrack. La politica Untracked in Calico è un'opzione più semplice ed efficace se desideri gestire le connessioni nel modo più rapido possibile. Ad esempio, se utilizzi un massivo o come ulteriore misura di protezione contro .
Leggi questo (o ) per ulteriori informazioni, comprese le prove delle prestazioni utilizzando la politica untracked.
Quando imposti l'opzione «doNotTrack: true» nella globalNetworkPolicy di Calico, diventa una policy **non tracciabile** e viene applicata all'inizio del pipeline di elaborazione dei pacchetti di Linux. Se guardi 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 è consentito dalla policy untracked, viene contrassegnato per disabilitare il tracciamento della connessione per quel pacchetto. Ciò significa:
- La policy untracked si applica a ogni pacchetto. Non esiste il concetto di connessione (o flusso). L'assenza di connessioni comporta diverse importanti conseguenze:
- Se desideri consentire sia il traffico di richiesta che quello di risposta, è necessario avere una regola sia per il traffico in entrata che per quello in uscita (poiché Calico di solito utilizza conntrack per contrassegnare il traffico di risposta come consentito).
- La policy untracked non funziona per i workload Kubernetes (pod) perché, in questo caso, non c'è modo di tracciare la connessione in uscita da un pod.
- Il NAT funziona in modo errato con i pacchetti non tracciabili (poiché il kernel memorizza il mapping NAT in conntrack).
- Quando si utilizza la regola "consenti tutto" nelle politiche untracked, tutti i pacchetti verranno contrassegnati come non tracciati. Questo quasi sempre non è ciò di cui hai bisogno, pertanto è importante essere molto selettivi sui pacchetti consentiti dalle politiche untracked (e permettere a una parte maggiore del traffico di passare attraverso politiche di tracciamento normali).
- Le politiche untracked vengono applicate all'inizio del processo di elaborazione dei pacchetti. È fondamentale comprendere questo aspetto durante la creazione delle politiche Calico. Puoi avere una politica per il pod con order:1 e una politica untracked con order:1000. Questo non avrà importanza. La politica untracked sarà applicata prima di quella per il pod. Le politiche untracked rispettano solo l'ordine di esecuzione tra di loro.
Poiché uno degli obiettivi della politica doNotTrack è forzare l'applicazione della politica nelle prime fasi del processo di elaborazione dei pacchetti Linux, Calico richiede che l'opzione applyOnForward sia specificata quando si utilizza doNotTrack. Riferendosi al diagramma di elaborazione dei pacchetti, si noti che la politica untracked (5) viene applicata prima di qualsiasi decisione di instradamento. Il traffico può essere indirizzato al processo host, oppure può essere reindirizzato a un pod o a un'altra nodo.
Risultati
Abbiamo esaminato diverse opzioni di politiche (Host endpoint, ApplyOnForward, preDNAT e Untracked) in Calico e come vengono applicate nel processo di gestione dei pacchetti. Comprendere la loro essenza aiuta a sviluppare politiche efficaci e sicure. Con Calico puoi utilizzare global network policy, che viene applicata all'etichetta (gruppo di nodi e pod) e applicare politiche con vari parametri. Ciò consente agli esperti di sicurezza e ai progettisti di rete di proteggere comodamente tutto (tipi di endpoint), utilizzando un linguaggio uniforme delle politiche con le politiche Calico.
Ringraziamenti: Vorrei ringraziare e per le loro revisioni e per le preziose informazioni.
Fonte: habr.com
