El connector de xarxa Calico proporciona una àmplia gamma de polítiques de xarxa amb una sintaxi unificada per protegir els amfitrions de maquinari, les màquines virtuals i els pods. Aquestes polítiques es poden aplicar dins d'un espai de noms o ser polítiques globals de xarxa que s'apliquen a (per protegir les aplicacions que s'executen directament a l'amfitrió: l'amfitrió pot ser un servidor o una màquina virtual) o (per protegir les aplicacions que s'executen en contenidors o màquines virtuals allotjades). Les polítiques de Calico us permeten aplicar mesures de seguretat en diversos punts del camí d'un paquet mitjançant opcions com ara preDNAT, unraracked i applyOnForward. Entendre com funcionen aquestes opcions pot ajudar a millorar la seguretat i el rendiment del vostre sistema en general. Aquest article explica l'essència d'aquestes opcions de política de Calico (preDNAT, unraracked i applyOnForward) aplicades als punts finals de l'amfitrió, amb èmfasi en el que passa a les rutes de processament de paquets (cadenes iptabels).
En aquest article s'assumeix que teniu una comprensió bàsica de com funcionen les polítiques de xarxa de Kubernetes i Calico. Si no, us recomanem que ho proveu и fent servir Calico abans de llegir aquest article. També esperem que tingueu una comprensió bàsica del treball en linux.
Calic permet aplicar un conjunt de regles d'accés per etiquetes (a grups d'amfitrions i càrregues de treball/pods). Això és molt útil si feu servir sistemes heterogenis junts: màquines virtuals, un sistema directament al maquinari o una infraestructura de Kubernetes. A més, podeu protegir el vostre clúster (nodes) mitjançant un conjunt de polítiques declaratives i aplicar polítiques de xarxa al trànsit entrant (per exemple, mitjançant el servei NodePorts o IPs externes).
En un nivell fonamental, quan Calico connecta un pod a la xarxa (vegeu el diagrama següent), el connecta a l'amfitrió mitjançant una interfície Ethernet virtual (veth). El trànsit enviat pel pod arriba a l'amfitrió des d'aquesta interfície virtual i es processa de la mateixa manera que si provingués d'una interfície de xarxa física. Per defecte, Calico anomena aquestes interfícies caliXXX. Com que el trànsit passa per la interfície virtual, passa per iptables com si el pod estigués a un salt de distància. Per tant, quan el trànsit arriba a/des d'un pod, es reenvia des del punt de vista de l'amfitrió.
En un node de Kubernetes que executa Calico, podeu assignar una interfície virtual (veth) a una càrrega de treball de la manera següent. A l'exemple següent, podeu veure que veth#10 (calic1cbf1ca0f8) està connectat a cnx-manager-* a l'espai de noms de 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
...
Tenint en compte que Calico crea una interfície veth per a cada càrrega de treball, com fa complir les polítiques? Per fer-ho, Calico crea ganxos en diverses cadenes de la ruta de processament de paquets mitjançant iptables.
El diagrama següent mostra les cadenes implicades en el processament de paquets a iptables (o el subsistema netfilter). Quan un paquet arriba a través d'una interfície de xarxa, primer passa per la cadena PREROUTING. Aleshores es pren una decisió d'encaminament i, en funció d'això, el paquet passa per INPUT (dirigit als processos host) o FORWARD (dirigit a un pod o un altre node de la xarxa). Des del procés local, el paquet passa per la cadena OUTPUT i després POSTROUTING abans de ser enviat pel cable.
Tingueu en compte que el pod també és una entitat externa (connectada al veth) pel que fa al processament d'iptables. Resumim:
- El trànsit reenviat (nat, encaminat o cap a/des d'un pod) passa per les cadenes PREROUTING - FORWARD - POSTROUTING.
- El trànsit al procés d'amfitrió local passa per la cadena PREROUTING - INPUT.
- El trànsit del procés d'amfitrió local passa per la cadena OUTPUT - POSTROUTING.
Calico ofereix opcions de polítiques que us permeten aplicar polítiques a totes les cadenes. Tenint això en compte, mirem les diferents opcions de configuració de polítiques disponibles a Calico. Els números de la llista d'opcions a continuació corresponen als números del diagrama anterior.
- Política de punt final de càrrega de treball (pod).
- Política de punt final de l'amfitrió
- Opció ApplyOnForward
- Política PreDNAT
- Política sense seguiment
Comencem mirant com s'apliquen les polítiques als punts finals de càrrega de treball (pods Kubernetes o màquines virtuals d'OpenStack) i, a continuació, analitzem les opcions de política per als punts finals de l'amfitrió.
Punts finals de càrrega de treball
Política de punt final de càrrega de treball (1)
Aquesta és una opció per protegir els vostres pods de kubernetes. Calico admet treballar amb Kubernetes NetworkPolicy, però també proporciona polítiques addicionals: Calico NetworkPolicy i GlobalNetworkPolicy. Calico crea una cadena per a cada pod (càrrega de treball) i enganxa les cadenes INPUT i OUTPUT per a la càrrega de treball a la taula de filtres de la cadena FORWARD.
Punts finals de l'amfitrió
Política de punt final de l'amfitrió (2)
A més de CNI (interfície de xarxa de contenidors), les polítiques de Calico ofereixen la possibilitat de protegir el propi host. A Calico, podeu crear un punt final d'amfitrió especificant una combinació de la interfície de l'amfitrió i, si cal, números de port. L'aplicació de les polítiques d'aquesta entitat s'aconsegueix mitjançant una taula de filtres a les cadenes INPUT i OUTPUT. Com podeu veure al diagrama, (2) s'apliquen als processos locals del node/amfitrió. És a dir, si creeu una política que s'aplica al punt final de l'amfitrió, no afectarà el trànsit que va cap als vostres pods. Però proporciona una única interfície/sintaxi per bloquejar el trànsit del vostre amfitrió i pods mitjançant polítiques de Calico. Això simplifica molt el procés de gestió de polítiques per a una xarxa heterogènia. Configurar polítiques de punt final d'amfitrió per millorar la seguretat del clúster és un altre cas d'ús important.
Política d'ApplyOnForward (3)
L'opció ApplyOnForward està disponible a la política de xarxa global de Calico per permetre que les polítiques s'apliquin a tot el trànsit que passa pel punt final de l'amfitrió, inclòs el trànsit que serà reenviat per l'amfitrió. Això inclou el trànsit reenviat al pod local o a qualsevol altre lloc de la xarxa. Calico requereix que aquest paràmetre estigui habilitat per a polítiques que utilitzen PreDNAT i no es fa el seguiment, consulteu les seccions següents. A més, ApplyOnForward es pot utilitzar per controlar el trànsit de l'amfitrió en els casos en què s'utilitza un encaminador virtual o un programari NAT.
Tingueu en compte que si necessiteu aplicar la mateixa política de xarxa tant als processos d'amfitrió com als pods, no cal que utilitzeu l'opció ApplyOnForward. Tot el que heu de fer és crear una etiqueta per al punt final de l'amfitrió i el punt final de la càrrega de treball (pod). Calico és prou intel·ligent com per fer complir la política basada en etiquetes, independentment del tipus de punt final (punt de connexió o càrrega de treball).
Política PreDNAT (4)
A Kubernetes, els ports d'entitats de servei es poden exposar externament mitjançant l'opció NodePorts o, opcionalment (quan s'utilitza Calico), publicant-los mitjançant les opcions IP de clúster o IP externes. Kube-proxy equilibra el trànsit entrant vinculat a un servei als pods del servei corresponent mitjançant DNAT. Tenint en compte això, com apliqueu les polítiques per al trànsit que arriba a través de NodePorts? Per garantir que aquestes polítiques s'apliquen abans que DNAT processi el trànsit (que és un mapeig entre host:port i el servei corresponent), Calico proporciona un paràmetre per a globalNetworkPolicy anomenat "preDNAT: true".
Quan el pre-DNAT està habilitat, aquestes polítiques s'implementen a (4) del diagrama, a la taula de mangle de la cadena PREROUTING, immediatament abans de DNAT. Aquí no se segueix l'ordre habitual de les polítiques, ja que l'aplicació d'aquestes polítiques es produeix molt abans en la ruta de processament del trànsit. Tanmateix, les polítiques preDNAT respecten l'ordre d'aplicació entre elles.
Quan creeu polítiques amb pre-DNAT, és important tenir cura amb el trànsit que voleu processar i permetre que es rebutgi la majoria. El trànsit marcat com a "permès" a la política anterior al DNA ja no es comprovarà per la política del punt d'acollida, mentre que el trànsit que falla la política anterior al DNA continuarà per les cadenes restants.
Calico ha fet obligatori habilitar l'opció applyOnForward quan s'utilitza preDNAT, ja que per definició encara no s'ha seleccionat la destinació del trànsit. El trànsit es pot dirigir al procés amfitrió, o bé es pot reenviar a un pod o un altre node.
Política sense seguiment (5)
Les xarxes i les aplicacions poden tenir grans diferències de comportament. En alguns casos extrems, les aplicacions poden generar moltes connexions de curta durada. Això pot fer que conntrack (un component bàsic de la pila de xarxes de Linux) es quedi sense memòria. Tradicionalment, per executar aquest tipus d'aplicacions a Linux, hauríeu de configurar o desactivar manualment conntrack, o escriure regles iptables per evitar conntrack. La política sense seguiment a Calico és una opció més senzilla i eficient si voleu processar connexions el més ràpidament possible. Per exemple, si feu servir massiu o com a mesura addicional de protecció contra .
Llegeix això (O ) per obtenir més informació, incloses les proves de rendiment amb una política sense seguiment.
Quan configureu l'opció "doNotTrack: true" a Calico globalNetworkPolicy, es converteix en una política **no rastrejada** i s'aplica molt aviat a la canalització de processament de paquets de Linux. Si observem el diagrama anterior, les polítiques sense seguiment s'apliquen a les cadenes PREROUTING i OUTPUT de la taula en brut abans que s'iniciï el seguiment de la connexió (conntrack). Quan la política sense seguiment permet un paquet, es marca per desactivar el seguiment de connexió per a aquest paquet. Significa:
- La política sense seguiment s'aplica per paquet. No hi ha concepte de connexió (o flux). La manca de connexions té diverses conseqüències importants:
- Si voleu permetre el trànsit de sol·licituds i de resposta, necessiteu una regla tant per a l'entrada com per a la sortida (ja que Calico normalment utilitza conntrack per marcar el trànsit de resposta com a permès).
- La política sense seguiment no funciona per a les càrregues de treball de Kubernetes (pods), perquè en aquest cas no hi ha manera de fer un seguiment de la connexió de sortida des del pod.
- NAT no funciona correctament amb paquets sense seguiment (ja que el nucli emmagatzema el mapeig NAT a conntrack).
- En passar per la regla "permetre tot" a la política sense seguiment, tots els paquets es marcaran com a sense seguiment. Això gairebé sempre no és el que voleu, per la qual cosa és important ser molt selectiu sobre els paquets permesos per les polítiques sense seguiment (i permetre que la majoria del trànsit passi per les polítiques de seguiment normals).
- Les polítiques sense seguiment s'apliquen al principi del procés de processament de paquets. Això és molt important entendre-ho a l'hora de crear polítiques de Calico. Podeu tenir una política de pod amb order:1 i una política sense seguiment amb order:1000. No importarà. La política sense seguiment s'aplicarà abans que la política del pod. Les polítiques sense seguiment només respecten l'ordre d'execució entre elles.
Com que un dels propòsits de la política doNotTrack és fer complir la política molt aviat en el processament de paquets de Linux, Calico fa que sigui obligatori especificar l'opció applyOnForward quan s'utilitza doNotTrack. En referència al diagrama de processament de paquets, tingueu en compte que la política sense seguiment (5) s'aplica abans de qualsevol decisió d'encaminament. El trànsit es pot dirigir al procés amfitrió, o bé es pot reenviar a un pod o un altre node.
Resultats de
Hem analitzat les diferents opcions de política (punt final de l'amfitrió, ApplyOnForward, preDNAT i Untracked) a Calico i com s'apliquen al llarg del camí de processament de paquets. Entendre com funcionen ajuda a desenvolupar polítiques efectives i segures. Amb Calico podeu utilitzar una política de xarxa global que s'aplica a una etiqueta (un grup de nodes i pods) i aplicar polítiques amb diversos paràmetres. Això permet als professionals de la seguretat i el disseny de xarxes protegir-ho còmodament "tot" (tipus de punt final) alhora utilitzant un únic llenguatge de política amb polítiques de Calico.
Agraïment: m'agradaria donar les gràcies и per la seva revisió i informació valuosa.
Font: www.habr.com