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

El complemento de red Calico ofrece un amplio conjunto 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 de un namespace o ser políticas de red globales que se aplican a host endpoint (para proteger aplicaciones que se ejecutan directamente en el host, que puede ser un servidor o máquina virtual) o a workload endpoint (para proteger aplicaciones que se ejecutan en contenedores o máquinas virtuales alojadas en el host). Las políticas de Calico permiten aplicar medidas de seguridad a diferentes puntos de ruta de paquetes utilizando opciones como preDNAT, unraracked y applyOnForward. Comprender cómo funcionan estas opciones puede ayudar a mejorar la seguridad y el rendimiento del sistema en general. Este artículo explica la esencia de estas opciones de políticas de Calico (preDNAT, unraracked y applyOnForward) aplicadas a los host endpoints, con énfasis en lo que ocurre en las rutas de procesamiento de paquetes (cadenas de iptables).

Este artículo asume que tiene una comprensión básica de los principios de las políticas de red de Kubernetes y Calico. Si no es así, le recomendamos que pruebe el tutorial de políticas de red básicas y tutorial de protección de host utilizando Calico antes de leer este artículo. También asumimos que tiene un entendimiento básico del funcionamiento iptables en Linux.

Calico global network policy le permite aplicar un conjunto de reglas de acceso por etiquetas (a grupos de hosts y workloads/pods). Esto es muy útil si usa junto diferentes sistemas: máquinas virtuales, sistemas directamente en hardware o infraestructura de Kubernetes. Además, puede proteger su clúster (nodos) mediante un conjunto de políticas declarativas y aplicar políticas de red al tráfico entrante (por ejemplo, a través de servicios NodePorts o IPs externas).

A nivel fundamental, cuando Calico conecta un pod a la red (ver diagrama a continuación), lo conecta al host mediante una interfaz virtual Ethernet (veth). El tráfico enviado por el pod llega al host desde esta interfaz virtual y se maneja como si proviniera de una interfaz de red física. Por defecto, Calico llama a estas interfaces caliXXX. Dado que el tráfico llega a través de una interfaz virtual, pasa por iptables, como si el pod estuviera a una distancia de un hop. Por lo tanto, cuando el tráfico llega/sale del pod, se reenvía desde la perspectiva del host.

En el nodo de Kubernetes donde se ejecuta Calico, puedes relacionar la interfaz virtual (veth) con el workload de la siguiente manera. En el ejemplo a continuación, puedes 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:  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 workload, ¿cómo aplica las políticas? Para ello, Calico crea hooks en varias cadenas de procesamiento de paquetes, utilizando iptables.

En el diagrama a continuación se muestran las cadenas involucradas en el procesamiento de paquetes en iptables (o subsistema netfilter). Cuando un paquete entra a través de la interfaz de red, primero pasa por la cadena PREROUTING. Luego se toma una decisión de enrutamiento y, dependiendo de esto, el paquete pasa ya sea por INPUT (destinado a los procesos del host) o por FORWARD (destinado a un pod o a otro nodo en la red). Desde un proceso local, el paquete pasa por la cadena OUTPUT y luego por POSTROUTING antes de enviarse por cable.

Ten en cuenta que el pod también es un objeto externo (conectado a veth) desde el punto de vista del procesamiento de iptables. Resumiendo:

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

Calico ofrece opciones para políticas que permiten aplicar políticas a todas las cadenas. Teniendo esto en cuenta, analicemos 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.

1. Política de endpoint de carga de trabajo (pod)
2. Política de endpoint de host
3. Opción ApplyOnForward
4. Política PreDNAT
5. Política Untracked

Comencemos revisando cómo se aplican las políticas a los endpoints de carga de trabajo (pods de Kubernetes o VMs de OpenStack), y luego revisaremos las opciones de políticas para los endpoints de host.

Endpoints de Carga de Trabajo

Política de Endpoint de Carga de Trabajo (1)

