# Aislamiento de Contenedores Mejorado





El Aislamiento de Contenedores Mejorado (Enhanced Container Isolation - ECI) evita que los contenedores maliciosos comprometan Docker Desktop o el sistema host. Aplica de forma automática técnicas avanzadas de seguridad manteniendo la total productividad del desarrollador y la compatibilidad con los flujos de trabajo.

- ECI fortalece el aislamiento de los contenedores y bloquea las configuraciones de seguridad creadas por los administradores, como las [políticas de Gestión de Acceso a Registros](/enterprise/security/hardened-desktop/registry-access-management/) y los controles de [Gestión de Ajustes](/enterprise/security/settings-management/).
- ECI funciona junto con otras características de seguridad de Docker, como la reducción de capacidades de Linux, seccomp y AppArmor.

Si estás utilizando el motor WSL2, asegúrate de ejecutar la versión 2.6 o posterior de WSL. Esto es necesario porque ECI depende de una versión del kernel de Linux de al menos 6.3.0, y WSL 2.6+ incluye la versión 6.6 del kernel.

## ¿Quién debería usar el Aislamiento de Contenedores Mejorado?

ECI está diseñado para:

- Organizaciones que desean prevenir ataques basados en contenedores y reducir las vulnerabilidades de seguridad en los entornos de desarrollo.
- Equipos de seguridad que necesitan un aislamiento de contenedores más fuerte sin afectar los flujos de trabajo de los desarrolladores.
- Empresas que requieren protección adicional al ejecutar imágenes de contenedores de terceros o no confiables.

## Cómo funciona el Aislamiento de Contenedores Mejorado

