Linux LXC vs FreeBSD cárcel


62

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

A primera vista, ambos enfoques se ven muy similares.


1
LXC es una tecnología bastante nueva, por lo que esperaría una mayor seguridad y estabilidad con las cárceles. Ni siquiera una suposición sobre el rendimiento. Hay algunos problemas de seguridad conocidos con LXC que pueden mitigarse usando selinux, por ejemplo. Sin embargo, personalmente me gusta LXC.
Pavel Šimerda

1
@ PavelŠimerda Acabo de enterarme de LXC hoy, pero me sorprendió descubrir que tanto Heroku como probablemente Google App Engine ya usan LXC.
Philipp Claßen

3
Si acabas de toparte con LXC, deberías echar un vistazo a Docker que usa LXC debajo del capó: docker.io/the_whole_story
Kev

1
Docker ya no usa lxc.

1
@nwildner ya no usa liblxc, pero usa exactamente los mismos conceptos: espacios de nombres de kernel.
0xC0000022L

Respuestas:


101

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

Chroot se introdujo el 18 de marzo de 1982, meses antes del lanzamiento de 4.2 BSD , como una herramienta para probar su instalación y sistema de construcción, pero hoy todavía tiene sus fallas. Dado que el primer objetivo de chroot era solo proporcionar una ruta de raíz nueva , 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 del 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 utiliza cualquier recurso de red para lograr la comunicación "fuera del mundo", todo se enviará a la interfaz / canal asignado que este contenedor tiene.

Caracteristicas

Cárceles de FreeBSD:

  • Considerada tecnología estable, ya que es una característica dentro de FreeBSD desde 4.0;
  • Se necesita lo mejor del sistema de archivos ZFS en el punto donde podría clonar cárceles y crear plantillas de cárcel para implementar fácilmente más cárceles. Un poco más de locura ZFS ;
  • Bien documentado y en evolución ;
  • Las cárceles jerárquicas le permiten crear cárceles dentro de una cárcel (¡necesitamos profundizar más!). Combine con allow.mount.zfspara lograr más potencia, y otras variables como children.maxdefinir max max children jails.
  • rctl (8) manejará los límites de recursos de las cárceles (memoria, CPU, disco, ...);
  • Las cárceles de FreeBSD manejan el espacio de usuario de Linux ;
  • Aislamiento de red con vnet, permitiendo que cada cárcel tenga su propia pila de red, interfaces, direcciones y tablas de enrutamiento;
  • nullfs para ayudar a vincular carpetas a las ubicadas en el servidor real dentro de una cárcel;
  • utilidad ezjail para ayudar a despliegues masivos y gestión de cárceles;
  • Un montón de núcleos sintonizables ( sysctl). security.jail.allow.*los parámetros limitarán las acciones del usuario raíz de esa cárcel.
  • Tal vez, las cárceles de FreeBSD extenderán algunas de las características del proyecto VPS como la migración en vivo en un futuro cercano.
  • Se está ejecutando algún esfuerzo de integración de ZFS y Docker . Aún experimental.
  • FreeBSD 12 admite bhyve dentro de una cárcel y pf dentro de una cárcel, creando un mayor aislamiento de esas herramientas
  • Se desarrollaron muchas herramientas interesantes durante los últimos años. Algunos de ellos están indexados en esta publicación de blog .
  • Alternativas: proyecto FreeBSD VPS

Contenedores Linux (LXC):

  • Nueva tecnología "en el núcleo" pero respaldada por grandes (especialmente Canonical);
  • Los contenedores sin privilegios a partir de LXC 1.0 dan un gran paso hacia la seguridad dentro de los contenedores;
  • Mapeo UID y GID dentro de contenedores;
  • Espacios de nombres del núcleo, para hacer la separación de IPC, montaje, pid, red y usuarios. Estos espacios de nombres se pueden manejar de forma separada, donde un proceso que utiliza un espacio de nombres de red diferente no se aislará necesariamente en otros aspectos como el almacenamiento;
  • Grupos de control (cgroups) para gestionar recursos y agruparlos. CGManager es el tipo para lograr eso.
  • Perfiles Apparmor / SELinux y capacidades de Kernel para hacer cumplir mejor las funciones de Kernel accesibles por contenedores. Seccomp también está disponible en contenedores lxc para filtrar las llamadas al sistema. Otros aspectos de seguridad aquí .
  • Funcionalidad de migración en vivo en desarrollo. Es realmente difícil decir cuándo estará listo para su uso en producción, ya que docker / lxc tendrá que lidiar con la pausa, la instantánea, la migración y la consolidación del proceso del espacio de usuario: ref1 , ref2 .La migración en vivo funciona con contenedores básicos (sin transferencia de dispositivos ni servicios de red complejos ni configuraciones de almacenamiento especiales).
  • Enlaces de API para permitir el desarrollo en python3 y 2, lua, Go, Ruby y Haskell
  • Área centralizada "Novedades". Bastante útil siempre que necesite verificar si se corrigió algún error o si se confirmó una nueva característica. Aquí .
  • Una alternativa interesante podría ser lxd , que debajo del capó funciona con lxc pero tiene algunas características agradables como una API REST, integración OpenStack, etc.
  • Otra cosa interesante 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
  • Estibador . Tenga en cuenta que Docker utiliza espacios de nombres, grupos de c 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 una lib específica llamada libcontainer que maneja la integración con el espacio de nombres Kernel de bajo nivel y las características de cgroups directamente.

Ninguna de las tecnologías 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 kernel tunables, MAC y aislamientos que esas virtudes de nivel de sistema operativo le ofrecen.

Ver también:


1
Vale la pena mencionar que fuera de la caja, lxc no hace ningún esfuerzo para proporcionar el aislamiento adecuado de los huéspedes. Sin embargo, lxd intenta proporcionar aislamiento como cárceles BSD o zonas de Solaris.
allquixotic

lxd es una "mejor experiencia" de LXC, que pone otras características encima. Sin embargo, parece agradable citar a este pequeño aquí

@allquixotic, ¿quieres decir si usas una configuración sin cambios creada a partir de plantillas? Es cierto, pero los contenedores no privilegiados (habilitados para usuarios) estaban disponibles con LXC 1.x e incluso podían iniciarse automáticamente en el arranque del sistema, siempre que fueran propiedad de ellos root(y por lo tanto se ubicaran en la ubicación de los contenedores en todo el sistema).
0xC0000022L
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.