Esta opción está diseñada para proteger sus pods de Kubernetes. Calico admite el uso de Kubernetes NetworkPolicy, pero también proporciona políticas adicionales: Calico NetworkPolicy y GlobalNetworkPolicy. Calico crea una cadena para cada pod (carga de trabajo) y ganchos en las cadenas INPUT y OUTPUT para la carga de trabajo a la tabla de filtros de la cadena FORWARD.

Endpoints de Host

Política de Endpoint de Host (2)

Además de CNI (interfaz de red de contenedor), las políticas de Calico ofrecen la capacidad de proteger directamente el host. En Calico, puede crear un endpoint de host estableciendo 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 la tabla de filtros en las cadenas INPUT y OUTPUT. Como se muestra en el diagrama, (2) se aplican a los procesos locales en el nodo/host. Es decir, si ha creado una política que se aplica al endpoint de host, no afectará el tráfico que va hacia/desde sus pods. Sin embargo, proporciona una interfaz/sintaxis única para bloquear el tráfico para su host y pods mediante políticas de Calico. Esto simplifica significativamente el proceso de gestión de políticas para una red heterogénea. La configuración de políticas de endpoint de host para fortalecer la seguridad del clúster es otro importante caso de uso.

Política ApplyOnForward (3)

La opción ApplyOnForward está disponible en la política de red global de Calico para permitir la aplicación de políticas a todo el tráfico que pase a través del endpoint de host, incluido el tráfico que será reenviado por el host. Este tráfico incluye el que se envía a un pod local o a cualquier otro lugar en la red. Calico requiere que esta opción esté habilitada para las políticas que utilizan PreDNAT y untracked, consulte las secciones siguientes. Además, ApplyOnForward se puede utilizar para rastrear el tráfico del host en casos de uso de enrutador virtual o NAT programático.

Tenga en cuenta que si necesita aplicar la misma política de red tanto para los procesos de host como para los pods, no es necesario usar la opción ApplyOnForward. Simplemente debe crear una etiqueta para los endpoint de host y los endpoint de carga de trabajo (pod) necesarios. Calico es lo suficientemente inteligente como para aplicar la política en función de las etiquetas, sin importar el tipo de endpoint (hostendpoint o workload).

Política PreDNAT (4)

En Kubernetes, los puertos de la entidad service pueden ser expuestos al exterior mediante la opción NodePorts o, opcionalmente (al usar Calico), mediante su declaración a través de las opciones Cluster IPs o External IPs. Kube-proxy equilibra el tráfico entrante asociado al service a los pods del service correspondiente, utilizando DNAT. Teniendo esto en cuenta, ¿cómo aplica políticas para el tráfico que ingresa a través de NodePorts? Para que estas políticas se apliquen antes de que el tráfico sea procesado por DNAT (que representa la coincidencia entre host:puerto y el service correspondiente), Calico proporciona un parámetro para globalNetworkPolicy llamado "preDNAT: true".

Cuando el pre-DNAT está habilitado, estas políticas se implementan en (4) en el diagrama — en la tabla mangle de la cadena PREROUTING — justo antes de DNAT. El orden normal de las políticas (order) no se sigue aquí, ya que la aplicación de estas políticas sucede mucho antes en la ruta de procesamiento del tráfico. Sin embargo, las políticas preDNAT respetan el orden de aplicación (order) entre ellas.

Al crear políticas con pre-DNAT, es importante prestar atención al tráfico que desea procesar y permitir que la mayoría sea rechazada. El tráfico marcado como 'allow' en la política pre-DNAT ya no será verificado por la política de hostendpoint, mientras que el tráfico que no pase la política pre-DNAT continuará su camino a través de las demás cadenas.
Calico ha hecho obligatorio habilitar la opción applyOnForward al usar preDNAT, ya que por definición el destino del tráfico aún no se ha seleccionado. El tráfico puede ser dirigido a un proceso de host, o puede ser redirigido a un pod o a otro nodo.

