🥇Comprensión de las opciones de políticas de red con Calico

El complemento de red Calico proporciona una amplia gama de políticas de red con una sintaxis unificada para proteger hosts de hardware, máquinas virtuales y pods. Estas políticas se pueden aplicar dentro de un espacio de nombres o ser políticas de red global que se aplican a punto final del host (para proteger las aplicaciones que se ejecutan directamente en el host; el host puede ser un servidor o una máquina virtual) o punto final de carga de trabajo (para proteger aplicaciones que se ejecutan en contenedores o máquinas virtuales alojadas). Las políticas de Calico le permiten aplicar medidas de seguridad en varios puntos de la ruta de un paquete utilizando opciones como preDNAT, unrack y applyOnForward. Comprender cómo funcionan estas opciones puede ayudar a mejorar la seguridad y el rendimiento de su sistema en general. Este artículo explica la esencia de estas opciones de política de Calico (preDNAT, unraracked y applyOnForward) aplicadas a los puntos finales del host, con énfasis en lo que sucede en las rutas de procesamiento de paquetes (cadenas itabels).

Este artículo supone que tiene un conocimiento básico de cómo funcionan las políticas de red de Kubernetes y Calico. Si no, te recomendamos probarlo. tutorial básico de política de red и tutorial de protección de host usando Calico antes de leer este artículo. También esperamos que tenga una comprensión básica del trabajo. iptables en linux

Calicó política de red global le permite aplicar un conjunto de reglas de acceso por etiquetas (a grupos de hosts y cargas de trabajo/pods). Esto es muy útil si usa sistemas heterogéneos juntos: máquinas virtuales, un sistema directamente en hardware o una infraestructura de Kubernetes. Además, puede proteger su clúster (nodos) utilizando un conjunto de políticas declarativas y aplicar políticas de red al tráfico entrante (por ejemplo, a través del servicio NodePorts o IP externas).

En un nivel fundamental, cuando Calico conecta un pod a la red (consulte el diagrama a continuación), lo conecta al host mediante una interfaz Ethernet virtual (veth). El tráfico enviado por el pod llega al host desde esta interfaz virtual y se procesa de la misma manera que si viniera de una interfaz de red física. De forma predeterminada, Calico nombra estas interfaces caliXXX. Dado que el tráfico llega a través de la interfaz virtual, pasa por iptables como si el pod estuviera a un salto de distancia. Por lo tanto, cuando el tráfico llega o sale de un pod, se reenvía desde el punto de vista del host.

En un nodo de Kubernetes que ejecuta Calico, puede asignar una interfaz virtual (veth) a una carga de trabajo de la siguiente manera. En el siguiente ejemplo, puede ver que veth#10 (calic1cbf1ca0f8) está conectado a cnx-manager-* en el espacio de nombres 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 una interfaz quinta para cada carga de trabajo, ¿cómo aplica las políticas? Para hacer esto, Calico crea ganchos en varias cadenas de la ruta de procesamiento de paquetes usando iptables.

El siguiente diagrama muestra las cadenas involucradas en el procesamiento de paquetes en iptables (o el subsistema netfilter). Cuando un paquete llega a través de una interfaz de red, primero pasa por la cadena PREROUTING. Luego se toma una decisión de enrutamiento y, en función de esto, el paquete pasa por INPUT (dirigido a los procesos del host) o FORWARD (dirigido a un pod u otro nodo de la red). Desde el proceso local, el paquete pasa por la cadena de SALIDA y luego por la cadena POSTROUTING antes de ser enviado por el cable.

Tenga en cuenta que el pod también es una entidad externa (conectada al veth) en términos de procesamiento de iptables. Resumamos:

El tráfico reenviado (nat, enrutado o hacia/desde un pod) pasa a través de las cadenas PREROUTING - FORWARD - POSTROUTING.
El tráfico hacia el proceso del host local pasa a través de la cadena PREROUTING - INPUT.
El tráfico del proceso del host local pasa por la cadena SALIDA - POSTROUTING.

Calico ofrece opciones de políticas que le permiten aplicar políticas en todas las cadenas. Con eso en mente, veamos las diferentes opciones de configuración de políticas disponibles en Calico. Los números en la lista de opciones a continuación corresponden a los números en el diagrama anterior.

