Contenedores o máquinas virtuales: ¿Cuál es más seguro?
¿Las máquinas virtuales (VM) son más seguras que los contenedores? Puede pensar que conoce la respuesta, pero IBM Research ha descubierto que los contenedores pueden ser tan seguros o más seguros que las máquinas virtuales.
James Bottomley, Ingeniero Distinguido de IBM Research y desarrollador principal del Kernel Linux, escribe: "Uno de los mayores problemas con el debate actual sobre la seguridad de los Contenedores vs Hypervisor es que nadie ha desarrollado una forma de medir la seguridad, por lo que el debate es todo en términos cualitativos (los hipervisores "se sienten" más seguros que los contenedores debido a la amplitud de la interfaz) pero en realidad nadie ha hecho una comparación cuantitativa".
Para satisfacer esta necesidad, Bottomley creó el Perfil de ataque horizontal (HAP), diseñado para describir la seguridad del sistema de manera que se pueda medir objetivamente. Bottomley descubrió que "un contenedor Docker con un perfil seccomp bien diseñado (que bloquea llamadas al sistema inesperadas) proporciona una seguridad aproximadamente equivalente a un hipervisor".
Bottomley comienza definiendo Vertical Attack Profile (VAP). Este es todo el código, que se recorre para proporcionar un servicio desde la entrada hasta la actualización de la base de datos y la salida. Este código, como todos los programas, contiene errores. La densidad de errores varía, pero mientras más código atravieses, mayor es la probabilidad de exposición a un agujero de seguridad. "Los exploits de agujeros de seguridad que pueden saltar al host del servidor físico o a las máquinas virtuales, son HAP".
Los HAP son el peor tipo de agujeros de seguridad. Bottomley los llama "eventos potencialmente destructores de negocios". Entonces, ¿cómo mides un sistema para HAP? Bottomley explica:
El enfoque cuantitativo para medir el HAP dice que tomamos la densidad de errores del código Kernel de Linux y la multiplicamos por la cantidad de código único atravesado por el sistema en ejecución después de que ha alcanzado un estado estable (lo que significa que no parece ser atravesando cualquier nueva ruta del kernel).
Por el bien de este método, suponemos que la densidad de errores es uniforme y, por lo tanto, el HAP se aproxima por la cantidad de código atravesado en el estado estable.
Medir esto para un sistema en ejecución es otro asunto completamente diferente, pero, afortunadamente, el kernel tiene un mecanismo llamado ftrace que puede usarse para proporcionar un rastro de todas las funciones llamadas por un proceso de espacio de usuario dado y así proporciona una aproximación razonable del número de líneas de código atravesadas. (Tenga en cuenta que esta es una aproximación porque medimos el número total de líneas en la función sin tomar en cuenta el flujo de código interno, principalmente porque ftrace no proporciona tantos detalles).
Además, esta metodología funciona muy bien para los contenedores donde todas las El flujo de control emana de un conocido grupo de procesos a través de la información de llamada del sistema, pero funciona menos para hipervisores donde, además de la interfaz de hypercall, también debe agregar rastros de los daemons del back-end (como de los vhost del kernel kvm o dom0 en el caso de Xen).
En resumen, se mide la cantidad de líneas de código que un sistema, ya sea bare metal, VM o container, utiliza para ejecutar una aplicación determinada. Cuantos más códigos ejecuta, más probabilidades hay de tener un agujero de seguridad de nivel HAP.
Habiendo definido los HAP y cómo medirlo, Bottomley ejecutó varios puntos de referencia estándar como redis-bench-set, redis-bench-get, python-tornado y node-express con los dos últimos también ejecutando los servidores web con simple externo Clientes transaccionales. Realizó estas pruebas con Docker, el gVisor de Google, un arenero de tiempo de ejecución de los contenedores; gVisor-kvm, el mismo sandbox contenedor utilizando KVM, el hipervisor VM integrado en Linux; Kata Containers, una máquina virtual liviana de código abierto; y Nabla, el tipo de contenedor recién lanzado de IBM, que está diseñado para un fuerte aislamiento del servidor.
Bottomley descubrió que el tiempo de ejecución de Nabla tenía un mejor "HAP que el hipervisor que contenía tecnología Kata, lo que significa que hemos logrado un sistema de contenedores con mejor HAP (es decir, más seguro) que los hipervisores".
Sin embargo, no fue solo el proyecto de IBM, que resultó ser más seguro. También descubrió que "el contenedor Docker con un perfil seccomp bien diseñado (que bloquea las llamadas inesperadas del sistema) proporciona una seguridad aproximadamente equivalente a un hipervisor".
GVisor fue otra historia. En el mejor de los casos, gVisor tuvo resultados incluso que con el caso de uso de Docker, pero en un caso fue significativamente peor.
Bottomley especula que eso se debe a que "gVisor intenta mejorar la contención reescribiendo la interfaz de llamadas del sistema Linux en Go. Sin embargo, nadie ha prestado atención a la cantidad de llamadas al sistema que el tiempo de ejecución Go está usando, que es lo que realmente muestran estos resultados " Si ese es el caso, Bottomley piensa que una versión futura de gVisor podría reescribirse para que sea mucho más segura.
El verdadero punto, sin embargo, no es qué la tecnología sea más segura. Es que, para los problemas de seguridad más severos, los contenedores y las máquinas virtuales tienen aproximadamente el mismo nivel de seguridad. De hecho, piensa Bottomley, "es perfectamente posible tener contenedores que sean más seguros que los hipervisores y que descansen, finalmente, los argumentos sobre cuál es la tecnología más segura".
"El próximo paso", continuó, "es establecer el alcance total de la exposición a una aplicación maliciosa y, para ello, se debe utilizar algún tipo de prueba de fuzz".
Además, el trabajo de Bottomley es solo el comienzo. Él ha demostrado que es posible medir objetivamente la seguridad de una aplicación. Como dijo, "no espero que esta sea la última palabra en el debate, pero al describir cómo lo hicimos, espero que otros también puedan desarrollar mediciones cuantitativas".
Fuente: Blog Bottomley
