Enhanced Container Isolation limitations

{{< summary-bar feature_name="Hardened Docker Desktop" >}}

Enhanced Container Isolation has some platform-specific limitations and feature constraints. Understanding these limitations helps you plan your security strategy and set appropriate expectations.

WSL 2 security considerations#

[!NOTE]

Docker Desktop requires WSL 2 version 2.1.5 or later. ECI on the WSL 2 backend requires WSL version 2.6 or later because ECI depends on a Linux kernel version of at least 6.3.0. Check your version with wsl --version and update with wsl --update if needed.

Enhanced Container Isolation provides different security levels depending on your Windows backend configuration.

The following table compares ECI on WSL 2 and ECI on Hyper-V:

WSL 2 security gaps include:

• Direct VM access: Users can bypass Docker Desktop security by accessing the VM directly: wsl -d docker-desktop. This gives users root access to modify Docker Engine settings and bypass Settings Management configurations.
• Shared kernel vulnerability: All WSL 2 distributions share the same Linux kernel instance. Other WSL distributions can modify kernel settings that affect Docker Desktop's security.

Recommendation#

Use Hyper-V backend for maximum security. WSL 2 offers better performance and resource utilization, but provides reduced security isolation.

Windows containers not supported#

ECI only works with Linux containers (Docker Desktop's default mode). Native Windows containers mode isn't supported.

Docker Build protection varies#

Docker Build protection depends on the driver and Docker Desktop version:

The following Docker Build features don't work with ECI:

• docker build --network=host
• Docker Buildx entitlements: network.host, security.insecure

Recommendation#

Use docker-container build driver for builds requiring these features:

$ docker buildx create --driver docker-container --use
$ docker buildx build --network=host .

Docker Desktop Kubernetes not protected in Kubeadm mode#

The integrated Kubernetes feature, when used with the legacy Kubeadm provisioner, doesn't benefit from ECI protection. Malicious or privileged pods can compromise the Docker Desktop VM and bypass security controls.

Recommendation#

Use the Docker Desktop Kubernetes kind provisioner (see Cluster provisioning method). In this mode, and with ECI turned on, each Kubernetes node runs in an ECI-protected container, providing stronger isolation from the Docker Desktop VM. The kind provisioner is also faster and allows for multi-node Kubernetes clusters.

Unprotected container types#

These container types currently don't benefit from ECI protection:

• Docker Extensions: Extension containers run without ECI protection
• Kubernetes pods: When using Docker Desktop's integrated Kubernetes with the old Kubeadm provisioner.

Recommendation#

Only use extensions from trusted sources in security-sensitive environments.

Global command restrictions#

Command lists apply to all containers allowed to mount the Docker socket. You can't configure different command restrictions per container image.

Local-only images not supported#

You can't allow arbitrary local-only images (images not in a registry) to mount the Docker socket, unless they're:

• Derived from an allowed base image (with allowDerivedImages: true)
• Using the wildcard allowlist ("*", Docker Desktop 4.36 and later)

Unsupported Docker commands#

These Docker commands aren't yet supported in command list restrictions:

• compose: Docker Compose commands
• dev: Development environment commands
• extension: Docker Extensions management
• feedback: Docker feedback submission
• init: Docker initialization commands
• manifest: Image manifest management
• plugin: Plugin management
• sbom: Software Bill of Materials
• scout: Docker Scout commands
• trust: Image trust management

Performance considerations#

Derived images impact#

Enabling allowDerivedImages: true adds approximately 1 second to container startup time for image validation.

Registry dependencies#

• Docker Desktop periodically fetches image digests from registries for validation
• Initial container starts require registry access to validate allowed images
• Network connectivity issues may cause delays in container startup

Image digest validation#

When allowed images are updated in registries, local containers may be unexpectedly blocked until you refresh the local image:

$ docker image rm <image>
$ docker pull <image>

Production compatibility#

Container behavior differences#

Most containers run identically with and without ECI. However, some advanced workloads may behave differently:

• Containers requiring kernel module loading
• Workloads modifying global kernel settings (BPF, sysctl)
• Applications expecting specific privilege escalation behavior
• Tools requiring direct hardware device access

Test advanced workloads with ECI in development environments before production deployment to ensure compatibility.

Runtime considerations#

Containers using the Sysbox runtime (with ECI) may have subtle differences compared to standard OCI runc runtime in production. These differences typically only affect privileged or system-level operations.