Política de punto final (pod) de carga de trabajo
Política de punto final del host
Opción Aplicar en avance
Política previa al ADNT
Política sin seguimiento

Comencemos viendo cómo se aplican las políticas a los puntos finales de la carga de trabajo (pods de Kubernetes o máquinas virtuales OpenStack) y luego veamos las opciones de políticas para los puntos finales del host.

Puntos finales de carga de trabajo

Política de terminales de carga de trabajo (1)

Esta es una opción para proteger sus pods de Kubernetes. Calico admite trabajar con Kubernetes NetworkPolicy, pero también proporciona políticas adicionales: Calico NetworkPolicy y GlobalNetworkPolicy. Calico crea una cadena para cada módulo (carga de trabajo) y conecta las cadenas de ENTRADA y SALIDA para la carga de trabajo a la tabla de filtros de la cadena ADELANTE.

Puntos finales del host

Política de punto final del host (2)

Además de CNI (interfaz de red de contenedores), las políticas de Calico brindan la capacidad de proteger el propio host. En Calico, puede crear un punto final de host especificando una combinación de la interfaz del host y, si es necesario, los números de puerto. La aplicación de políticas para esta entidad se logra mediante una tabla de filtros en las cadenas de ENTRADA y SALIDA. Como puede ver en el diagrama, (2) se aplican a procesos locales en el nodo/host. Es decir, si crea una política que se aplica al punto final del host, no afectará el tráfico que va hacia/desde sus pods. Pero sí proporciona una interfaz/sintaxis única para bloquear el tráfico para su host y pods utilizando políticas de Calico. Esto simplifica enormemente el proceso de gestión de políticas para una red heterogénea. La configuración de políticas de terminales de host para mejorar la seguridad del clúster es otro caso de uso importante.

Política ApplyOnForward (3)

La opción ApplyOnForward está disponible en la política de red global de Calico para permitir que las políticas se apliquen a todo el tráfico que pasa a través del punto final del host, incluido el tráfico que será reenviado por el host. Esto incluye el tráfico reenviado al módulo local o a cualquier otro lugar de la red. Calico requiere que esta configuración esté habilitada para políticas que usan PreDNAT y sin seguimiento; consulte las siguientes secciones. Además, ApplyOnForward se puede utilizar para monitorear el tráfico del host en los casos en que se utiliza un enrutador virtual o software NAT.

Tenga en cuenta que si necesita aplicar la misma política de red tanto a los procesos de host como a los pods, no necesita utilizar la opción ApplyOnForward. Todo lo que necesita hacer es crear una etiqueta para el punto final de host y el punto final de carga de trabajo (pod) requeridos. Calico es lo suficientemente inteligente como para aplicar políticas basadas en etiquetas, independientemente del tipo de punto final (punto final de host o carga de trabajo).

Política PreDNAT (4)

En Kubernetes, los puertos de la entidad de servicio se pueden exponer externamente usando la opción NodePorts u, opcionalmente (cuando se usa Calico), anunciándolos usando las opciones IP del clúster o IP externas. Kube-proxy equilibra el tráfico entrante vinculado a un servicio con los pods del servicio correspondiente mediante DNAT. Teniendo esto en cuenta, ¿cómo se aplican las políticas para el tráfico que llega a través de NodePorts? Para garantizar que estas políticas se apliquen antes de que DNAT procese el tráfico (que es una asignación entre el host: puerto y el servicio correspondiente), Calico proporciona un parámetro para globalNetworkPolicy llamado "preDNAT: true".

Cuando se habilita pre-DNAT, estas políticas se implementan en (4) en el diagrama (en la tabla de mangle de la cadena PREROUTING) inmediatamente antes de DNAT. Aquí no se sigue el orden habitual de las políticas, ya que la aplicación de estas políticas ocurre mucho antes en la ruta de procesamiento del tráfico. Sin embargo, las políticas preDNAT respetan el orden de aplicación entre sí.

Al crear políticas con pre-DNAT, es importante tener cuidado con el tráfico que desea procesar y permitir que la mayoría sea rechazada. El tráfico marcado como "permitir" en la política anterior a DNAT ya no será verificado por la política del punto final del host, mientras que el tráfico que no cumpla con la política anterior a DNAT continuará a través de las cadenas restantes.
Calico ha hecho obligatorio habilitar la opción applyOnForward cuando se usa preDNAT, ya que, por definición, el destino del tráfico aún no ha sido seleccionado. El tráfico se puede dirigir al proceso del host o se puede reenviar a un pod u otro nodo.

