🥇Comprendendo as opcións de política de rede con Calico

O complemento de rede Calico ofrece unha ampla gama de políticas de rede cunha sintaxe unificada para protexer os hosts de hardware, as máquinas virtuais e os pods. Estas políticas pódense aplicar dentro dun espazo de nomes ou ser políticas de rede globais que se apliquen a punto final do host (para protexer as aplicacións que se executan directamente no host - o host pode ser un servidor ou unha máquina virtual) ou punto final de carga de traballo (para protexer as aplicacións que se executan en contedores ou máquinas virtuais aloxadas). As políticas de Calico permítenche aplicar medidas de seguridade en varios puntos da ruta dun paquete mediante opcións como preDNAT, unraracked e applyOnForward. Comprender como funcionan estas opcións pode axudar a mellorar a seguridade e o rendemento do teu sistema en xeral. Este artigo explica a esencia destas opcións de política de Calico (preDNAT, unraracked e applyOnForward) aplicadas aos puntos finais do host, facendo énfase no que ocorre nas rutas de procesamento de paquetes (cadeas iptabels).

Este artigo asume que tes unha comprensión básica de como funcionan as políticas de rede de Kubernetes e Calico. Se non, recomendamos probalo Tutorial básico de políticas de rede и tutorial de protección do host usando Calico antes de ler este artigo. Tamén esperamos que teña unha comprensión básica do traballo iptables en linux.

chita política global de redes permítelle aplicar un conxunto de regras de acceso por etiquetas (a grupos de hosts e cargas de traballo/pods). Isto é moi útil se usas sistemas heteroxéneos xuntos: máquinas virtuais, un sistema directamente no hardware ou unha infraestrutura kubernetes. Ademais, pode protexer o seu clúster (nodos) mediante un conxunto de políticas declarativas e aplicar políticas de rede ao tráfico entrante (por exemplo, a través do servizo NodePorts ou IPs externas).

Nun nivel fundamental, cando Calico conecta un pod á rede (ver diagrama a continuación), conéctao ao host mediante unha interface Ethernet virtual (veth). O tráfico enviado polo pod chega ao host desde esta interface virtual e procédese do mesmo xeito que se procedese dunha interface de rede física. Por defecto, Calico nomea estas interfaces caliXXX. Dado que o tráfico pasa pola interface virtual, pasa por iptables coma se o pod estivese a un salto de distancia. Polo tanto, cando o tráfico chega a/desde un pod, remítese desde o punto de vista do host.

Nun nodo de Kubernetes que executa Calico, pode asignar unha interface virtual (veth) a unha carga de traballo do seguinte xeito. No seguinte exemplo, podes ver que veth#10 (calic1cbf1ca0f8) está conectado a cnx-manager-* no espazo de nomes 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
...

Dado que Calico crea unha interface veth para cada carga de traballo, como aplica as políticas? Para iso, Calico crea ganchos en varias cadeas da ruta de procesamento de paquetes mediante iptables.

O seguinte diagrama mostra as cadeas implicadas no procesamento de paquetes en iptables (ou o subsistema netfilter). Cando un paquete chega a través dunha interface de rede, primeiro pasa pola cadea PREROUTING. A continuación tómase unha decisión de enrutamento e, en función diso, o paquete pasa por INPUT (dirixido aos procesos host) ou FORWARD (dirixido a un pod ou outro nodo da rede). Desde o proceso local, o paquete pasa pola cadea OUTPUT e despois POSTROUTING antes de ser enviado polo cable.

Teña en conta que o pod tamén é unha entidade externa (conectada ao veth) en termos de procesamento de iptables. Imos resumir:

O tráfico reenviado (nat, enrutado ou a/desde un pod) pasa polas cadeas PREROUTING - FORWARD - POSTROUTING.
O tráfico ao proceso de host local pasa pola cadea PREROUTING - INPUT.
O tráfico do proceso host local pasa pola cadea OUTPUT - POSTROUTING.

Calico ofrece opcións de políticas que che permiten aplicar políticas en todas as cadeas. Tendo isto en conta, vexamos as diferentes opcións de configuración de políticas dispoñibles en Calico. Os números da lista de opcións a continuación corresponden aos números do diagrama anterior.

