gVisor Ejecución de Docker aislado

En Google Cloud Español hablamos de seguridad y aislamiento de los Contenedores de Software Engineer han revolucionado la forma en que desarrollamos, empaquetamos y desplegamos aplicaciones. Sin embargo, la zona de código del sistema expuesta a los contenedores es lo suficientemente amplia como para que muchos expertos en seguridad no los recomienden para ejecutar aplicaciones no confiables o potencialmente maliciosas.

El creciente deseo de ejecutar cargas de trabajo más heterogéneas y menos confiables ha creado un nuevo interés en los contenedores usando  espacios aislado: contenedores que ayudan a proporcionar un límite de aislamiento seguro entre el sistema operativo host y la aplicación que se ejecuta dentro del contenedor.

Con ese fin, nos gustaría presentar gVisor, un nuevo tipo de entorno limitado que ayuda a proporcionar un aislamiento seguro para los contenedores, a la vez que es más liviano que una máquina virtual (VM). gVisor se integra con Docker y Kubernetes, por lo que es simple y fácil ejecutar contenedores de espacio aislado en entornos de producción.

Los contenedores tradicionales de Linux no son cajas cerradas

Las aplicaciones que se ejecutan en contenedores Linux tradicionales acceden a los recursos del sistema de la misma forma que lo hacen las aplicaciones regulares (no en contenedor): realizando llamadas al sistema directamente al núcleo del host. El kernel se ejecuta en un modo privilegiado que le permite interactuar con el hardware necesario y devolver los resultados a la aplicación.

Con los contenedores tradicionales, el kernel impone algunos límites a los recursos a los que puede acceder la aplicación. Estos límites se implementan mediante el uso de cgroups y espacios de nombres de Linux, pero no todos los recursos se pueden controlar a través de estos mecanismos.

Además, incluso con estos límites, el núcleo aún expone una gran área de superficie que las aplicaciones maliciosas pueden atacar directamente. Las características Kernel como los filtros seccomp pueden proporcionar un mejor aislamiento entre la aplicación y el núcleo del host, pero requieren que el usuario cree una lista blanca predefinida de llamadas al sistema.

En la práctica, a menudo es difícil saber qué llamadas al sistema requerirá una aplicación de antemano. Los filtros también brindan poca ayuda cuando se descubre una vulnerabilidad en una llamada al sistema que requiere su aplicación.

Tecnología de contenedor basada en VM existente

Un enfoque para mejorar el aislamiento de contenedores es ejecutar cada contenedor en su propia máquina virtual (VM). Esto le da a cada contenedor su propia "máquina", incluidos kernel y dispositivos virtualizados, completamente separados del host. Incluso si hay una vulnerabilidad en el invitado, el hipervisor todavía aísla el host, así como otras aplicaciones / contenedores que se ejecutan en el host.

La ejecución de contenedores en distintas máquinas virtuales proporciona un gran aislamiento, compatibilidad y rendimiento, pero también puede requerir una mayor huella de recursos. Los contenedores Kata son un proyecto de código abierto que utiliza VM desmanteladas para mantener el espacio de recursos mínimo y maximizar el rendimiento para el aislamiento de contenedores. Al igual que gVisor, Kata contiene un tiempo de ejecución de Open Container Initiative (OCI) que es compatible con Docker y Kubernetes.

Contenedores de espacio aislado con gVisor

gVisor es más liviano que una VM mientras mantiene un nivel similar de aislamiento. El núcleo de gVisor es un núcleo que se ejecuta como un proceso normal y sin privilegios que admite la mayoría de las llamadas al sistema Linux. Este núcleo está escrito en Go, que fue elegido por su seguridad de tipo memoria y tipo. Al igual que en una máquina virtual, una aplicación que se ejecuta en una caja y  gVisor obtiene su propio kernel y un conjunto de dispositivos virtualizados, distintos del host y de otras cajas.

gVisor proporciona un fuerte límite de aislamiento al interceptar las llamadas al sistema de aplicaciones y actuar como el núcleo invitado, todo mientras se ejecuta en el espacio de usuario. A diferencia de una VM que requiere un conjunto fijo de recursos en la creación, gVisor puede acomodar los recursos cambiantes a lo largo del tiempo, como lo hacen la mayoría de los procesos normales de Linux. gVisor se puede considerar como un sistema operativo extremadamente paravirtualizado con una huella de recursos flexible y un costo fijo menor que una VM completa. Sin embargo, esta flexibilidad tiene el precio de una mayor sobrecarga de llamadas por sistema y compatibilidad de aplicaciones, sobre esto más sobre eso a continuación.

    "Las cargas de trabajo seguras son una prioridad para la industria. Nos alienta ver enfoques innovadores como gVisor y esperamos colaborar en la aclaración de especificaciones y en la mejora de los componentes técnicos conjuntos para brindar seguridad adicional al ecosistema". - Samuel Ortiz, miembro del Comité Directivo Técnico de Kata e Ingeniero Principal en Intel Corporation

    "Se alienta a Hyper a ver el nuevo enfoque de gVisor para el aislamiento de contenedores. La industria requiere un ecosistema robusto de tecnologías de contenedores seguros, y esperamos colaborar en gVisor para ayudar a traer contenedores seguros a la corriente principal ". - Xu Wang, miembro del Comité Directivo Técnico de Kata y CTO en Hyper.sh

Integrado con Docker y Kubernetes

El tiempo de ejecución de gVisor se integra sin problemas con Docker y Kubernetes a través de runsc (abreviatura de "ejecutar contenedor de espacio aislado"), que se ajusta a la API de tiempo de ejecución de OCI. El tiempo de ejecución de runsc es intercambiable con runc, el tiempo de ejecución de contenedor predeterminado de Docker. La instalación es simple; una vez instalado, solo se necesita una bandera adicional para ejecutar un contenedor de espacio aislado en Docker:

$ docker run --runtime=runsc hello-world
$ docker run --runtime=runsc -p 3306:3306 mysql

En Kubernetes, la mayor parte del aislamiento de los recursos se produce en el nivel del pod, lo que hace que el pod sea un ajuste natural para un límite de la zona de pruebas gVisor. La comunidad de Kubernetes está formalizando actualmente la API de la sandbox pod, pero el soporte experimental está disponible hoy.

El tiempo de ejecución de runsc puede ejecutar pods de espacio aislado en un clúster de Kubernetes mediante el uso de los proyectos cri-o cri-containerd, que convierten los mensajes de Kubelet en comandos de tiempo de ejecución OCI. gVisor implementa una gran parte de la API del sistema Linux (200 llamadas al sistema y conteo), pero no todas. Algunas llamadas al sistema y argumentos no son actualmente compatibles, como lo son algunas partes de los sistemas de archivos / proc y / sys. Como resultado, no todas las aplicaciones se ejecutarán dentro de gVisor, pero muchas funcionarán perfectamente, incluidas Node.js, Java 8, MySQL, Jenkins, Apache, Redis, MongoDB y muchas más.

Empezando

Como desarrolladores, queremos lo mejor de ambos mundos: la facilidad de uso y la portabilidad de los contenedores, y el aislamiento de los recursos de las máquinas virtuales. Creemos que gVisor es un gran paso en esa dirección. Consulte nuestro informe en GitHub para saber cómo comenzar con gVisor y obtener más información sobre los detalles técnicos. ¡Y asegúrese de unirse a nuestro grupo de Google para participar en la discusión!