# Limitaciones del Aislamiento de Contenedores Mejorado El Aislamiento de Contenedores Mejorado (ECI) tiene algunas limitaciones específicas de la plataforma y restricciones de características. Comprender estas limitaciones te ayuda a planificar tu estrategia de seguridad y establecer las expectativas adecuadas. ## Consideraciones de seguridad en WSL 2 > [!NOTE] > > Docker Desktop requiere la versión 2.1.5 o posterior de WSL 2. ECI en el motor WSL 2 requiere la versión 2.6 o posterior de WSL porque ECI depende de una versión del kernel de Linux de al menos 6.3.0. Comprueba tu versión con `wsl --version` y actualízala con `wsl --update` si es necesario. El Aislamiento de Contenedores Mejorado proporciona diferentes niveles de seguridad dependiendo de tu configuración del motor de Windows. La siguiente tabla compara ECI en WSL 2 y ECI en Hyper-V: | Característica de seguridad | ECI en WSL | ECI en Hyper-V | Comentario | | -------------------------------------------------- | ------------ | ---------------- | --------------------- | | Contenedores altamente seguros | Sí | Sí | Dificulta que las cargas de trabajo de contenedores maliciosos vulneren la VM Linux de Docker Desktop y el host. | | VM Linux de Docker Desktop protegida del acceso del usuario | No | Sí | En WSL, los usuarios pueden acceder directamente a Docker Engine o eludir la configuración de seguridad de Docker Desktop. | | La VM Linux de Docker Desktop tiene un kernel dedicado | No | Sí | En WSL, Docker Desktop no puede garantizar la integridad de las configuraciones a nivel del kernel. | Las brechas de seguridad de WSL 2 incluyen: - Acceso directo a la VM: Los usuarios pueden eludir la seguridad de Docker Desktop accediendo directamente a la VM: `wsl -d docker-desktop`. Esto otorga acceso de root a los usuarios para modificar los ajustes del motor de Docker y eludir las configuraciones de la Gestión de Ajustes (Settings Management). - Vulnerabilidad de kernel compartido: Todas las distribuciones de WSL 2 comparten la misma instancia del kernel de Linux. Otras distribuciones de WSL pueden modificar configuraciones del kernel que afecten a la seguridad de Docker Desktop. ### Recomendación Utiliza el motor Hyper-V para obtener la máxima seguridad. WSL 2 ofrece un mejor rendimiento y utilización de recursos, pero proporciona un menor aislamiento de seguridad. ## No se admiten contenedores de Windows ECI solo funciona con contenedores de Linux (el modo predeterminado de Docker Desktop). El modo nativo de contenedores de Windows no es compatible. ## La protección de Docker Build varía La protección de Docker Build depende del controlador (driver) y de la versión de Docker Desktop: | Controlador de compilación | Protección | Requisitos de versión | |:------------|:-----------|:---------------------| | `docker` (predeterminado) | Protegido | Docker Desktop 4.30 y posteriores (excepto WSL 2) | | `docker` (heredado) | No protegido | Versiones de Docker Desktop anteriores a la 4.30 | | `docker-container` | Siempre protegido | Todas las versiones de Docker Desktop | Las siguientes características de Docker Build no funcionan con ECI: - `docker build --network=host` - Permisos especiales de Docker Buildx: `network.host`, `security.insecure` ### Recomendación Utiliza el controlador de compilación `docker-container` para compilaciones que requieran estas características: ```console $ docker buildx create --driver docker-container --use $ docker buildx build --network=host . ``` ## El Kubernetes de Docker Desktop no está protegido en modo Kubeadm La característica de Kubernetes integrada, cuando se utiliza con el proveedor heredado Kubeadm, no se beneficia de la protección de ECI. Los pods maliciosos o privilegiados pueden comprometer la VM de Docker Desktop y eludir los controles de seguridad. ### Recomendación Utiliza el proveedor "KinD" de Kubernetes de Docker Desktop más reciente (consulta el [Método de aprovisionamiento del clúster](/desktop/use-desktop/kubernetes/#cluster-provisioning-method)). En este modo, y con ECI activado, cada nodo de Kubernetes se ejecuta en un contenedor protegido por ECI, proporcionando un aislamiento más sólido frente a la VM de Docker Desktop. El proveedor KinD es además más rápido y permite clústeres de Kubernetes de múltiples nodos. ## Tipos de contenedores no protegidos Estos tipos de contenedores actualmente no se benefician de la protección de ECI: - Extensiones de Docker: Los contenedores de las extensiones se ejecutan sin la protección de ECI. - Pods de Kubernetes: Cuando se utiliza el Kubernetes integrado de Docker Desktop con el antiguo proveedor Kubeadm. ### Recomendación Utiliza únicamente extensiones de fuentes de confianza en entornos sensibles a la seguridad. ## Restricciones globales de comandos Las listas de comandos se aplican a todos los contenedores autorizados a montar el socket de Docker. No puedes configurar diferentes restricciones de comandos por imagen de contenedor. ## No se admiten imágenes exclusivamente locales No puedes permitir que imágenes exclusivamente locales arbitrarias (imágenes que no estén en un registro) monten el socket de Docker, a menos que: - Deriven de una imagen base permitida (con `allowDerivedImages: true`). - Utilicen la lista de permitidos con comodín (`"*"`, Docker Desktop 4.36 y posteriores). ## Comandos de Docker no compatibles Estos comandos de Docker aún no son compatibles con las restricciones de la lista de comandos: - `compose`: Comandos de Docker Compose - `dev`: Comandos de entorno de desarrollo - `extension`: Gestión de extensiones de Docker - `feedback`: Envío de comentarios de Docker - `init`: Comandos de inicialización de Docker - `manifest`: Gestión de manifiestos de imágenes - `plugin`: Gestión de complementos (plugins) - `sbom`: Lista de materiales de software (Software Bill of Materials) - `scout`: Comandos de Docker Scout - `trust`: Gestión de la confianza de las imágenes ## Consideraciones de rendimiento ### Impacto de las imágenes derivadas Habilitar `allowDerivedImages: true` añade aproximadamente 1 segundo al tiempo de inicio del contenedor para la validación de la imagen. ### Dependencias del registro - Docker Desktop obtiene periódicamente los digests de las imágenes desde los registros para su validación. - Los inicios iniciales del contenedor requieren acceso al registro para validar las imágenes permitidas. - Los problemas de conectividad de red pueden causar retrasos en el inicio del contenedor. ### Validación del digest de la imagen Cuando las imágenes permitidas se actualizan en los registros, los contenedores locales pueden bloquearse inesperadamente hasta que actualices la imagen local: ```console $ docker image rm $ docker pull ``` ## Compatibilidad de producción ### Diferencias en el comportamiento del contenedor La mayoría de los contenedores se ejecutan de manera idéntica con y sin ECI. Sin embargo, algunas cargas de trabajo avanzadas pueden comportarse de manera diferente: - Contenedores que requieren la carga de módulos del kernel. - Cargas de trabajo que modifican configuraciones globales del kernel (BPF, sysctl). - Aplicaciones que esperan un comportamiento específico de escalada de privilegios. - Herramientas que requieren acceso directo a dispositivos de hardware. Prueba las cargas de trabajo avanzadas con ECI en entornos de desarrollo antes del despliegue en producción para asegurar la compatibilidad. ### Consideraciones sobre el tiempo de ejecución (runtime) Los contenedores que utilizan el entorno de ejecución Sysbox (con ECI) pueden presentar diferencias sutiles en producción en comparación con el entorno de ejecución estándar OCI runc. Estas diferencias generalmente solo afectan a operaciones privilegiadas o a nivel de sistema.