Política Untracked (5)

Las redes y las aplicaciones pueden tener grandes diferencias en su comportamiento. En algunos casos extremos, las aplicaciones pueden generar numerosas conexiones temporales. Esto puede llevar a la falta de memoria en conntrack (el componente principal de la pila de red de Linux). Tradicionalmente, para ejecutar aplicaciones de este tipo en Linux, es necesario configurar manualmente o desactivar conntrack, o escribir reglas de iptables para eludir conntrack. La política Untracked en Calico es una opción más simple y eficiente si deseas manejar conexiones lo más rápido posible. Por ejemplo, si utilizas un gran memcache o como una medida adicional de protección contra DDOS.

Lee esta entrada de blog (o nuestra traducción) para obtener más información, incluidas pruebas de rendimiento al usar la política untracked.

Cuando estableces la opción «doNotTrack: true» en la política global de Calico, se convierte en una política **no rastreada** y se aplica en la primera etapa del procesamiento de paquetes de Linux. Si observas el diagrama anterior, las políticas no rastreadas se aplican en las cadenas PREROUTING y OUTPUT en la tabla raw, antes de que se inicie el seguimiento de conexiones (conntrack). Cuando un paquete se permite mediante la política no rastreada, se marca para desactivar el seguimiento de conexiones para ese paquete. Esto significa que:

• La política no rastreada se aplica a cada paquete. No existe el concepto de conexión (o flujo). La ausencia de conexiones (connection) conlleva varias consecuencias importantes:
• Si deseas permitir tanto el tráfico de solicitud como el de respuesta, necesitas una regla tanto para el tráfico entrante como para el saliente (ya que Calico generalmente utiliza conntrack para marcar el tráfico de respuesta como permitido).
• La política no rastreada no funciona para cargas de trabajo de Kubernetes (pods), porque en este caso no hay forma de rastrear la conexión saliente desde un pod.
• NAT no funciona correctamente con paquetes no rastreados (ya que el núcleo almacena el mapeo NAT en conntrack).
• Al pasar por la regla de «permitir todo» en la política no rastreada, todos los paquetes serán marcados como no rastreados. Esto casi siempre no es lo que necesitas, por lo que es importante ser muy selectivo con los paquetes permitidos por políticas no rastreadas (y permitir que la mayor parte del tráfico pase a través de políticas rastreadas normales).
• Las políticas no rastreadas se aplican al inicio de la cadena de procesamiento de paquetes. Es muy importante entender esto al crear políticas de Calico. Puede tener una política para el pod con order:1 y una política no rastreada con order:1000. Esto no importará. La política no rastreada se aplicará antes de la política para el pod. Las políticas no rastreadas mantienen el orden de ejecución solo entre sí.

Dado que uno de los objetivos de la política doNotTrack es forzar la aplicación de la política en la etapa más temprana de la cadena de procesamiento de paquetes de Linux, Calico requiere que se especifique la opción applyOnForward al usar doNotTrack. Al mirar el diagrama de procesamiento de paquetes, observe que la política no rastreada (5) se aplica antes de cualquier decisión de enrutamiento. El tráfico puede ser dirigido a un proceso host, o puede ser redirigido a un pod o a otro nodo.

Resultados

Hemos revisado varias opciones de políticas (Host endpoint, ApplyOnForward, preDNAT, y Untracked) en Calico y cómo se aplican en el camino de procesamiento de paquetes. Comprender la esencia de su funcionamiento ayuda en el desarrollo de políticas eficaces y seguras. Con Calico, puede utilizar una política de red global que se aplica a una etiqueta (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 convenientemente "todo" (tipos de endpoints) utilizando un lenguaje único de políticas con políticas de Calico.

Agradecimientos: Quiero agradecer Shawn Crampton y Alex Pollitt por su revisión y por la valiosa información.

Fuente: habr.com