No, you can continue to use Docker as usual.
The great majority of container workloads run fine with ECI, but a few do not (yet). For the few workloads that don't yet work with Enhanced Container Isolation, Docker is continuing to improve the feature to reduce this to a minimum.
Yes, you can use the
--privileged flag in containers but unlike privileged
containers without Enhanced Container Isolation, the container can only use it's elevated privileges to
access resources assigned to the container. It can't access global kernel
resources in the Docker Desktop Linux VM. This allows you to run privileged
containers securely (including Docker-in-Docker). For more information, see
Key features and benefits.
No. Privileged container workloads that wish to access global kernel resources inside the Docker Desktop Linux VM won't work. For example, you can't use a privileged container to load a kernel module.
Privileged containers are typically used to run advanced workloads in containers, for example Docker-in-Docker or Kubernetes-in-Docker, to perform kernel operations such as loading modules, or to access hardware devices.
Enhanced Container Isolation allows the running of advanced workloads, but denies the ability to perform kernel operations or access hardware devices.
Yes, it restricts bind mounts of directories located in the Docker Desktop Linux VM into the container.
It doesn't restrict bind mounts of your host machine files into the container, as configured via Docker Desktop's Settings > Resources > File Sharing.
It protects all containers launched by users via
docker create and
docker run. It does not yet protect Docker Desktop Kubernetes pods, ExtensioncContainers, and Dev Environments.
No. Containers created prior to switching on ECI are not protected. Therefore, we recommend removing all containers prior to switching on ECI.
Enhanced Container Isolation has very little impact on the performance of
containers. The exception is for containers that perform lots of
umount system calls, as these are trapped and vetted by the Sysbox container
runtime to ensure they are not being used to breach the container's filesystem.
No. With Enhanced Container Isolation enabled, Sysbox is set as the default (and only) runtime for
containers deployed by Docker Desktop users. If a user attempts to override the
docker run --runtime=runc), this request is ignored and the
container is created through the Sysbox runtime.
runc is disallowed with Enhanced Container Isolation because it
allows users to run as "true root" on the Docker Desktop Linux VM, thereby
providing them with implicit control of the VM and the ability to modify the
administrative configurations for Docker Desktop, for example.
See How does it work.
See How does it work