Linux LXC vs FreeBSD jail

¿Existen diferencias notables entre LXC (contenedores de Linux) y cárceles de FreeBSD en términos de seguridad, estabilidad & rendimiento?

¿En primer lugar mira, ambos enfoques se ven muy similares.

Comentarios

  • LXC es una tecnología bastante nueva, por lo que esperaría una mejor seguridad y estabilidad con las cárceles. incluso una suposición sobre el rendimiento. Hay algunos problemas de seguridad conocidos con LXC que se pueden mitigar usando selinux, por ejemplo. A mí personalmente me gusta LXC, sin embargo.
  • @ PavelŠimerda Acabo de oír hablar de LXC hoy, pero estaba sorprendido de descubrir que tanto Heroku como probablemente Google App Engine ya usan LXC.
  • Si ' acaba de toparse con LXC, debería echar un vistazo a Docker, que usa LXC debajo del capó: docker.io/the_whole_story
  • Docker no ot usa más lxc.
  • @nwildner ya no ' t usa liblxc, pero usa exactamente los mismos conceptos: espacios de nombres del kernel.

Respuesta

No importa el nombre elegante que se use aquí, ambos son soluciones a un problema específico: una mejor solución de segregación que el Unix clásico chroot . La virtualización a nivel del sistema operativo, los contenedores, las zonas o incluso el «chroot con esteroides» son nombres o títulos comerciales que definen el mismo concepto de separación del espacio de usuario, pero con diferentes características.

Chroot se introdujo el 18 de marzo de 1982 , meses antes del lanzamiento de 4.2 BSD , como herramienta para probar su sistema de instalación y compilación, pero hoy todavía tiene sus fallas. Dado que el primer objetivo de chroot era solo proporcionar una ruta newroot , se descubrieron otros aspectos del sistema que debían aislarse o controlarse (red, vista de proceso, rendimiento de E / S). Aquí es donde aparecieron los primeros contenedores (virtualización a nivel de usuario).

Ambas tecnologías (FreeBSD Jails y LXC) hacen uso del aislamiento del espacio de usuario para proporcionar otra capa de seguridad. Esta compartimentación asegurará que un proceso determinado se comunicará solo con otros procesos en el mismo contenedor en el mismo host, y si se usa cualquier recurso de red para lograr la comunicación del «mundo exterior», todo será reenviado a la interfaz / canal asignado que este contenedor tiene.

Funciones

Cárceles de FreeBSD:

  • Considerada tecnología estable, ya que es una característica dentro de FreeBSD desde 4.0;
  • Toma lo mejor del sistema de archivos ZFS en el punto en el que podría clonar jails y crear plantillas de jail para implementar fácilmente más jail. Más locura de ZFS ;
  • Bien documentado y evolucionando ;
  • Las cárceles jerárquicas te permiten crear cárceles dentro de una cárcel (¡necesitamos profundizar más!). Combine con allow.mount.zfs para lograr más poder, y otras variables como children.max definen el número máximo de cárceles para niños.
  • rctl (8) manejará los límites de recursos de las cárceles (memoria, CPU, disco, …);
  • Las cárceles de FreeBSD manejan Linux espacio de usuario ;
  • Aislamiento de red con vnet, lo que permite que cada cárcel tenga su propia pila de red, interfaces, tablas de direccionamiento y enrutamiento;
  • nullfs para ayudar a vincular carpetas a las que están ubicadas en el servidor real dentro de una cárcel;
  • ezjail utilidad para ayudar a implementaciones masivas y administración de cárceles;
  • Muchos parámetros optimizables del kernel (sysctl ). security.jail.allow.* Los parámetros limitarán las acciones del usuario root de esa cárcel.
  • Quizás, las cárceles de FreeBSD extenderán algunas de las características del proyecto VPS como migración en vivo en un futuro cercano.
  • Se ha realizado un esfuerzo de integración de ZFS y Docker corriendo. Aún experimental.
  • FreeBSD 12 admite bhyve dentro de una cárcel y pf dentro de una cárcel, creando un mayor aislamiento para esas herramientas
  • Durante los últimos años se han desarrollado muchas herramientas interesantes. Algunos de ellos están indexados en esta publicación de blog .
  • Alternativas: Proyecto VPS FreeBSD

