|
| 1 | +--- |
| 2 | +title: FAQs and known issues |
| 3 | +description: FAQ for Enhanced Container Isolation |
| 4 | +keywords: enhanced container isolation, security, faq, sysbox |
| 5 | +toc_max: 2 |
| 6 | +--- |
| 7 | + |
| 8 | +<ul class="nav nav-tabs"> |
| 9 | + <li class="active"><a data-toggle="tab" data-target="#tab3">FAQs</a></li> |
| 10 | + <li><a data-toggle="tab" data-target="#tab4">Limitations and Known Issues</a></li> |
| 11 | +</ul> |
| 12 | +<div class="tab-content"> |
| 13 | +<div id="tab3" class="tab-pane fade in active" markdown="1"> |
| 14 | + |
| 15 | +#### Do I need to change the way I use Docker when Enhanced Container Isolation is enabled? |
| 16 | + |
| 17 | +No, you can continue to use Docker as usual. Enhanced Container Isolation will be mostly transparent to you. |
| 18 | + |
| 19 | +#### Do all container workloads work well with Enhanced Container Isolation? |
| 20 | + |
| 21 | +Most container workloads do, a few do not (yet). For the few workloads that |
| 22 | +don't yet work with Enhanced Container Isolation, Docker will continue to improve the feature to reduce |
| 23 | +this to a minimum. |
| 24 | + |
| 25 | +#### Can I run privileged containers with Enhanced Container Isolation? |
| 26 | + |
| 27 | +Yes, you can use the `--privileged` flag in containers but unlike privileged |
| 28 | +containers without Enhanced Container Isolation, the container can only use it's elevated privileges to |
| 29 | +access resources assigned to the container. It can't access global kernel |
| 30 | +resources in the Docker Desktop Linux VM. This allows you to run privileged |
| 31 | +containers securely. For more information, see [Key features and benefits](features-benefits.md#privileged-containers-are-also-secured). |
| 32 | + |
| 33 | +#### Will all privileged container workloads run with Enhanced Container Isolation? |
| 34 | + |
| 35 | +No. Privileged container workloads that wish to access global kernel resources, for example non-namespaced, inside the Docker Desktop Linux VM won't |
| 36 | +work. For example, you can't use a privileged container to load a kernel module. |
| 37 | + |
| 38 | +#### Why not just restrict usage of the `--privileged` flag? |
| 39 | + |
| 40 | +Privileged containers are typically used to run advanced workloads in |
| 41 | +containers, for example Docker-in-Docker or Kubernetes-in-Docker, to |
| 42 | +perform kernel operations such as loading modules, or to access hardware |
| 43 | +devices. |
| 44 | + |
| 45 | +Enhanced Container Isolation allows running advanced workloads, but denies the ability to perform |
| 46 | +kernel operations or access hardware devices. |
| 47 | + |
| 48 | +#### Does Enhanced Container Isolation restrict bind mounts inside the container? |
| 49 | + |
| 50 | +Yes, it restricts bind mounts of directories located in the Docker Desktop Linux |
| 51 | +VM into the container. |
| 52 | + |
| 53 | +It does not restrict bind mounts of your host machine files into the container, |
| 54 | +as configured via Docker Desktop's **Settings** > **Resources** > **File Sharing**. |
| 55 | + |
| 56 | +#### Does Enhanced Container Isolation protect all containers launched with Docker Desktop? |
| 57 | + |
| 58 | +It protects all containers launched by users via `docker create` and `docker run`. It does not yet protect Docker Desktop Kubernetes pods, Extension |
| 59 | +Containers, and Dev Environments. |
| 60 | + |
| 61 | +#### Does Enhanced Container Isolation affect performance of containers? |
| 62 | + |
| 63 | +Enhanced Container Isolation has very little impact on the performance of containers. The exception is |
| 64 | +for containers that perform lots of `mount` and `umount` system calls, as these |
| 65 | +are trapped and vetted by the Sysbox container runtime. |
| 66 | + |
| 67 | +#### With Enhanced Container Isolation, can the user still override the `--runtime` flag from the CLI ? |
| 68 | + |
| 69 | +No. With Enhanced Container Isolation enabled, Sysbox is locked as the default (and only) runtime for |
| 70 | +containers deployed by Docker Desktop users. If a user attempts to override the |
| 71 | +runtime (e.g., `docker run --runtime=runc`), this request is ignored and the |
| 72 | +container is created through the Sysbox runtime. |
| 73 | + |
| 74 | +The reason `runc` is disallowed with Enhanced Container Isolation because it |
| 75 | +allows users to run as "true root" on the Docker Desktop Linux VM, thereby |
| 76 | +providing them with implicit control of the VM and the ability to modify the |
| 77 | +administrative configurations for Docker Desktop, for example. |
| 78 | + |
| 79 | +#### How is ECI different from Docker Engine's userns-remap mode? |
| 80 | + |
| 81 | +See [How does it work](how-eci-works.md#enhanced-container-isolation-vs-docker-userns-remap-mode). |
| 82 | + |
| 83 | +#### How is ECI different from Rootless Docker? |
| 84 | + |
| 85 | +See [How does it work](how-eci-works.md#enhanced-container-isolation-vs-rootless-docker) |
| 86 | + |
| 87 | +<hr> |
| 88 | +</div> |
| 89 | +<div id="tab4" class="tab-pane fade" markdown="1"> |
| 90 | + |
| 91 | +#### Incompatibility with Windows Subsystem for Linux (WSL) |
| 92 | +Enhanced Container Isolation (ECI) does not currently work when Docker Desktop runs on |
| 93 | +Windows with WSL/WSL2. This is due to some limitations of the WSL/WSL2 Linux |
| 94 | +Kernel. As a result, to use Enhanced Container Isolation on Windows, you must |
| 95 | +configure Docker Desktop to use Hyper-V. This can be enforced using Admin |
| 96 | +Controls. For more information, see [Settings Management](../settings-management/index.md). |
| 97 | + |
| 98 | +#### Docker build and buildx has some restrictions |
| 99 | +With ECI enabled, Docker build `--network=host` and Docker buildx entitlements |
| 100 | +(`network.host`, `security.insecure`) are not allowed. Builds that require |
| 101 | +these will not work properly. |
| 102 | + |
| 103 | +#### Kubernetes pods are not yet protected |
| 104 | +Kubernetes pods are not yet protected by ECI. A malicious or privileged pod can |
| 105 | +compromise the Docker Desktop Linux VM and bypass security controls. We expect |
| 106 | +to improve on this in future versions of Docker Desktop. |
| 107 | + |
| 108 | +#### Extension Containers are not yet protected |
| 109 | +Extension containers are also not yet protected by ECI. Ensure you extension |
| 110 | +containers come from trusted entities to avoid issues. We expect to improve on |
| 111 | +this in future versions of Docker Desktop. |
| 112 | + |
| 113 | +#### Docker Desktop dev environments are not yet protected |
| 114 | +Containers launched by the Docker Desktop Dev Environments feature are not yet |
| 115 | +protected either. We expect to improve on this in future versions of Docker |
| 116 | +Desktop. |
| 117 | + |
| 118 | +#### Use in production |
| 119 | +In general users should not experience differences between running a container |
| 120 | +in Docker Desktop with ECI enabled, which uses the Sysbox runtime, and running |
| 121 | +that same container in production, through the standard OCI `runc` runtime. |
| 122 | + |
| 123 | +However in some cases, typically when running advanced or privileged workloads in |
| 124 | +containers, users may experience some differences. In particular, the container |
| 125 | +may run with ECI but not with `runc`, or vice-versa. |
| 126 | + |
| 127 | +<hr> |
| 128 | +</div> |
| 129 | +</div> |
0 commit comments