Contenedor de aplicación Docker frente a LXC dedicado para servicios domésticos privilegiados: ¿cuál conlleva más riesgos?
Elige un contenedor Docker con el mínimo de privilegios cuando el servicio se distribuya como una imagen y solo necesite archivos, puertos, dispositivos y capacidades asignados de forma estrictamente limitada. Elige un LXC sin privilegios dedicado cuando el servicio necesite un entorno Linux más completo, integración directa con el sistema o varios procesos relacionados bajo un mismo invitado gestionado por separado. Ninguno de los dos modelos sigue siendo un límite de seguridad significativo después de exponer directorios amplios del host, el socket de Docker, dispositivos sin restricciones o privilegios de root a nivel del host.
Compara primero límites de implementación equivalentes
Docker y LXC son tecnologías de contenedores de Linux que comparten el kernel del host, pero normalmente empaquetan unidades diferentes. Docker suele aislar una sola aplicación o una pila de Compose. LXC crea un contenedor de sistema ligero con sus propios usuarios, base de datos de paquetes, servicios y sistema de archivos del sistema operativo.
Por lo tanto, la comparación justa es entre una aplicación Docker que se ejecuta directamente en un host Linux y el mismo servicio doméstico privilegiado instalado dentro de un LXC dedicado. No se trata de Docker dentro de LXC frente a LXC en sí, ni de ninguno de los dos modelos de contenedor frente a una máquina virtual con un kernel independiente.
La comparación existente de ZimaSpace sobre Docker y las instalaciones nativas dentro de LXC aborda el empaquetado y el mantenimiento. Este artículo aísla la decisión de seguridad cuando el servicio solicita privilegios que debilitan los límites habituales de los contenedores.
| Eje de seguridad | Contenedor de aplicaciones Docker | Contenedor de sistema LXC dedicado |
|---|---|---|
| Unidad principal de aislamiento | Proceso de la aplicación y sus dependencias empaquetadas | Espacio de usuario de Linux con varios servicios y usuarios |
| Kernel del host | Compartido con el host | Compartido con el host |
| Asignación de root | De forma predeterminada, se ejecuta como root, a menos que se utilicen espacios de nombres de usuario o el modo rootless | Puede ser privilegiado o asignar el usuario root del contenedor a un UID sin privilegios del host |
| Acceso a dispositivos | Se pueden asignar dispositivos individuales; el modo privilegiado expone los dispositivos de forma amplia | Los nodos de dispositivo y los permisos del host pueden asignarse al invitado |
| Archivos del host | Los montajes vinculados exponen directamente rutas seleccionadas del host a la aplicación | Los montajes vinculados exponen rutas al invitado y a todos los procesos autorizados dentro de él |
| API administrativa | El socket de Docker puede otorgar control sobre el host de Docker | No existe un socket de demonio equivalente, a menos que se instale otro entorno de ejecución dentro de LXC |
| La mejor opción | Aplicación empaquetada con privilegios estrictamente delimitados | Servicio que necesita integración con el sistema operativo dentro de un límite de invitado sin privilegios |
Comienza con el privilegio exacto que requiere el servicio
«Servicio doméstico privilegiado» puede referirse a varios permisos no relacionados: leer un dispositivo serie USB, usar un nodo de renderizado de GPU, controlar una interfaz de red, montar un sistema de archivos, enlazar un puerto bajo, acceder a Bluetooth, leer datos SMART o gestionar otros contenedores.
Concede la capacidad, el dispositivo, la ruta y el modo de red mínimos necesarios para que el servicio funcione. La explicación de Snyk sobre el modo de contenedor privilegiado destaca que el acceso privilegiado completo expone todos los dispositivos del host y otorga poderes casi equivalentes a los del host. No debería sustituir la investigación del permiso específico que falta.
Si un servicio solo necesita /dev/dri/renderD128, una ruta serie por ID o un directorio de configuración de solo lectura, tanto Docker como LXC pueden exponer ese recurso específico. La diferencia de seguridad adquiere importancia cuando la implementación requiere capacidades amplias o acceso a varias superficies del host.
El LXC sin privilegios crea un límite más sólido para la asignación de root
En un LXC sin privilegios, el UID 0 dentro del invitado se asigna a un UID subordinado ordinario en el host Proxmox. Un proceso puede parecer root dentro del contenedor y, al mismo tiempo, carecer de la identidad de root del host fuera de su espacio de nombres de usuario. Esto reduce las consecuencias de muchos errores de permisos de archivos y de algunas fugas del contenedor.
El proyecto Linux Containers describe la asignación del root de LXC sin privilegios como el principal límite de seguridad del diseño, mientras que AppArmor, seccomp y las capacidades añaden restricciones adicionales sobre los procesos y los recursos del host.
La ventaja depende de mantener el contenedor sin privilegios. Un LXC privilegiado no utiliza la misma reasignación de UID, por lo que root dentro del invitado corresponde de forma mucho más directa a root en el host. Convertirlo al modo privilegiado únicamente para simplificar los montajes o los dispositivos puede eliminar el motivo por el que LXC parecía más seguro.
Docker puede reducir el riesgo de root sin mover la aplicación a LXC
Los contenedores de Docker no tienen que ejecutarse con un demonio rootful sin restricciones ni con un usuario de aplicación root. Una imagen de contenedor puede especificar un usuario que no sea root, el tiempo de ejecución puede eliminar capacidades, los sistemas de archivos pueden ser de solo lectura y los espacios de nombres de usuario pueden reasignar las identidades del contenedor.
El modo rootless de Docker ejecuta tanto el daemon como los contenedores sin privilegios de root en el host. Esto puede reducir los riesgos del daemon y del tiempo de ejecución cuando la aplicación y las funciones de almacenamiento o red necesarias son compatibles con las limitaciones del modo rootless.
Docker sigue siendo el límite más adecuado cuando la aplicación ya está bien empaquetada y solo necesita un privilegio definido y limitado. Trasladarla a una LXC completa añade otro sistema operativo que mantener actualizado sin reducir automáticamente el recurso asignado disponible para la aplicación comprometida.
El socket de Docker puede borrar el límite de la aplicación
Algunos paneles, actualizadores automáticos, herramientas de copia de seguridad y servicios de supervisión solicitan acceso a /var/run/docker.sock. El socket permite a un cliente indicar al daemon de Docker del host que cree contenedores, monte rutas del host, exponga dispositivos y cambie redes. Por tanto, un servicio comprometido podría controlar indirectamente el host sin aprovechar una vía de escape del kernel.
El análisis de Netdata explica por qué el acceso al socket de Docker se comporta como una administración del host: el proceso solicita al daemon privilegiado que realice en su nombre acciones potentes sobre el host, sin escapar convencionalmente del contenedor.
Este es el primer límite que conviene establecer. Si el servicio requiere acceso sin restricciones al socket de Docker, comparar el aislamiento normal de Docker con el aislamiento normal de LXC resulta engañoso. Trate el servicio como un administrador del host, restrinja su API mediante un proxy diseñado específicamente para ello si es posible, aíslelo de las redes que no sean de confianza y proteja sus credenciales en consecuencia.
El mapeo de dispositivos favorece el modelo con menos capas de permisos
Una GPU, un coordinador USB, un sintonizador, un acelerador Coral, un SAI o un adaptador serie pueden pasarse a cualquiera de las dos implementaciones. En Docker directo, el host expone el dispositivo al contenedor de la aplicación. En LXC, Proxmox expone el dispositivo al contenedor del sistema, que luego ejecuta el servicio de forma nativa o puede volver a pasarlo a Docker anidado.
La LXC dedicada puede ser más ordenada cuando varios procesos relacionados necesitan el mismo dispositivo y los usuarios o grupos de Linux deben gestionar el acceso. Docker puede ser más sencillo cuando una imagen necesita un solo dispositivo y el mapeo se describe directamente en Compose.
Evita dar a cualquiera de los dos contenedores acceso a todos los dispositivos simplemente porque sea difícil configurar el permiso de uno. Proxmox señala que la seguridad de LXC combina espacios de nombres, AppArmor, seccomp y restricciones de dispositivos. El acceso amplio a dispositivos elimina parte de ese límite por capas, igual que el modo privilegiado de Docker.
Los montajes bind del host transfieren el riesgo en direcciones diferentes
Un montaje bind de Docker expone directamente la ruta seleccionada del host a la aplicación. Un montaje con permisos de escritura que contenga fotos, copias de seguridad, configuración o el estado de otras aplicaciones otorga a un contenedor comprometido los mismos derechos de modificación que tiene el usuario del host asignado a esa ruta.
Un montaje bind de LXC expone la ruta al invitado, donde varios servicios y usuarios administrativos pueden acceder a ella según las asignaciones de UID y GID. El límite adicional del sistema puede ayudar a organizar los permisos, pero también amplía el conjunto de procesos dentro del invitado que podrían acceder a los datos.
Usa montajes de solo lectura cuando sea posible, separa la configuración de los datos masivos y evita asignar la raíz del host, /proc, /sys, /dev, o los directorios de datos de Docker de forma amplia. Si el servicio debe reescribir datos protegidos del NAS, el aislamiento de aplicaciones no puede sustituir a las instantáneas ni a las copias de seguridad independientes.
Los privilegios de red pueden crear un radio de impacto mayor que el acceso al sistema de archivos
Los servicios domésticos, como las pasarelas VPN, los filtros DNS, las herramientas de descubrimiento de red, las integraciones con Home Assistant y los sistemas de monitorización, pueden solicitar la red del host, sockets sin procesar, captura de paquetes, modificación del firewall o acceso a varias VLAN. Estas capacidades pueden exponer el tráfico y permitir que el servicio influya en otros dispositivos.
Un contenedor Docker con la red del host pierde la separación de red por puerto, mientras que capacidades adicionales como NET_ADMIN o NET_RAW aumentar lo que puede hacer una intrusión. Un LXC con su propia interfaz virtual puede proporcionar una dirección independiente y una política de firewall propia, pero un invitado privilegiado o conectado ampliamente mediante bridge aún puede acceder a redes sensibles.
Elige el límite que te permita definir la ruta de red más restrictiva. Una VLAN independiente, una dirección dedicada, reglas de firewall explícitas y la ausencia de acceso a la administración del NAS suelen reducir más el riesgo que cambiar de tecnología de contenedores mientras el servicio permanece en todas las redes de confianza.
El LXC privilegiado y Docker privilegiado fallan de formas diferentes
Un contenedor Docker con privilegios completos recibe amplias capacidades de Linux y acceso a dispositivos a través de un demonio Docker ejecutado como root. Un LXC privilegiado establece una relación de identidad mucho más cercana entre el espacio de usuario completo del invitado y el root del host. Ninguno debe tratarse como un contenedor de aplicaciones sin privilegios común.
La guía de seguridad de Tigera advierte que el modo privilegiado de Docker elude importantes controles de aislamiento. Asimismo, los debates de la comunidad de Proxmox advierten que habilitar el anidamiento o permitir un acceso amplio al sistema de archivos del host dentro de LXC puede exponer las superficies /proc y /sys del host si se configura de forma descuidada.
Si el servicio realmente requiere poderes equivalentes a los de root en el host, una VM con un kernel dedicado puede proporcionar un límite de contención más claro. La sobrecarga adicional de memoria y almacenamiento puede estar justificada cuando el servicio está expuesto a Internet, procesa entradas no confiables, carga controladores cercanos al kernel o administra otras cargas de trabajo.
Las actualizaciones y la recuperación determinan si el aislamiento sigue siendo utilizable
Docker hace que el paquete de la aplicación pueda sustituirse. Recrea el contenedor a partir de una imagen o un digest fijado, restaura su configuración y sus datos persistentes, y vuelve a aplicar los mismos privilegios limitados. Esto es valioso cuando la política de seguridad está visible en Compose en lugar de depender de comandos de shell recordados.
Un LXC dedicado hace que el entorno operativo pueda sustituirse como un único invitado de Proxmox. Su base de datos de paquetes, archivos de servicio, usuarios y asignaciones de dispositivos pueden respaldarse conjuntamente. La recuperación es limpia cuando los montajes bind, las asignaciones de UID, los dispositivos del host y las reglas de red están documentados fuera del invitado.
La comparación de ZimaSpace sobre los límites de recuperación de una VM Docker y un LXC por aplicación proporciona la prueba operativa relacionada. Un límite de seguridad más reducido solo resulta útil cuando puede restaurarse sin recrear manualmente privilegios amplios.
Usa una prueba de reducción de privilegios antes de elegir Docker o LXC
- Enumera todos los dispositivos, rutas del host, capacidades, redes, API y funciones del kernel que solicita el servicio.
- Elimina el modo completamente privilegiado y vuelve a añadir un requisito cada vez.
- Ejecuta la aplicación como un usuario sin privilegios de root o dentro de un LXC sin privilegios, cuando sea compatible.
- Sustituye los montajes con permisos de escritura amplios por rutas específicas del conjunto de datos o de solo lectura.
- Elimina el acceso al socket de Docker o coloca un proxy restringido entre el servicio y el demonio.
- Pon a prueba las suposiciones sobre la intrusión verificando qué archivos, dispositivos y redes del host siguen siendo accesibles.
- Restaura el servicio en un host Docker o LXC limpio utilizando únicamente una configuración versionada.
No evalúes la seguridad solo por el número de capas. Evalúa los permisos efectivos disponibles después de añadir todos los dispositivos, montajes, capacidades, sockets y redes necesarios. Un contenedor sencillo con acceso limitado puede ser más seguro que un diseño anidado complejo con varias excepciones.
¿Qué frontera es adecuada para un servicio doméstico privilegiado?
Cuándo elegir un contenedor de aplicaciones Docker
Elige Docker cuando el servicio se distribuya como una imagen, necesite uno o dos dispositivos o montajes explícitos y pueda ejecutarse sin --privileged, acceso sin restricciones al socket de Docker o redes amplias del host. Fija las versiones, elimina capacidades, usa sistemas de archivos de solo lectura cuando sea posible y mantén explícitos los datos persistentes.
Cuándo elegir un LXC sin privilegios dedicado
Elige LXC cuando el servicio necesite un entorno Linux más completo, varios demonios relacionados, integración directa con systemd o permisos complejos para grupos de dispositivos. Conserva la asignación del espacio de nombres de usuario, mantén las restricciones de AppArmor y seccomp, y documenta cada montaje del host y cada asignación de dispositivos.
Cuándo elegir una máquina virtual
Usa una máquina virtual cuando la carga de trabajo necesite un control equivalente al de root en el host, cargue controladores inusuales, administre otras cargas de trabajo, acepte entradas públicas no confiables o no pueda ejecutarse sin privilegios amplios sobre el sistema de archivos y la red. Un kernel independiente crea una frontera más sólida que añadir más excepciones a un contenedor con kernel compartido.
Preguntas frecuentes
¿Es un LXC privilegiado más seguro que un contenedor Docker privilegiado?
No como regla general. Ambos han debilitado controles de aislamiento importantes, pero exponen las capacidades de forma diferente. Evalúa la asignación de UID, los dispositivos, los montajes, las capacidades, el acceso de red, AppArmor, seccomp y las API de los demonios, en lugar de confiar en la etiqueta del contenedor.
¿Ejecutar Docker dentro de un LXC sin privilegios añade otra capa de seguridad?
Puede añadir una asignación de UID entre el LXC y el host Proxmox, pero Docker anidado puede requerir funciones de anidamiento, capacidades adicionales, excepciones del sistema de archivos o asignaciones de dispositivos. Estos cambios pueden contrarrestar el beneficio. Una máquina virtual es más clara cuando se necesita una separación sólida del host.
¿Los servicios domésticos que solo están en la LAN necesitan contenedores sin privilegios?
Sí, cuando el compromiso pueda producirse a través de otro dispositivo de la LAN, una interfaz web vulnerable, contenido multimedia o documentos maliciosos, imágenes de la cadena de suministro o credenciales expuestas. Colocarlo únicamente en la LAN reduce parte de la exposición, pero no vuelve inofensivo el acceso como root al host.
Veredicto final
Usa Docker cuando una aplicación empaquetada pueda ejecutarse con privilegios estrictamente definidos y sin interfaces administrativas del host. Usa un LXC sin privilegios cuando un servicio necesite un sistema Linux más completo, conservando la asignación de root y el acceso controlado a dispositivos. Si cualquiera de los diseños requiere privilegios amplios de root en el host, sockets sin restricciones o acceso de escritura a datos críticos, deja de comparar contenedores y coloca el servicio detrás de una frontera más sólida, como una máquina virtual o un equipo independiente.
Productos recomendados
Comparaciones de productos
Más para leer
Servidor WireGuard frente a VPN de malla para dispositivos detrás de CGNAT
Usa una VPN de malla para dispositivos itinerantes sin complicaciones; usa un relay de WireGuard cuando quieras controlar el enrutamiento, las claves y el...
NAS de 10 GbE con clientes Gigabit: ¿actualizar primero el servidor o los dispositivos finales?
Actualiza la ruta del endpoint para una estación de trabajo lenta; actualiza primero el enlace ascendente del NAS cuando varios clientes gigabit lo saturen...
1GbE vs 2.5GbE para un servidor doméstico: ¿Qué cargas de trabajo marcan la diferencia?
Mantén 1GbE para servicios ligeros y transmisiones individuales; cambia a 2,5GbE cuando las transferencias recurrentes o los clientes combinados superen de forma sostenida aproximadamente...
