Get best of the week

Comprender las políticas de red con Calico



Calico Network Plugin proporciona una amplia gama de políticas de red con una sintaxis unificada para proteger hosts en hardware, máquinas virtuales y pods. Estas políticas pueden aplicarse dentro del espacio de nombres o ser políticas de red globales aplicables al punto final del host (para proteger las aplicaciones que se ejecutan directamente en el host: el servidor o la máquina virtual pueden ser el host directamente) o al punto final de la carga de trabajo(para proteger las aplicaciones que se ejecutan en contenedores o máquinas virtuales alojadas). Las políticas de Calico le permiten aplicar medidas de seguridad a varios puntos en la ruta del paquete utilizando parámetros como preDNAT, sin seguimiento y applyOnForward. Comprender cómo funcionan estas opciones puede ayudar a mejorar la seguridad y el rendimiento del sistema en su conjunto. Este artículo explica la esencia de estas configuraciones de política de Calico (preDNAT, sin rastrear y applyOnForward) aplicadas a los puntos finales del host, con énfasis en lo que sucede en las rutas de procesamiento de paquetes (cadenas iptabels).

Este artículo asume que usted comprende cómo funcionan las políticas de red de Kubernetes y Calico. De lo contrario, le recomendamos que pruebe el tutorial básico de políticas de red y el tutorial de protección del host con Calico antes de leer este artículo. También esperamos que tenga una comprensión básica de iptables en Linux. Política de red global de

Calicole permite aplicar un conjunto de reglas de acceso a etiquetas (para alojar grupos y cargas de trabajo / pods). Esto es muy útil si utiliza sistemas heterogéneos juntos: máquinas virtuales, un sistema directamente en el hardware o la 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 una red (vea el diagrama a continuación), lo conecta a un host usando una interfaz virtual Ethernet (veth). El tráfico enviado por pod llega al host desde esta interfaz virtual y se procesa como si viniera de una interfaz de red física. Por defecto, Calico llama a estas interfaces caliXXX. Como el tráfico llega a través de la interfaz virtual, pasa a través de iptables, como si el pod estuviera a la distancia de un salto. Por lo tanto, cuando el tráfico viene / viene del pod, se reenvía desde el punto de vista del host.

En el nodo Kubernetes donde se ejecuta Calico, puede asignar la interfaz virtual (veth) a la 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 de monitoreo de calico.

