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).

El artículo Cilium 1.4, un sistema de red basado en BPF para contenedores de Linux ha sido originalmente publicado en Linux Adictos.

from Linux Adictos http://bit.ly/2X7wOKr
via IFTTT

Si estás pensando en llevar varias distribuciones en vivo (Live) en un mismo medio, es decir, crear un medio multiboot, como un disco óptico o una memoria USB, entonces sabrás que existen multitud de herramientas que te pueden ayudar a esto. Una de ellas es la conocida como YUMI, o también MultiBootUSB y MultiSystem, e incluso con el proyecto que nos aporta Sardu. Pero existen otras alternativas para crearlos, y una de ellas es de la que os hablamos hoy: MultiCD.

Para que veáis mejor su funcionamiento, os vamos a dejar un ejemplo de tutorial práctico paso a paso para crear un Live con dos distribuciones GNU/Linux que tras grabar en el medio que tengamos, podremos arrancar seleccionando una u otra desde un menú. Así de sible, como lo imaginas. Tan solo elige las imágenes ISO de las distros que quieras añadir, y esta herramienta se encargará de ponertelo fácil ocupándose del resto:

• El primer paso es descargar el script MultiCD, ya que está escrito en un lenguaje interpretado. Lo puedes hacer desde el enlace que te dejo, o con un simple comando desde tu terminal:

sudo git clone git://github.com/IsaacSchemm/MultiCD.git

• Ahora que ya lo tendremos en nuestro poder, tenemos que descargar las imágenes ISO de las distros que queramos meter en ese multiboot. Por ejemplo, imagina que quieres usar elementaryOS y openSUSE. Pues descargaremos éstas desde sus respectivos sitios web oficiales si no las tenemos ya…
• Ahora vamos a situar el script MultiCD en el mismo directorio que tengamos las imágenes ISO descargadas, por ejemplo, si lo tenemos todo en Descargas, pues perfecto. En tal caso, pasamos al siguiente paso.
• El siguiente paso será hacer uso del script que tiene todos los pasos para hacer lo necesario de forma automática para la creación de nuestro medio:

sudo multicd.sh

• El script usará las ISOs que se encuentren en el mismo directory para crear el medio y generará una única imagen llamada multicd.iso y que estará en el mismo directorio en el que estamos trabajando.
• Ahora, el último paso será quemar o grabar esa imagen ISO al medio óptico (CD o DVD) o al pendrive que queramos. Para ello, puedes usar cualquiera de los proyectos que conoces y que hemos hablado de ellos en este blog: Rufus, UNetbootin, Brasero, K3b, etc.

El artículo MultiCD: cómo crear un Live multiboot ha sido originalmente publicado en Linux Adictos.

from Linux Adictos http://bit.ly/2S4TPcS
via IFTTT