Política de punto final de carga de traballo (pod).
Política do punto final do host
Opción ApplyOnForward
Política PreDNAT
Política sen rastrexar

Comecemos por ver como se aplican as políticas aos puntos finais de carga de traballo (pods Kubernetes ou máquinas virtuales OpenStack) e despois vexamos as opcións de políticas para os puntos finais de host.

Puntos finais de carga de traballo

Política de punto final de carga de traballo (1)

Esta é unha opción para protexer os teus pods de kubernetes. Calico admite traballar con Kubernetes NetworkPolicy, pero tamén ofrece políticas adicionais: Calico NetworkPolicy e GlobalNetworkPolicy. Calico crea unha cadea para cada pod (carga de traballo) e engancha nas cadeas INPUT e OUTPUT para a carga de traballo á táboa de filtros da cadea FORWARD.

Puntos finais do host

Política de punto final de host (2)

Ademais de CNI (interfaz de rede de contedores), as políticas de Calico proporcionan a capacidade de protexer o propio host. En Calico, pode crear un punto final de host especificando unha combinación da interface de host e, se é necesario, números de porto. A aplicación das políticas para esta entidade conséguese mediante unha táboa de filtros nas cadeas INPUT e OUTPUT. Como podes ver no diagrama, (2) aplícanse aos procesos locais no nodo/host. É dicir, se crea unha política que se aplique ao punto final do host, non afectará ao tráfico que vai desde/hasta os seus pods. Pero proporciona unha única interface/sintaxe para bloquear o tráfico para o teu host e pods usando políticas de Calico. Isto simplifica moito o proceso de xestión de políticas para unha rede heteroxénea. Configurar políticas do punto final do host para mellorar a seguridade do clúster é outro caso de uso importante.

Política de AplicaciónOnForward (3)

A opción ApplyOnForward está dispoñible na política de rede global de Calico para permitir que se apliquen políticas a todo o tráfico que pasa polo punto final do host, incluído o tráfico que será reenviado polo host. Isto inclúe o tráfico reenviado ao pod local ou a calquera outro lugar da rede. Calico require que este axuste estea activado para políticas que usan PreDNAT e non se rastrexa; consulte as seguintes seccións. Ademais, ApplyOnForward pódese usar para supervisar o tráfico do host nos casos en que se utilice un enrutador virtual ou un software NAT.

Teña en conta que se precisa aplicar a mesma política de rede tanto aos procesos anfitrións como aos pods, entón non necesita utilizar a opción ApplyOnForward. Todo o que tes que facer é crear unha etiqueta para o punto final de host e o punto final de carga de traballo (pod). Calico é o suficientemente intelixente como para facer cumprir políticas baseadas en etiquetas, independentemente do tipo de punto final (punto de conexión ou carga de traballo).

Política PreDNAT (4)

En Kubernetes, os portos das entidades de servizo pódense expoñer externamente mediante a opción NodePorts ou, opcionalmente (cando se usa Calico), publicándoos mediante as opcións de IP de clúster ou IP externas. Kube-proxy equilibra o tráfico entrante vinculado a un servizo aos pods do servizo correspondente mediante DNAT. Tendo en conta isto, como se aplican as políticas para o tráfico que chega a través de NodePorts? Para garantir que estas políticas se apliquen antes de que DNAT procese o tráfico (que é unha asignación entre host:port e servizo correspondente), Calico proporciona un parámetro para globalNetworkPolicy chamado "preDNAT: true".

Cando pre-DNAT está activado, estas políticas impléntanse en (4) no diagrama - na táboa de mangle da cadea PREROUTING - inmediatamente antes de DNAT. Aquí non se segue a orde habitual das políticas, xa que a aplicación destas políticas ocorre moito antes na ruta de procesamento do tráfico. Non obstante, as políticas preDNAT respectan a orde de aplicación entre elas.

Ao crear políticas con pre-DNAT, é importante ter coidado co tráfico que quere procesar e permitir que a maioría sexa rexeitada. O tráfico marcado como "permitido" na política pre-DNAT xa non será comprobado pola política de hostendpoint, mentres que o tráfico que falla a política pre-DNAT continuará polas cadeas restantes.
Calico fixo obrigatorio activar a opción applyOnForward cando se utiliza preDNAT, xa que por definición aínda non se seleccionou o destino do tráfico. O tráfico pode dirixirse ao proceso host ou reenviarse a un pod ou a outro nodo.