Política sin seguimiento (5)

Las redes y aplicaciones pueden tener grandes diferencias de comportamiento. En algunos casos extremos, las aplicaciones pueden generar muchas conexiones de corta duración. Esto puede hacer que conntrack (un componente central de la pila de redes de Linux) se quede sin memoria. Tradicionalmente, para ejecutar este tipo de aplicaciones en Linux, habría que configurar o deshabilitar manualmente conntrack, o escribir reglas de iptables para omitir conntrack. La política sin seguimiento en Calico es una opción más simple y eficiente si desea procesar las conexiones lo más rápido posible. Por ejemplo, si usas masivo memcache o como medida adicional de protección contra DDOS.

Lee esto del blog (o nuestra traducción) para obtener más información, incluidas pruebas de rendimiento utilizando una política sin seguimiento.

Cuando configura la opción "doNotTrack: true" en Calico globalNetworkPolicy, se convierte en una política **sin seguimiento** y se aplica muy temprano en el proceso de procesamiento de paquetes de Linux. Si observa el diagrama anterior, las políticas sin seguimiento se aplican en las cadenas PREROUTING y OUTPUT en la tabla sin formato antes de que se inicie el seguimiento de la conexión (conntrack). Cuando la política sin seguimiento permite un paquete, se marca para deshabilitar el seguimiento de la conexión para ese paquete. Significa:

La política sin seguimiento se aplica por paquete. No existe el concepto de conexión (o flujo). La falta de conexiones tiene varias consecuencias importantes:
Si desea permitir tanto el tráfico de solicitud como el de respuesta, necesita una regla tanto para el tráfico entrante como para el saliente (ya que Calico normalmente usa conntrack para marcar el tráfico de respuesta como permitido).
La política sin seguimiento no funciona para cargas de trabajo de Kubernetes (pods), porque en este caso no hay forma de rastrear la conexión saliente desde el pod.
NAT no funciona correctamente con paquetes sin seguimiento (ya que el kernel almacena el mapeo NAT en conntrack).
Al pasar por la regla "permitir todo" en la política sin seguimiento, todos los paquetes se marcarán como sin seguimiento. Esto casi siempre no es lo que desea, por lo que es importante ser muy selectivo con los paquetes permitidos por las políticas sin seguimiento (y permitir que la mayor parte del tráfico pase por las políticas con seguimiento normales).
Las políticas sin seguimiento se aplican al comienzo del proceso de procesamiento de paquetes. Es muy importante comprender esto al crear políticas de Calico. Puede tener una política de pod con orden:1 y una política sin seguimiento con orden:1000. No importará. La política sin seguimiento se aplicará antes que la política del pod. Las políticas sin seguimiento respetan el orden de ejecución sólo entre sí.

Debido a que uno de los propósitos de la política doNotTrack es aplicar la política muy temprano en el proceso de procesamiento de paquetes de Linux, Calico hace obligatorio especificar la opción applyOnForward cuando se usa doNotTrack. Con referencia al diagrama de procesamiento de paquetes, tenga en cuenta que la política sin seguimiento (5) se aplica antes de cualquier decisión de enrutamiento. El tráfico se puede dirigir al proceso del host o se puede reenviar a un pod u otro nodo.

resultados

Analizamos las diversas opciones de políticas (punto final de host, ApplyOnForward, preDNAT y Untracked) en Calico y cómo se aplican a lo largo de la ruta de procesamiento de paquetes. Comprender cómo funcionan ayuda a desarrollar políticas efectivas y seguras. Con Calico puede utilizar una política de red global que se aplica a una etiqueta (un grupo de nodos y pods) y aplicar políticas con varios parámetros. Esto permite a los profesionales de seguridad y diseño de redes proteger cómodamente “todo” (tipos de puntos finales) a la vez utilizando un lenguaje de políticas único con las políticas de Calico.

Agradecimiento: quisiera agradecer Sean Crampton и Alexa Pollita por su revisión e información valiosa.

Fuente: habr.com

Comprender las opciones de políticas de red con Calico