Il plug-in di rete Calico fornisce un'ampia gamma di policy di rete con una sintassi unificata per proteggere host hardware, macchine virtuali e pod. Queste policy possono essere applicate all'interno di uno spazio dei nomi o essere policy di rete globali applicabili a (per proteggere le applicazioni in esecuzione direttamente sull'host: l'host può essere un server o una macchina virtuale) o (per proteggere le applicazioni in esecuzione in contenitori o macchine virtuali ospitate). Le policy Calico ti consentono di applicare misure di sicurezza in vari punti del percorso di un pacchetto utilizzando opzioni come preDNAT, unracked e applyOnForward. Comprendere come funzionano queste opzioni può aiutare a migliorare la sicurezza e le prestazioni del sistema complessivo. Questo articolo spiega l'essenza di queste opzioni di policy Calico (preDNAT, unracked e applyOnForward) applicate agli endpoint host, con un'enfasi su ciò che accade nei percorsi di elaborazione dei pacchetti (catene iptabels).
Questo articolo presuppone che tu abbia una conoscenza di base del funzionamento delle policy di rete Kubernetes e Calico. In caso contrario, ti consigliamo di provarlo и utilizzando Calico prima di leggere questo articolo. Ci aspettiamo anche che tu abbia una conoscenza di base del lavoro in linux.
Calico consente di applicare una serie di regole di accesso in base alle etichette (a gruppi di host e carichi di lavoro/pod). Ciò è molto utile se si utilizzano insieme sistemi eterogenei: macchine virtuali, un sistema direttamente sull'hardware o un'infrastruttura Kubernetes. Inoltre, puoi proteggere il tuo cluster (nodi) utilizzando una serie di policy dichiarative e applicare policy di rete al traffico in entrata (ad esempio, tramite il servizio NodePort o IP esterni).
A livello fondamentale, quando Calico collega un pod alla rete (vedi diagramma sotto), lo collega all'host utilizzando 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, passa attraverso iptables come se il pod fosse a un passo di distanza. Pertanto, quando il traffico arriva da/verso un pod, viene inoltrato dal punto di vista dell'host.
Su un nodo Kubernetes che esegue Calico, puoi mappare un'interfaccia virtuale (veth) a un carico di lavoro come segue. Nell'esempio seguente, puoi vedere che veth#10 (calic1cbf1ca0f8) è connesso a cnx-manager-* nello spazio dei nomi calico-monitoring.
[centos@ip-172-31-31-46 K8S]$ sudo ip a
...
10: calic1cbf1ca0f8@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> 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 carico di lavoro, come applica le policy? Per fare ciò, Calico crea hook in varie catene del percorso di elaborazione dei pacchetti utilizzando iptables.
Il diagramma seguente mostra le catene coinvolte nell'elaborazione dei pacchetti in iptables (o nel sottosistema netfilter). Quando un pacchetto arriva attraverso un'interfaccia di rete, passa prima attraverso la catena PREROUTING. Viene quindi presa una decisione di instradamento e, in base a ciò, il pacchetto passa attraverso INPUT (diretto ai processi host) o FORWARD (diretto a un pod o a un altro nodo sulla rete). Dal processo locale, il pacchetto passa attraverso la catena OUTPUT e poi POSTROUTING prima di essere inviato lungo il cavo.
Tieni presente che il pod è anche un'entità esterna (connessa a veth) in termini di elaborazione di iptables. Riassumiamo:
- Il traffico inoltrato (nat, routed o da/verso un pod) passa attraverso le catene PREROUTING - FORWARD - POSTROUTING.
- Il traffico verso il processo host locale passa attraverso la catena PREROUTING - INPUT.
- Il traffico proveniente dal processo host locale passa attraverso la catena OUTPUT - POSTROUTING.
Calico fornisce opzioni di policy che ti consentono di applicare policy a tutte le catene. Tenendo questo in mente, diamo un'occhiata alle diverse opzioni di configurazione dei criteri disponibili in Calico. I numeri nell'elenco delle opzioni di seguito corrispondono ai numeri nel diagramma sopra.
- Criterio dell'endpoint (pod) del carico di lavoro
- Criterio dell'endpoint host
- Opzione Applica in avanti
- Politica PreDNAT
- Politica non tracciata
Iniziamo esaminando il modo in cui le policy vengono applicate agli endpoint del carico di lavoro (pod Kubernetes o VM OpenStack), quindi esaminiamo le opzioni delle policy per gli endpoint host.
Endpoint del carico di lavoro
Policy endpoint del carico di lavoro (1)
Questa è un'opzione per proteggere i tuoi pod Kubernetes. Calico supporta l'utilizzo di Kubernetes NetworkPolicy, ma fornisce anche policy aggiuntive: Calico NetworkPolicy e GlobalNetworkPolicy. Calico crea una catena per ciascun pod (carico di lavoro) e aggancia le catene INPUT e OUTPUT per il carico di lavoro alla tabella dei filtri della catena FORWARD.
Endpoint host
Policy endpoint host (2)
Oltre alla CNI (interfaccia di rete del contenitore), le policy Calico offrono la possibilità di proteggere l'host stesso. In Calico, puoi creare un endpoint host specificando una combinazione dell'interfaccia host e, se necessario, dei numeri di porta. L'applicazione delle policy per questa entità viene ottenuta utilizzando una tabella di filtro nelle catene INPUT e OUTPUT. Come puoi vedere dal diagramma, (2) si applicano ai processi locali sul nodo/host. Cioè, se crei una policy che si applica all'endpoint host, non influirà sul traffico diretto a/dai tuoi pod. Fornisce però un'unica interfaccia/sintassi per bloccare il traffico per il tuo host e i pod utilizzando le policy Calico. Ciò semplifica notevolmente il processo di gestione delle policy per una rete eterogenea. La configurazione delle policy dell'endpoint host per migliorare la sicurezza del cluster è un altro caso d'uso importante.
Politica ApplicaOnForward (3)
L'opzione ApplyOnForward è disponibile nella policy di rete globale Calico per consentire l'applicazione delle policy a tutto il traffico che passa attraverso l'endpoint host, incluso il traffico che verrà inoltrato dall'host. Ciò include il traffico inoltrato al pod locale o in qualsiasi altro punto della rete. Calico richiede che questa impostazione sia abilitata per le policy che utilizzano PreDNAT e non tracciate, vedere le sezioni seguenti. Inoltre, ApplyOnForward può essere utilizzato per monitorare il traffico host nei casi in cui viene utilizzato un router virtuale o un NAT software.
Tieni presente che se devi applicare la stessa politica di rete sia ai processi host che ai pod, non è necessario utilizzare l'opzione ApplyOnForward. Tutto quello che devi fare è creare un'etichetta per l'hostendpoint e l'endpoint del carico di lavoro (pod) richiesti. Calico è abbastanza intelligente da applicare policy basate su etichette, indipendentemente dal tipo di endpoint (hostendpoint o carico di lavoro).
Politica PreDNAT (4)
In Kubernetes, le porte delle entità di servizio possono essere esposte esternamente utilizzando l'opzione NodePorts o, facoltativamente (quando si utilizza Calico), pubblicizzandole utilizzando le opzioni IP cluster o IP esterni. Il proxy Kube bilancia il traffico in entrata legato a un servizio ai pod del servizio corrispondente utilizzando DNAT. Detto questo, come si applicano le policy per il traffico proveniente dalle NodePort? Per garantire che queste politiche vengano applicate prima che il traffico venga elaborato da DNAT (che è una mappatura tra host:porta e servizio corrispondente), Calico fornisce un parametro per globalNetworkPolicy chiamato "preDNAT: true".
Quando pre-DNAT è abilitato, queste politiche sono implementate in (4) nel diagramma - nella tabella mangle della catena PREROUTING - immediatamente prima di DNAT. In questo caso non viene seguito il consueto ordine delle politiche, poiché l'applicazione di queste politiche avviene molto prima nel percorso di elaborazione del traffico. Tuttavia, le politiche preDNAT rispettano l'ordine di applicazione tra di loro.
Quando si creano policy con pre-DNAT, è importante prestare attenzione al traffico che si desidera elaborare e consentire che la maggior parte venga rifiutata. Il traffico contrassegnato come "consentito" nella policy pre-DNAT non verrà più controllato dalla policy hostendpoint, mentre il traffico che non supera la policy pre-DNAT continuerà attraverso le catene rimanenti.
Calico ha reso obbligatorio abilitare l'opzione applyOnForward quando si utilizza preDNAT, poiché per definizione la destinazione del traffico non è stata ancora selezionata. Il traffico può essere indirizzato al processo host oppure può essere inoltrato a un pod o a un altro nodo.
Politica non tracciata (5)
Le reti e le applicazioni possono presentare grandi differenze di comportamento. In alcuni casi estremi, le applicazioni possono generare molte connessioni di breve durata. Ciò può causare l'esaurimento della memoria di conntrack (un componente principale dello stack di rete Linux). Tradizionalmente, per eseguire questi tipi di applicazioni su Linux, dovresti configurare o disabilitare manualmente conntrack o scrivere regole iptables per ignorare conntrack. La politica non tracciata in Calico è un'opzione più semplice ed efficiente se desideri elaborare le connessioni il più rapidamente possibile. Ad esempio, se usi Massive o come misura aggiuntiva di protezione contro .
Leggi questo (o ) per ulteriori informazioni, compresi i test delle prestazioni utilizzando criteri non tracciati.
Quando imposti l'opzione "doNotTrack: true" in Calico globalNetworkPolicy, diventa una policy **non tracciata** e viene applicata molto presto nella pipeline di elaborazione dei pacchetti Linux. Osservando il diagramma precedente, le policy non tracciate vengono applicate nelle catene PREROUTING e OUTPUT nella tabella grezza prima che venga avviato il tracciamento della connessione (conntrack). Quando un pacchetto è consentito dalla policy non tracciata, viene contrassegnato per disabilitare il tracciamento della connessione per quel pacchetto. Significa:
- La politica di non tracciabilità viene applicata pacchetto per pacchetto. Non esiste il concetto di connessione (o flusso). La mancanza di connessioni ha diverse conseguenze importanti:
- Se desideri consentire sia il traffico di richiesta che quello di risposta, hai bisogno di una regola sia per il traffico in entrata che per quello in uscita (poiché Calico in genere utilizza conntrack per contrassegnare il traffico di risposta come consentito).
- La policy non tracciata non funziona per i carichi di lavoro Kubernetes (pod), perché in questo caso non c'è modo di tracciare la connessione in uscita dal pod.
- NAT non funziona correttamente con i pacchetti non tracciati (poiché il kernel memorizza la mappatura NAT in conntrack).
- Quando si passa attraverso la regola "consenti tutto" nella policy non tracciata, tutti i pacchetti verranno contrassegnati come non tracciati. Questo non è quasi sempre ciò che desideri, quindi è importante essere molto selettivi riguardo ai pacchetti consentiti dalle policy non tracciate (e consentire alla maggior parte del traffico di passare attraverso le normali policy tracciate).
- Le policy non tracciate vengono applicate all'inizio della pipeline di elaborazione dei pacchetti. Questo è molto importante da capire quando si creano le politiche Calico. Puoi avere una policy pod con order:1 e una policy non tracciata con order:1000. Non avrà importanza. La policy Untracked verrà applicata prima della policy per il pod. Le politiche non tracciate rispettano l'ordine di esecuzione solo tra di loro.
Poiché uno degli scopi della policy doNotTrack è quello di applicare la policy molto presto nella pipeline di elaborazione dei pacchetti Linux, Calico rende obbligatorio specificare l'opzione applyOnForward quando si utilizza doNotTrack. Facendo riferimento al diagramma di elaborazione dei pacchetti, si noti che la politica untracked(5) viene applicata prima di qualsiasi decisione di routing. Il traffico può essere indirizzato al processo host oppure può essere inoltrato a un pod o a un altro nodo.
Risultati di
Abbiamo esaminato le varie opzioni di policy (endpoint host, ApplyOnForward, preDNAT e Untracked) in Calico e il modo in cui vengono applicate lungo il percorso di elaborazione dei pacchetti. Capire come funzionano aiuta a sviluppare politiche efficaci e sicure. Con Calico puoi utilizzare una policy di rete globale che si applica a un'etichetta (un gruppo di nodi e pod) e applicare policy con vari parametri. Ciò consente ai professionisti della sicurezza e della progettazione di rete di proteggere comodamente "tutto" (tipi di endpoint) contemporaneamente utilizzando un unico linguaggio di policy con le policy Calico.
Riconoscimenti: Vorrei ringraziare и per la loro recensione e preziose informazioni.
Fonte: habr.com