Política sen rastrexar (5)

As redes e as aplicacións poden ter grandes diferenzas de comportamento. Nalgúns casos extremos, as aplicacións poden xerar moitas conexións de curta duración. Isto pode provocar que conntrack (un compoñente central da pila de rede de Linux) quede sen memoria. Tradicionalmente, para executar este tipo de aplicacións en Linux, tería que configurar ou desactivar manualmente conntrack, ou escribir regras de iptables para evitar conntrack. A política sen rastrexar en Calico é unha opción máis sinxela e eficiente se queres procesar as conexións o máis rápido posible. Por exemplo, se usas masivo memcache ou como medida adicional de protección contra DDOS.

Le isto blog (Ou nosa tradución) para obter máis información, incluídas as probas de rendemento mediante a política sen seguimento.

Cando estableces a opción "doNotTrack: true" en Calico globalNetworkPolicy, convértese nunha política **sen rastrexar** e aplícase moi cedo na canalización de procesamento de paquetes de Linux. Mirando o diagrama anterior, as políticas sen rastrexar aplícanse nas cadeas PREROUTING e OUTPUT da táboa bruta antes de que se inicie o seguimento de conexións (conntrack). Cando un paquete está permitido pola política sen rastrexar, márcase para desactivar o seguimento de conexións para ese paquete. Significa:

A política sen rastrexar aplícase por paquete. Non hai concepto de conexión (ou fluxo). A falta de conexións ten varias consecuencias importantes:
Se queres permitir o tráfico de solicitudes e respostas, necesitas unha regra tanto para a entrada como para a saída (xa que Calico normalmente usa conntrack para marcar o tráfico de resposta como permitido).
A política sen rastrexar non funciona para as cargas de traballo de Kubernetes (pods), porque neste caso non hai forma de rastrexar a conexión saínte do pod.
NAT non funciona correctamente con paquetes sen rastrexar (xa que o núcleo almacena a asignación NAT en conntrack).
Ao pasar pola regra "permitir todo" na política sen rastrexar, todos os paquetes marcaranse como sen rastrexar. Isto case sempre non é o que queres, polo que é importante ser moi selectivo sobre os paquetes permitidos polas políticas sen rastrexar (e permitir que a maior parte do tráfico pase polas políticas de rastrexo normais).
As políticas sen rastrexar aplícanse ao principio do proceso de procesamento de paquetes. É moi importante entender isto ao crear políticas de Calico. Podes ter unha política de pod con order:1 e unha política sen seguimento con order:1000. Non importará. A política Untracked aplicarase antes que a política para o pod. As políticas sen rastrexar só respectan a orde de execución entre elas.

Dado que un dos propósitos da política doNotTrack é facer cumprir a política moi pronto no proceso de procesamento de paquetes de Linux, Calico fai obrigatorio especificar a opción applyOnForward cando se usa doNotTrack. Facendo referencia ao diagrama de procesamento de paquetes, teña en conta que a política non rastrexada(5) aplícase antes de tomar calquera decisión de encamiñamento. O tráfico pode dirixirse ao proceso host ou reenviarse a un pod ou a outro nodo.

Resultados de

Analizamos as distintas opcións de política (punto final de host, ApplyOnForward, preDNAT e Untracked) en Calico e como se aplican ao longo da ruta de procesamento de paquetes. Comprender como funcionan axuda a desenvolver políticas eficaces e seguras. Con Calico pode utilizar unha política de rede global que se aplica a unha etiqueta (un grupo de nodos e pods) e aplicar políticas con varios parámetros. Isto permite que os profesionais da seguridade e do deseño de redes poidan protexer "todo" (tipos de extremos) á vez usando unha única linguaxe de políticas coas políticas de Calico.

Agradecemento: gustaríame agradecer Sean Crampton и Alexa Pollitta pola súa revisión e información valiosa.

Fonte: www.habr.com

Comprender as opcións de política de rede con Calico