Contenedores Linux (LXC):

  • Nueva tecnología «en el kernel» pero respaldada por las grandes (especialmente Canonical);
  • Contenedores sin privilegios a partir de LXC 1.0, da un gran paso hacia la seguridad dentro de los contenedores;
  • Mapeo de UID y GID dentro de los contenedores;
  • Espacios de nombres del kernel, para hacer la separación de IPC, montaje, pid, red y usuarios. Estos espacios de nombres se pueden manejar de manera separada, donde un proceso que usa un diferente espacio de nombres de red no necesariamente se aislará en otros aspectos como el almacenamiento;
  • Grupos de control (cgroups) para administrar recursos y agruparlos. CGManager es el tipo para lograr eso.
  • Perfiles de Apparmor / SELinux y capacidades de Kernel para hacer cumplir mejor las características de Kernel accesibles por contenedores. Seccomp también está disponible en contenedores lxc para filtrar llamadas al sistema. Otros aspectos de seguridad aquí .
  • Se está desarrollando la funcionalidad de migración en vivo. Es muy difícil decir cuándo estará listo para su uso en producción, ya que docker / lxc tendrá que lidiar con la pausa del proceso del espacio de usuario, la captura de pantalla, la migración y la consolidación – ref1 , ref2 . La migración en vivo funciona con contenedores básicos (no hay transferencia de dispositivo ni servicios de red complejos ni configuraciones especiales de almacenamiento).
  • Enlaces de API para permitir el desarrollo en python3 y 2, lua, Go, Ruby y Haskell
  • Área centralizada de «Novedades». Bastante útil siempre que necesite comprobar si se corrigió algún error o se comprometió una nueva función. Aquí .
  • Una alternativa interesante podría ser lxd , que bajo el capó funciona con lxc pero tiene algunas características interesantes como una API REST, integración OpenStack, etc.
  • Otro interesante Lo que pasa es que Ubuntu parece estar enviando zfs como el sistema de archivos predeterminado para contenedores en 16.04 . Para mantener los proyectos alineados, lxd lanzó su versión 2.0 y algunas de las características están relacionadas con zfs .
  • Alternativas : OpenVZ , Docker
  • Docker . Tenga en cuenta aquí que Docker usa espacios de nombres, grupos que crean aislamiento «por aplicación» / «por software» . Diferencias clave aquí . Mientras que LXC crea contenedores con múltiples procesos, Docker reduce un contenedor tanto como sea posible a un solo proceso y luego lo administra a través de Docker.
  • Esfuerzo para integrar Docker con SELinux y reducir las capacidades dentro de un contenedor para hacerlo más seguro – Docker y SELinux, Dan Walsh
  • ¿Cuál es la diferencia entre Docker, LXD y LXC

Docker ya no usa lxc. Ahora tienen un lib específico llamado runc que maneja directamente la integración con el espacio de nombres del Kernel de bajo nivel y las funciones de cgroups.

Ninguna tecnología es una panacea de seguridad, pero ambas son formas bastante buenas de aislar un entorno que no requiere virtualización completa debido a la infraestructura de sistemas operativos mixtos. La seguridad vendrá después de mucha lectura de documentación e implementación de parámetros optimizables del kernel, MAC y aislamientos que le ofrecen esas virtudes a nivel de SO.

Vea también:

Comentarios

  • Vale la pena mencionar que, desde el primer momento, lxc no hace ningún esfuerzo por proporcionar un aislamiento adecuado a los huéspedes. lxd , sin embargo, intenta proporcionar aislamiento como las cárceles BSD o las zonas de Solaris.
  • lxd es una " mejor experiencia " de LXC, agregando otras características. Sin embargo, parece agradable citar a este pequeño individuo aquí
  • @allquixotic, ¿te refieres a si usas una configuración sin cambios creada a partir de plantillas? Es cierto, pero los contenedores sin privilegios (habilitados para usuarios) estaban disponibles con LXC 1.xy incluso podían iniciarse automáticamente al arrancar el sistema, siempre que fueran propiedad de root (y, por lo tanto, se ubicaran en la ubicación de todo el sistema para contenedores).

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *