Se presenta el lanzamiento del proyecto Cilium 1.4, en el que, con la participación de Google, Facebook, Netflix y Red Hat, se está desarrollando un sistema para garantizar la interacción de la red y aplicar políticas de seguridad para contenedores y procesos aislados.
Para distinguir entre el acceso a la red en Cilium, se utilizan eBPF (Berkeley Packet Filter) y XDP (eXpress Data Path). El código para los componentes de nivel de usuario se escribe en Go y se distribuye bajo la licencia Apache 2.0.
Los scripts BPF cargados en el kernel de Linux están disponibles bajo la licencia GPLv2.
Sobre Cilium
La base de Cilium es un proceso en segundo plano que funciona en el espacio del usuario y realiza el trabajo de generar y compilar programas BPF, así como interactuar con el tiempo de ejecución que proporciona los contenedores.
En la forma de programas BPF, se implementan sistemas para asegurar la conectividad de los contenedores, la integración con el subsistema de red (redes físicas y virtuales, VXLAN, Geneve) y el equilibrio de carga.
El proceso en segundo plano se complementa con una interfaz de administración, un repositorio de reglas de acceso, un sistema de monitoreo y módulos de integración con soporte para Kubernetes, Mesos, Istio y Docker.
El rendimiento de una solución basada en Cilium con una gran cantidad de servicios y conexiones está dos veces por delante de las soluciones basadas en iptables debido a la gran sobrecarga de búsqueda de las reglas.
Principales innovaciones
Cilium cuenta con la capacidad de enrutar y reenviar el tráfico de servicio entre varios clústeres Kubernetes.
También se propone el concepto de servicios globales (una variante de los servicios de servicio completo de Kubernetes con backends en varios clústeres).
También cuenta con herramientas para establecer las reglas para procesar solicitudes y respuestas de DNS junto con grupos de contenedores (pods), lo que le permite aumentar el control sobre el uso de recursos externos de los contenedores.
Además, hay soporte para registrar todas las solicitudes y respuestas de DNS junto con los pods. Además de las reglas de acceso en el nivel de la dirección IP, ahora puede determinar qué consultas de DNS y respuestas de DNS son válidas y cuáles deberían estar bloqueadas.
Por ejemplo, puede bloquear el acceso a dominios específicos o permitir solicitudes solo para el dominio local, sin la necesidad de realizar un seguimiento de los cambios en el enlace de los dominios a la IP.
Esto incluye la posibilidad de utilizar la dirección IP devuelta en el proceso de una solicitud de DNS para restringir las operaciones de red posteriores (por ejemplo, solo puede permitir el acceso a las direcciones IP que se devolvieron durante la resolución de DNS.
Principales novedades de la versión 1.4 de Cilium
En la nueva versión se agregó soporte experimental para el cifrado transparente de todo el tráfico entre servicios. El cifrado se puede utilizar para el tráfico entre diferentes clústeres, así como dentro del mismo clúster.
También se ha agregado la capacidad de autenticar nodos, lo que permite que el clúster se coloque en una red no confiable.
La nueva funcionalidad permite, en caso de fallas de backends que aseguren el funcionamiento del servicio en un clúster, redirigir automáticamente el tráfico a los procesadores de este servicio en otro clúster.
Se agregó soporte experimental para las interfaces de red IPVLAN, permitiendo un mayor rendimiento y menores retrasos en la interacción entre dos contenedores locales;
Se agregó un módulo para la integración con Flannel, un sistema para automatizar la configuración de la interacción de red entre nodos en un clúster Kubernetes, que le permite trabajar en paralelo o ejecutar Cilium sobre Flannel (interacción de red de Flannel, políticas de acceso y balanceo de Cilium).
Se ha proporcionado asistencia experimental para definir reglas de acceso basadas en metadatos de AWS (Amazon Web Services), como etiquetas EC2, grupos de seguridad y nombres de VPC.
También se ha propuesto la oportunidad de lanzar Cilium en GKE (Google Kubernetes Engine en Google Cloud) utilizando COS (sistema operativo optimizado para contenedores);
Con lo cual se proporciona una oportunidad de prueba para usar Sockmap BPF para acelerar la comunicación entre procesos locales (por ejemplo, útil para acelerar la interacción entre el proxy de sidecar y los procesos locales).