[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 veth para cada carga de trabajo, ¿cómo aplica las políticas? Para hacer esto, Calico crea enlaces en varias cadenas de la ruta de procesamiento del paquete 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 base a esto, el paquete pasa a través de INPUT (dirigido a los procesos del host) o FORWARD (dirigido al pod u otro nodo en la red). Desde el proceso local, el paquete pasa por la cadena de SALIDA y luego POSTROUTING antes de enviarlo por el cable.

Tenga en cuenta que pod también es un objeto externo (conectado a veth) en términos de manejo de iptables. Para resumir:

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



Calico ofrece opciones de políticas para aplicar políticas a todas las cadenas. Con eso en mente, echemos un vistazo a las diversas configuraciones 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 de arriba.

  1. Política de punto final de carga de trabajo (pod)
  2. Política de punto final del host
  3. Opción ApplyOnForward
  4. Política de PreDNAT
  5. Política sin seguimiento

Comencemos por ver cómo se aplican las políticas a los puntos finales de carga de trabajo (pods Kubernetes o OpenStack VM), y luego veamos las opciones de política para los puntos finales de host.

Puntos finales de carga de trabajo


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


Esta es una opción para proteger sus vainas 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 pod (carga de trabajo) y se engancha a las cadenas INPUT y OUTPUT para la carga de trabajo a la tabla de filtros de la cadena FORWARD.

Puntos finales de host


Política de punto final del host (2)


Además de CNI (interfaz de red de contenedor), las políticas de Calico brindan la capacidad de proteger directamente al host. En Calico, puede crear un punto final de host especificando una combinación de la interfaz de host y, si es necesario, los números de puerto. La aplicación de políticas para esta entidad se logra utilizando la tabla de filtro en las cadenas INPUT y OUTPUT. Como se puede ver en el diagrama, (2) se aplican a procesos locales en el nodo / host. Es decir, si creó una política que se aplica al punto final del host, no afectará el tráfico que va hacia / desde sus pods. Pero proporciona una única interfaz / sintaxis para bloquear el tráfico de su host y pods utilizando las 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 punto final de host para mejorar la protección 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 por el punto final del host, incluido el tráfico que el host reenviará. Este tráfico incluye ser enviado a un pod local o en cualquier otro lugar de la red. Calico requiere que esta configuración esté habilitada para las políticas que usan PreDNAT y sin seguimiento, consulte las siguientes secciones. Además, ApplyOnForward se puede utilizar para rastrear el tráfico del host cuando se utiliza un enrutador virtual o software NAT.

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

Política de PreDNAT (4)


En Kubernetes, los puertos de la entidad de servicio se pueden reenviar hacia afuera utilizando la opción NodePorts o, opcionalmente (cuando se usa Calico), declarándolos a través de las opciones Cluster IP o IP externas. Kube-proxy equilibra el tráfico entrante vinculado al servicio a los pods del servicio correspondiente utilizando DNAT. Dado esto, ¿cómo aplica políticas al tráfico que ingresa a través de NodePorts? Para 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: verdadero".

Cuando pre-DNAT está habilitado, estas políticas se implementan en (4) en el diagrama, en la tabla de cambios de la cadena PREROUTING, inmediatamente antes de DNAT. Aquí no se respeta la política de pedidos habitual, ya que la aplicación de estas políticas se produce mucho antes en la ruta de procesamiento del tráfico. Sin embargo, las políticas preDNAT respetan el orden de aplicación entre ellas.

Al crear políticas con anterioridad a DNAT, es importante tener en cuenta 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 al DNAT ya no será verificado por la política del punto de hospedaje, mientras que el tráfico cuando la política anterior al DNAT falle continuará fluyendo por el resto de las cadenas.
Calico hizo obligatorio habilitar la opción applyOnForward cuando se usa preDNAT, porque por definición el destino del tráfico aún no se ha seleccionado. El tráfico se puede dirigir al proceso del host, o se puede redirigir 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 a corto plazo. Esto puede conducir a una falta de memoria para conntrack (el componente principal de la pila de red de Linux). Tradicionalmente, para ejecutar este tipo de aplicación en Linux, debe 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 más eficiente si desea procesar las conexiones lo más rápido posible. Por ejemplo, si usa memcache masivo o como una medida adicional de protección contra DDOS .

Lea esta publicación de blog (o nuestra traducción) para obtener más información, incluidas las pruebas de rendimiento con la 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 en la etapa inicial de la canalización 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 iniciar el seguimiento de conexión (conntrack). Cuando un paquete está permitido por una política no rastreada, se marca para deshabilitar el seguimiento de conexión para este paquete. Significa:

  • Se aplica una política sin seguimiento para cada paquete. No existe el concepto de una conexión (o secuencia). La falta de conexiones conlleva varias consecuencias importantes:
  • , , , ( Calico conntrack, ).
  • untracked workload Kubernetes (pod’), pod’.
  • NAT ( ​​ NAT conntrack).
  • « » untracked- . , , untracked- ( ).
  • Las políticas sin seguimiento se aplican al comienzo de la canalización de procesamiento de paquetes. Es muy importante entender esto al crear políticas de Calico. Puede tener una política para un 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 para el pod. Las políticas sin seguimiento respetan el orden de ejecución solo entre ellas.

Debido a que uno de los objetivos de la política doNotTrack es hacer cumplir la política en la etapa inicial del proceso de procesamiento de paquetes de Linux, Calico hace obligatorio especificar la opción applyOnForward cuando se usa doNotTrack. En 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 redirigir a un pod u otro nodo.

Resumen


Analizamos las diversas opciones de política (punto final de host, ApplyOnForward, preDNAT y Untracked) en Calico y cómo se aplican al procesamiento de paquetes. Comprender la esencia de su trabajo ayuda a desarrollar políticas efectivas y seguras. Con Calico, puede usar la política de red global, que se aplica a la etiqueta (un grupo de nodos y pods) y aplicar políticas con varios parámetros. Esto permite a los especialistas en seguridad y diseño de redes proteger de forma conveniente "todo" (tipos de puntos finales) utilizando el mismo lenguaje de políticas con las políticas de Calico.


Reconocimiento: Me gustaría agradecer a Sean Crampton y Alex Pollitt por su revisión y por su valiosa información.

More articles:


All Articles