Docker implementa ECI utilizando el [entorno de ejecución de contenedores Sysbox](https://github.com/nestybox/sysbox), una bifurcación (fork) con seguridad mejorada del entorno de ejecución estándar OCI runc. Cuando ECI está activado, los contenedores creados a través de `docker run` o `docker create` utilizan automáticamente Sysbox en lugar de runc sin requerir ningún cambio en los flujos de trabajo de los desarrolladores. El entorno de ejecución predeterminado de Docker sigue siendo runc, pero todos los contenedores de usuario se inician implícitamente con Sysbox.

Cuando ECI está activado, se ignora la bandera `--runtime` de la CLI de Docker. Incluso los contenedores que utilizan la bandera `--privileged` se ejecutan de forma segura con ECI, evitando que vulneren la máquina virtual de Docker Desktop u otros contenedores.

## Características clave de seguridad

### Aislamiento de espacios de nombres de usuario de Linux

Con el Aislamiento de Contenedores Mejorado, todos los contenedores aprovechan los espacios de nombres de usuario de Linux (user namespaces) para lograr un aislamiento más fuerte. Los usuarios root del contenedor se asignan a usuarios sin privilegios en la VM de Docker Desktop:

```console
$ docker run -it --rm --name=first alpine
/ # cat /proc/self/uid_map
         0     100000      65536
```

Esta salida muestra que el usuario root del contenedor (0) se asigna al usuario sin privilegios 100000 en la VM, con un rango de 64K IDs de usuario. Cada contenedor obtiene asignaciones exclusivas:

```console
$ docker run -it --rm --name=second alpine
/ # cat /proc/self/uid_map
         0     165536      65536
```

Sin el Aislamiento de Contenedores Mejorado, los contenedores se ejecutan como root real:

```console
$ docker run -it --rm alpine
/ # cat /proc/self/uid_map
         0       0     4294967295
```

Al utilizar espacios de nombres de usuario de Linux, ECI garantiza que los procesos del contenedor nunca se ejecuten con IDs de usuario válidos en la VM Linux, limitando sus capacidades únicamente a los recursos dentro del contenedor.

### Contenedores privilegiados seguros

Los contenedores privilegiados (`docker run --privileged`) normalmente representan riesgos de seguridad significativos porque proporcionan acceso sin restricciones al kernel de Linux. Sin ECI, los contenedores privilegiados pueden:

- Ejecutarse como root real con todas las capacidades.
- Omitir las restricciones de seccomp y AppArmor.
- Acceder a todos los dispositivos de hardware.
- Modificar los ajustes globales del kernel.

Las organizaciones que protegen los entornos de desarrollo se enfrentan a desafíos con los contenedores privilegiados porque estos pueden obtener el control de la VM de Docker Desktop y alterar los ajustes de seguridad, como la gestión de acceso a registros y los proxies de red.

El Aislamiento de Contenedores Mejorado transforma los contenedores privilegiados garantizando que solo puedan acceder a los recursos dentro del límite de su contenedor. Por ejemplo, los contenedores privilegiados no pueden acceder a la configuración de red de Docker Desktop:

```console
$ docker run --privileged djs55/bpftool map show
Error: can't get next map: Operation not permitted
```

Sin ECI, los contenedores privilegiados pueden acceder a estos ajustes directamente y modificarlos:

```console
$ docker run --privileged djs55/bpftool map show
17: ringbuf  name blocked_packets  flags 0x0
        key 0B  value 0B  max_entries 16777216  memlock 0B
18: hash  name allowed_map  flags 0x0
        key 4B  value 4B  max_entries 10000  memlock 81920B
```

Las cargas de trabajo de contenedores avanzadas, como Docker-in-Docker y Kubernetes-in-Docker, continúan funcionando con ECI, pero se ejecutan de manera mucho más segura.

> [!NOTE]
>
> ECI no impide que los usuarios ejecuten contenedores privilegiados, sino que los hace seguros al limitar su acceso. Las cargas de trabajo privilegiadas que modifican los ajustes globales del kernel (cargar módulos del kernel, cambiar los ajustes de Berkeley Packet Filter) reciben errores de "permiso denegado".

### Imposición del aislamiento de espacios de nombres

El Aislamiento de Contenedores Mejorado evita que los contenedores compartan espacios de nombres de Linux con la VM de Docker Desktop, manteniendo los límites de aislamiento:

**Uso compartido del espacio de nombres PID bloqueado:**

```console
$ docker run -it --rm --pid=host alpine
docker: Error response from daemon: failed to create shim task: OCI runtime create failed: error in the container spec: invalid or unsupported container spec: sysbox containers can't share namespaces [pid] with the host (because they use the linux user-namespace for isolation): unknown.
```

**Uso compartido del espacio de nombres de red bloqueado:**

```console
$ docker run -it --rm --network=host alpine
docker: Error response from daemon: failed to create shim task: OCI runtime create failed: error in the container spec: invalid or unsupported container spec: sysbox containers can't share a network namespace with the host (because they use the linux user-namespace for isolation): unknown.
```

**Anulación de espacio de nombres de usuario ignorada:**

```console
$ docker run -it --rm --userns=host alpine
/ # cat /proc/self/uid_map
         0     100000      65536
```

Las operaciones de construcción de Docker que utilizan `--network-host` y los permisos especiales de buildx (`network.host`, `security.insecure`) también están bloqueados.

### Montajes de tipo bind protegidos

El Aislamiento de Contenedores Mejorado mantiene la compatibilidad con el uso compartido de archivos estándar, mientras evita el acceso a directorios sensibles de la VM:

Los montajes de directorios del host continúan funcionando:

```console
$ docker run -it --rm -v $HOME:/mnt alpine
/ # ls /mnt
# Muestra correctamente el contenido del directorio personal (home)
```

Los montajes de configuración de la VM están bloqueados:

```console
$ docker run -it --rm -v /etc/docker/daemon.json:/mnt/daemon.json alpine
docker: Error response from daemon: failed to create shim task: OCI runtime create failed: error in the container spec: can't mount /etc/docker/daemon.json because it's configured as a restricted host mount: unknown
```

Esto evita que los contenedores lean o modifiquen las configuraciones del motor de Docker, los ajustes de gestión de acceso a registros, las configuraciones de proxy y otros archivos de la VM relacionados con la seguridad.

> [!NOTE]
>
> Por defecto, ECI bloquea el montaje tipo bind del socket del motor de Docker (/var/run/docker.sock), ya que esto otorgaría a los contenedores el control sobre el motor de Docker. Los administradores pueden crear excepciones para imágenes de contenedores de confianza.

### Protección avanzada de llamadas al sistema

El Aislamiento de Contenedores Mejorado intercepta las llamadas al sistema sensibles para evitar que los contenedores utilicen capacidades legítimas de forma maliciosa:

```console
$ docker run -it --rm --cap-add SYS_ADMIN -v $HOME:/mnt:ro alpine
/ # mount -o remount,rw /mnt /mnt
mount: permission denied (are you root?)
```

Incluso con la capacidad `CAP_SYS_ADMIN`, los contenedores no pueden cambiar los montajes tipo bind de solo lectura a lectura y escritura, garantizando que no puedan vulnerar los límites del contenedor.

Los contenedores aún pueden crear montajes internos dentro de su sistema de archivos:

```console
/ # mkdir /root/tmpfs
/ # mount -t tmpfs tmpfs /root/tmpfs
/ # mount -o remount,ro /root/tmpfs /root/tmpfs
/ # findmnt | grep tmpfs
├─/root/tmpfs    tmpfs      tmpfs    ro,relatime,uid=100000,gid=100000
```

ECI realiza el filtrado de llamadas al sistema de manera eficiente al interceptar solo las llamadas al sistema de la ruta de control (de uso poco frecuente), mientras deja intactas las llamadas de la ruta de datos, manteniendo el rendimiento del contenedor.

### Mapeo automático de IDs de usuario en el sistema de archivos

El Aislamiento de Contenedores Mejorado resuelve los desafíos de compartir archivos entre contenedores con diferentes rangos de IDs de usuario mediante el mapeo automático del sistema de archivos.

Cada contenedor obtiene asignaciones de ID de usuario exclusivas, pero Sysbox utiliza la reasignación de ID de usuario del sistema de archivos mediante montajes asignados a ID del kernel de Linux (añadidos en 2021) o el módulo alternativo shiftfs. Esto mapea los accesos al sistema de archivos desde los IDs de usuario reales del contenedor a los rangos estándar, permitiendo:

- Compartir volúmenes entre contenedores con diferentes rangos de IDs de usuario.
- Propiedad de archivos consistente independientemente de las asignaciones de ID de usuario del contenedor.
- Acceso transparente a archivos sin intervención del usuario.

### Ocultación de información mediante emulación del sistema de archivos

ECI emula partes de los sistemas de archivos `/proc` y `/sys` dentro de los contenedores para ocultar información sensible del host y proporcionar vistas por contenedor de los recursos del kernel:

```console
$ docker run -it --rm alpine
/ # cat /proc/uptime
5.86 5.86
```

Esto muestra el tiempo de actividad del contenedor en lugar del tiempo de actividad de la VM de Docker Desktop, evitando que la información del sistema se filtre en los contenedores.

Varios recursos de `/proc/sys` que no están en espacios de nombres por el kernel de Linux se emulan por contenedor, con Sysbox coordinando los valores al programar los ajustes del kernel. Esto permite que las cargas de trabajo de los contenedores que normalmente requieren acceso privilegiado se ejecuten de forma segura.

## Rendimiento y compatibilidad

El Aislamiento de Contenedores Mejorado mantiene un rendimiento optimizado y una total compatibilidad:

- Sin impacto en el rendimiento: El filtrado de llamadas al sistema se dirige únicamente a las llamadas de la ruta de control, dejando intactas las operaciones de la ruta de datos.
- Compatibilidad total con los flujos de trabajo: Los procesos de desarrollo, herramientas e imágenes de contenedores existentes funcionan sin cambios.
- Soporte para cargas de trabajo avanzadas: Docker-in-Docker, Kubernetes-in-Docker y otros escenarios complejos funcionan de forma segura.
- Gestión automática: Las asignaciones de ID de usuario, el acceso al sistema de archivos y las políticas de seguridad se manejan automáticamente.
- Soporte para imágenes estándar: No se requieren imágenes de contenedor especiales ni modificaciones.

> [!IMPORTANT]
>
> La protección de ECI varía según la versión de Docker Desktop y aún no protege los contenedores de extensión. Las compilaciones de Docker y Kubernetes en Docker Desktop tienen niveles de protección variables según la versión. Para más detalles, consulta las [Limitaciones del Aislamiento de Contenedores Mejorado](/enterprise/security/hardened-desktop/enhanced-container-isolation/limitations/).

