docker
/
docs
mirror of https://github.com/docker/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

ECI: document docker socket mount restrictions. (#19117) 

* eci: document docker socket mount restrictions.

Signed-off-by: Cesar Talledo <cesar.talledo@docker.com>

* eci: make formatting of notes more consistent.

Signed-off-by: Cesar Talledo <cesar.talledo@docker.com>

* eci: add new config section to docs TOC.

Signed-off-by: Cesar Talledo <cesar.talledo@docker.com>

* eci: a few more small doc improvements.

Remove the note regarding ECI being available to business customers
from all but the main ECI doc page (it's overkill otherwise).

Signed-off-by: Cesar Talledo <cesar.talledo@docker.com>

* eci: more doc improvements per review feedback.

Signed-off-by: Cesar Talledo <cesar.talledo@docker.com>

---------

Signed-off-by: Cesar Talledo <cesar.talledo@docker.com>
This commit is contained in:
Cesar Talledo 2024-01-25 08:23:39 -08:00 committed by GitHub
parent 5b7a6ba6e4
commit 7734c16df8
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
7 changed files with 346 additions and 49 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

45
content/desktop/hardened-desktop/enhanced-container-isolation/_index.md
View File

@ -5,9 +5,9 @@ keywords: containers, rootless, security, sysbox, runtime
title: What is Enhanced Container Isolation?
---
>**Note**
> Note
>
>Enhanced Container Isolation is available to Docker Business customers only.
> Enhanced Container Isolation is available to Docker Business customers only.
Enhanced Container Isolation provides an additional layer of security to prevent malicious workloads running in containers from compromising Docker Desktop or the host.
@ -23,7 +23,7 @@ When Enhanced Container Isolation is enabled, these mechanisms are applied autom
Enhanced Container Isolation ensures stronger container isolation and also locks in any security configurations that have been created by IT admins, for instance through [Registry Access Management policies](../../../security/for-admins/registry-access-management.md) or with [Settings Management](../settings-management/index.md).
>**Note**
> Note
>
> Enhanced Container Isolation is in addition to other container security techniques used by Docker. For example, reduced Linux Capabilities, Seccomp, AppArmor.
@ -48,16 +48,16 @@ In addition, the following restrictions are imposed:
- Containers can no longer share namespaces with the Docker Desktop VM (e.g., `--network=host`, `--pid=host` are disallowed).
- Containers can no longer modify configuration files inside the Docker Desktop VM (e.g., mounting any VM directory into the container is disallowed).
- Containers can no longer access the Docker engine (e.g., mounting the Docker engine's socket into the container is restricted); this prevents malicious containers from gaining control of the Docker engine.
- Containers can no longer access the Docker engine (e.g., mounting the Docker engine's socket into the container is restricted); this prevents malicious containers from gaining control of the Docker engine. Admins can relax this for [trusted container images](config.md).
- Console access to the Docker Desktop VM is forbidden for all users.
These features and restrictions ensure that containers are better secured at runtime, with minimal impact to developer experience and productivity.
For more information on how Enhanced Container Isolation work, see [How does it work](how-eci-works.md).
>**Important**
> Important
>
>Enhanced Container Isolation does not protect Kubernetes pods. For more information on known limitations and workarounds, see [FAQs](../../../faq/security/eci-faq.md).
> Enhanced Container Isolation does not protect Kubernetes pods. For more information on known limitations and workarounds, see [FAQs](../../../faq/security/eci-faq.md).
{ .important }
### What host OSes / platforms is Enhanced Container Isolation supported on?
@ -83,38 +83,47 @@ To enable Enhanced Container Isolation as a developer:
5. Next to **Use Enhanced Container Isolation**, select the checkbox.
6. Select **Apply and restart** to save your settings.
>**Important**
> Important
>
>Enhanced Container Isolation does not protect containers created prior to enabling ECI. For more information on known limitations and workarounds, see [FAQs](../../../faq/security/eci-faq.md).
> Enhanced Container Isolation does not protect containers created prior to enabling ECI. For more information on known limitations and workarounds, see [FAQs](../../../faq/security/eci-faq.md).
{ .important }
#### As an admin
To enable Enhanced Container Isolation as an admin, you first need to [configure a `registry.json` file to enforce sign-in](../../../security/for-admins/configure-sign-in.md). This is because the Enhanced Container Isolation feature requires a Docker Business subscription and therefore your Docker Desktop users must authenticate to your organization for this configuration to take effect.
To enable Enhanced Container Isolation as an admin, you first need to [configure a `registry.json` file to enforce sign-in](../../../security/for-admins/configure-sign-in.md).
This is because the Enhanced Container Isolation feature requires a Docker
Business subscription and therefore your Docker Desktop users must authenticate
to your organization for this configuration to take effect.
Next, you must [create and configure the `admin-settings.json` file](../settings-management/configure.md) and specify:
```JSON
```json
{
"configurationFileVersion": 2,
"enhancedContainerIsolation": {
"configurationFileVersion": 2,
"enhancedContainerIsolation": {
"value": true,
"locked": true
}
}
}
```
By setting `"value": true`, the admin ensures ECI is enabled by default. By setting `"locked": true`, the admin ensures ECI can't be disabled by developers. If you wish to give developers the ability to disable the feature, set `"locked": false`.
By setting `"value": true`, the admin ensures ECI is enabled by default. By
setting `"locked": true`, the admin ensures ECI can't be disabled by
developers. If you wish to give developers the ability to disable the feature,
set `"locked": false`.
In addition, starting with Docker Desktop 4.27, admins can also configure Docker
socket mount permissions for containers, as described [here](config.md).
For this to take effect:
- On a new install, developers need to launch Docker Desktop and authenticate to their organization.
- On an existing install, developers need to quit Docker Desktop through the Docker menu, and then relaunch Docker Desktop. If they are already signed in, they don’t need to sign in again for the changes to take effect.
>Important
>
>Selecting **Restart** from the Docker menu isn't enough as it only restarts some components of Docker Desktop.
{ .important }
> Important
>
> Selecting **Restart** from the Docker menu isn't enough as it only restarts some components of Docker Desktop.
{ .important }
### What do users see when this setting is enforced by an admin?

278
content/desktop/hardened-desktop/enhanced-container-isolation/config.md Normal file
View File

@ -0,0 +1,278 @@
---
description: Advanced Configuration for Enhanced Container Isolation
title: Enhanced Container Isolation Configuration
keywords: enhanced container isolation, Docker Desktop, Docker socket, bind mount, configuration
---
This section describes configuration specific to Enhanced Container Isolation (ECI).
### Enabling ECI
ECI may be enabled by users or admins, as described [here](_index.md#how-do-i-enable-enhanced-container-isolation).
The sections below describe optional, advanced configurations for ECI.
### Docker Socket Mount Permissions (Beta)
> Note
>
> This feature is available since Docker Desktop 4.27 and it's currently in
> [Beta](../../../release-lifecycle.md/#beta). It does not yet work on Windows
> hosts when Docker Desktop configured to use WSL (but does work with Hyper-V).
By default, when ECI is enabled, Docker Desktop does not allow bind-mounting the
Docker Engine socket into containers:
```console
$ docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock docker:cli
docker: Error response from daemon: enhanced container isolation: docker socket mount denied for container with image "docker.io/library/docker"; image is not in the allowed list; if you wish to allow it, configure the docker socket image list in the Docker Desktop settings.
```
This prevents malicious containers from gaining access to the Docker Engine, as
such access could allow them to perform supply chain attacks (e.g., build and
push malicious images into the organization's repositories) or similar.
However, some legitimate use-cases require containers to have access to the
Docker Engine socket. For example, the popular [TestContainers](https://testcontainers.com/)
framework sometimes bind-mounts the Docker Engine socket into containers to
manage them, perform post-test cleanup, etc.
Starting with Docker Desktop 4.27, admins can optionally configure ECI to allow
bind mounting the Docker Engine socket into containers, but in a controlled way.
This can be done via the `admin-settings.json` file, as described in
[Settings Management](../settings-management/configure.md). For example:
```json
{
"configurationFileVersion": 2,
"enhancedContainerIsolation": {
"locked": true,
"value": true,
"dockerSocketMount": {
"imageList": {
"images": [
"docker.io/localstack/localstack:*",
"docker.io/testcontainers/ryuk:*",
"docker:cli"
]
},
"commandList": {
"type": "deny",
"commands": ["push"]
}
}
}
}
```
As shown above, there are two configurations for bind-mounting the Docker
socket into containers: the `imageList` and the `commandList`. These are
described below.
#### Image List
The `imageList` is a list of container images that are allowed to bind-mount the
Docker socket. By default the list is empty (i.e., no containers are allowed to
bind-mount the Docker socket when ECI is enabled). However, an admin can add
images to the list, using either of these formats:
| Image Reference Format | Description |
| :---------------------- | :---------- |
| `<image_name>[:<tag>]` | Name of the image, with optional tag; if tag is omitted, the `:latest` tag is used; if tag is the wildcard `*`, then it means "any tag for that image." |
| `<image_name>@<digest>` | Name of the image, with a specific repository digest (e.g., as reported by `docker buildx imagetools inspect <image>`). This means only the image that matches that name and digest is allowed. |
The image name follows the standard convention, so it can point to any registry
and repository.
In the example above, the image list was configured with three images:
```json
"imageList": {
"images": [
"docker.io/localstack/localstack:*",
"docker.io/testcontainers/ryuk:*",
"docker:cli"
]
}
```
This means that containers that use either the `docker.io/localstack/localstack`
or the `docker.io/testcontainers/ryuk` image (with any tag), or the `docker:cli`
image, are allowed to bind-mount the Docker socket when ECI is enabled. Thus,
the following works:
```console
$ docker run -it -v /var/run/docker.sock:/var/run/docker.sock docker:cli sh
/ #
```
> Note
>
> Be restrictive on the images you allow, as described in [Recommendations](#recommendations) below.
In general, it's easiest to specify the image using the tag wildcard format
(e.g., `<image-name>:*`) because this way the image list in the
`admin-settings.json` file need not be updated whenever a new version of the
image is used. Alternatively, one can use an immutable tag (e.g., `:latest`),
but it does not work always work as well as the wildcard because, for example,
TestContainers uses specific versions of the image, not necessarily the latest
one.
When ECI is enabled, Docker Desktop periodically downloads the image digests
for the allowed images from the appropriate registry and stores them in
memory. Then, when a container is started with a Docker socket bind-mount,
Docker Desktop checks if the container's image digest matches one of the allowed
digests. If so, the container is allowed to start, otherwise it's blocked.
Note that due to the digest comparison mentioned in the prior paragraph, it's
not possible to bypass the Docker socket mount permissions by retagging a
disallowed image to the name of an allowed one. In other words, if a user
does:
```console
$ docker image rm <allowed_image>
$ docker tag <disallowed_image> <allowed_image>
$ docker run -v /var/run/docker.sock:/var/run/docker.sock <allowed_image>
```
then the tag operation will succeed, but the `docker run` command will fail
because the image digest of the disallowed image won't match that of the allowed
ones in the repository.
#### Command List
The `commandList` restricts the Docker commands that a container can issue via a
bind-mounted Docker socket when ECI is enabled. It acts as a complementary
security mechanism to the `imageList` (i.e., like a second line of defense).
For example, say the `imageList` (see prior section) is configured to allow
image `docker:cli` to mount the Docker socket, and a container is started with
it:
```console
$ docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock sh
/ #
```
By default, this allows the container to issue any command via that Docker
socket (e.g., build and push images to the organisation's repositories), which
is generally not desirable.
To improve security, the `commandList` can be configured to restrict the
commands that the processes inside the container can issue on the bind-mounted
Docker socket. The `commandList` can be configured as a "deny" list (default) or
an "allow" list, depending on your preference.
Each command in the list is specified by its name, as reported by `docker
--help` (e.g., "ps", "build", "pull", "push", etc.) In addition, the following
command wildcards are allowed to block an entire group of commands:
| Command Wildcard | Description |
| :---------------- | :---------- |
| "container\*" | Refers to all "docker container ..." commands |
| "image\*" | Refers to all "docker image ..." commands |
| "volume\*" | Refers to all "docker volume ..." commands |
| "network\*" | Refers to all "docker network ..." commands |
| "build\*" | Refers to all "docker build ..." commands |
| "system\*" | Refers to all "docker system ..." commands |
For example, the following configuration blocks the `build` and `push` commands
on the Docker socket:
```json
"commandList": {
"type": "deny",
"commands": ["build", "push"]
}
```
Thus, if inside the container, one issues either of those commands on the
bind-mounted Docker socket, they will be blocked:
```console
/ # docker push myimage
Error response from daemon: enhanced container isolation: docker command "/v1.43/images/myimage/push?tag=latest" is blocked; if you wish to allow it, configure the docker socket command list in the Docker Desktop settings or admin-settings.
```
Similarly:
```console
/ # curl --unix-socket /var/run/docker.sock -XPOST http://localhost/v1.43/images/myimage/push?tag=latest
Error response from daemon: enhanced container isolation: docker command "/v1.43/images/myimage/push?tag=latest" is blocked; if you wish to allow it, configure the docker socket command list in the Docker Desktop settings or admin-settings.
```
Note that if the `commandList` had been configured as an "allow" list, then the
effect would be the opposite: only the listed commands would have been allowed.
Whether to configure the list as an allow or deny list depends on the use case.
#### Recommendations
* Be restrictive on the list container images for which you allow bind-mounting
of the Docker socket (i.e., the `imageList`). Generally, only allow this for
images that absolutely needed and that you trust.
* Admins should use the tag wildcard format if possible in the `imageList`
(e.g., `<image_name>:*`), as this eliminates the need to update the
`admin-settings.json` file due to image tag changes.
* In the `commandList`, block commands that you don't expect the container to
execute. For example, for local testing (e.g., TestContainers), containers that bind-mount the Docker
socket typically create / run / remove containers, volumes, and networks, but
don't typically build images or push them into repositories (though some may
legitimately do this). What commands to allow or block depends on the use case.
- Note that all "docker" commands issued by the container via the bind-mounted
Docker socket will also execute under enhanced container isolation (i.e.,
the resulting container uses a the Linux user-namespace, sensitive system
calls are vetted, etc.)
#### Caveats and Limitations
* Docker Socket Mount permissions don't yet work on Docker Desktop on Windows
hosts with WSL (but they work on Hyper-V). Support for WSL is expected to be
added soon.
* When Docker Desktop is restarted, it's possible that an image that is allowed
to mount the Docker socket is unexpectedly blocked from doing so. This can
happen when the image digest changes in the remote repository (e.g., a
":latest" image was updated) and the local copy of that image (e.g., from a
prior `docker pull`) no longer matches the digest in the remote repository. In
this case, remove the local image and pull it again (e.g., `docker rm <image>`
and `docker pull <image>`).
* It's not possible to allow Docker socket bind-mounts on images that are not on
a registry (e.g., images built locally and not yet pushed to a
registry). That's because Docker Desktop pulls the digests for the allowed
images from the registry, and then uses that to compare against the local copy
of the image.
* The `commandList` configuration applies to all containers that are allowed to
bind-mount the Docker socket. Therefore it can't be configured differently per
container.
* The following commands are not yet supported in the `commandList`:
| Unsupported command | Description |
| :------------------- | :---------- |
| compose | Docker compose |
| dev | Docker dev environments |
| extension | Manages Docker extensions |
| feedback | Send feedback to Docker |
| init | Creates Docker-related starter files |
| manifest | Manages Docker image manifests |
| plugins | Manages plugins |
| sbom | View Software Bill of Materials (SBOM) |
| scan | Docker Scan |
| scout | Docker Scout |
| trust | Manage trust on Docker images |
> Note
>
> Docker socket mount permissions do not apply when running "true"
> Docker-in-Docker (i.e., when running the Docker Engine inside a container). In
> this case there's no bind-mount of the host's Docker socket into the
> container, and therefore no risk of the container leveraging the configuration
> and credentials of the host's Docker Engine to perform malicious activity.
> Enhanced Container Isolation is capable of running Docker-in-Docker securely,
> without giving the outer container true root permissions in the Docker Desktop
> VM.

21
content/desktop/hardened-desktop/enhanced-container-isolation/features-benefits.md
View File

@ -1,8 +1,7 @@
---
description: The benefits of enhanced container isolation
title: Key features and benefits
keywords: set up, enhanced container isolation, rootless, security, features, Docker
Desktop
keywords: set up, enhanced container isolation, rootless, security, features, Docker Desktop
---
### Linux User Namespace on all containers
@ -62,9 +61,10 @@ workloads whether benign or malicious to gain control of the Linux kernel
inside the Docker Desktop VM and thus modify security related settings, for example registry
access management, and network proxies.
With Enhanced Container Isolation, privileged containers can no longer do this. The combination of the Linux user-namespace and other security techniques used
by Sysbox ensures that processes inside a privileged container can only access
resources assigned to the container.
With Enhanced Container Isolation, privileged containers can no longer do
this. The combination of the Linux user-namespace and other security techniques
used by Sysbox ensures that processes inside a privileged container can only
access resources assigned to the container.
> Note
>
@ -169,14 +169,11 @@ $ docker run -it --rm -v $HOME:/mnt alpine
> Note
>
> Enhanced Container Isolation won't allow bind mounting the Docker socket
> By default, Enhanced Container Isolation won't allow bind mounting the Docker Engine socket
> (/var/run/docker.sock) into a container, as doing so essentially grants the
> container control of Docker Engine, thus breaking container
> isolation. Containers that rely on this will not work with Enhanced Container
> Isolation enabled. Instead, use Docker-in-Docker (i.e., run the Docker Engine
> fully inside a Docker Container). Enhanced Container Isolation is capable of
> running Docker-in-Docker securely, without giving the outer container root
> privileges in the Docker Desktop Linux VM.
> container control of Docker Engine, thus breaking container isolation. However,
> as some legitimate use cases require this, it's possible to relax
> this restriction for trusted container images. See [Docker socket mount permissions](config.md#docker-socket-mount-permissions).
### Vetting sensitive system calls

10
content/desktop/hardened-desktop/enhanced-container-isolation/how-eci-works.md
View File

@ -4,10 +4,6 @@ title: How does it work?
keywords: set up, enhanced container isolation, rootless, security
---
>**Note**
>
> Enhanced Container Isolation is available to Docker Business customers only.
Docker implements Enhanced Container Isolation by using the [Sysbox
container runtime](https://github.com/nestybox/sysbox). Sysbox is a fork of the
standard OCI runc runtime that was modified to enhance standard container isolation and
@ -26,14 +22,14 @@ Even containers that use the insecure `--privileged` flag can now be run
securely with Enhanced Container Isolation, such that they can no longer be used
to breach the Docker Desktop Virtual Machine (VM) or other containers.
>Note
> Note
>
> When Enhanced Container Isolation is enabled in Docker Desktop, the Docker CLI
> "--runtime" flag is ignored. Docker's default runtime continues to be "runc",
> but all user containers are implicitly launched with Sysbox.
Enhanced Container Isolation is not the same as Docker Engine's userns-remap
mode or Rootless Docker. This is explained further below.
mode or Rootless Docker. This is explained further below.
### Under the hood
@ -67,7 +63,7 @@ Userns-remap mode is similar to Enhanced Container Isolation in that both improv
container isolation by leveraging the Linux user-namespace.
However, Enhanced Container Isolation is much more advanced since it assigns
exclusive user-namespace mappings per container automatically and add several
exclusive user-namespace mappings per container automatically and adds several
other [container isolation features](#under-the-hood) meant to secure Docker
Desktop in organizations with stringent security requirements.

8
content/desktop/hardened-desktop/enhanced-container-isolation/limitations.md
View File

@ -22,7 +22,7 @@ configured to use either Hyper-V or WSL version 2.
> it returns a version number prior to 1.1.3.0, update WSL to the latest version
> by typing `wsl --update` in a Windows command or PowerShell terminal.
Note,however, that ECI on WSL is not as secure as on Hyper-V because:
Note however that ECI on WSL is not as secure as on Hyper-V because:
* While ECI on WSL still hardens containers so that malicious workloads can't
easily breach Docker Desktop's Linux VM, ECI on WSL can't prevent Docker
@ -63,11 +63,11 @@ these won't work properly.
### Kubernetes pods are not yet protected
Kubernetes pods are not yet protected by ECI. A malicious or privileged pod can
compromise the Docker Desktop Linux VM and bypass security controls.
compromise the Docker Desktop Linux VM and bypass security controls.
### Extension containers are not yet protected
Extension containers are also not yet protected by ECI. Ensure you extension
containers come from trusted entities to avoid issues.
containers come from trusted entities to avoid issues.
### Docker Desktop dev environments are not yet protected
Containers launched by the Docker Desktop Dev Environments feature are not yet
@ -81,4 +81,4 @@ that same container in production, through the standard OCI `runc` runtime.
However in some cases, typically when running advanced or privileged workloads in
containers, users may experience some differences. In particular, the container
may run with ECI but not with `runc`, or vice-versa.
may run with ECI but not with `runc`, or vice-versa.

23
content/desktop/hardened-desktop/settings-management/configure.md
View File

@ -70,7 +70,19 @@ The following `admin-settings.json` code and table provides an example of the re
},
"enhancedContainerIsolation": {
"locked": true,
"value": true
"value": true,
"dockerSocketMount": {
"imageList": {
"images": [
"docker.io/localstack/localstack:*",
"docker.io/testcontainers/ryuk:*"
]
},
"commandList": {
"type": "deny",
"commands": ["push"]
}
}
},
"linuxVM": {
"wslEngineEnabled": {
@ -108,7 +120,7 @@ The following `admin-settings.json` code and table provides an example of the re
},
"extensionsEnabled": {
"locked": true,
"value": false
"value": false
},
"scout": {
"locked": false,
@ -125,7 +137,7 @@ The following `admin-settings.json` code and table provides an example of the re
},
"blockDockerLoad": {
"locked": false,
"value": true
"value": true
}
}
```
@ -136,7 +148,10 @@ The following `admin-settings.json` code and table provides an example of the re
| `exposeDockerAPIOnTCP2375` | <span class="badge badge-info">Windows only</span>| Exposes the Docker API on a specified port. If `value` is set to true, the Docker API is exposed on port 2375. Note: This is unauthenticated and should only be enabled if protected by suitable firewall rules.|
| `proxy` | |If `mode` is set to `system` instead of `manual`, Docker Desktop gets the proxy values from the system and ignores and values set for `http`, `https` and `exclude`. Change `mode` to `manual` to manually configure proxy servers. If the proxy port is custom, specify it in the `http` or `https` property, for example `"https": "http://myotherproxy.com:4321"`. The `exclude` property specifies a comma-separated list of hosts and domains to bypass the proxy. |
&nbsp; &nbsp; &nbsp; &nbsp;`windowsDockerdPort` | <span class="badge badge-info">Windows only</span> | Exposes Docker Desktop's internal proxy locally on this port for the Windows Docker daemon to connect to. If it is set to 0, a random free port is chosen. If the value is greater than 0, use that exact value for the port. The default value is -1 which disables the option. Note: This is available for Windows containers only. |
| `enhancedContainerIsolation` | | If `value` is set to true, Docker Desktop runs all containers as unprivileged, via the Linux user-namespace, prevents them from modifying sensitive configurations inside the Docker Desktop VM, and uses other advanced techniques to isolate them. For more information, see [Enhanced Container Isolation](../enhanced-container-isolation/index.md).|
| `enhancedContainerIsolation` | | If `value` is set to true, Docker Desktop runs all containers as unprivileged, via the Linux user-namespace, prevents them from modifying sensitive configurations inside the Docker Desktop VM, and uses other advanced techniques to isolate them. For more information, see [Enhanced Container Isolation](../enhanced-container-isolation/index.md).|
| &nbsp; &nbsp; &nbsp; &nbsp;`dockerSocketMount` | | By default, enhanced container isolation blocks bind-mounting the Docker Engine socket into containers (e.g., `docker run -v /var/run/docker.sock:/var/run/docker.sock ...`). This allows admins to relax this in a controlled way. See [ECI Configuration](../enhanced-container-isolation/config.md) for more info. |
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; `imageList` | | Indicates which container images are allowed to bind-mount the Docker Engine socket. |
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; `commandList` | | Restricts the commands that containers can issue via the bind-mounted Docker Engine socket. |
| `linuxVM` | |Parameters and settings related to Linux VM options - grouped together here for convenience. |
| &nbsp; &nbsp; &nbsp; &nbsp;`wslEngineEnabled` | <span class="badge badge-info">Windows only</span> | If `value` is set to true, Docker Desktop uses the WSL 2 based engine. This overrides anything that may have been set at installation using the `--backend=<backend name>` flag.
| &nbsp;&nbsp; &nbsp; &nbsp;`dockerDaemonOptions`| |If `value` is set to true, it overrides the options in the Docker Engine config file. See the [Docker Engine reference](/engine/reference/commandline/dockerd/#daemon-configuration-file). Note that for added security, a few of the config attributes may be overridden when Enhanced Container Isolation is enabled. |

10
data/toc.yaml
View File

@ -175,7 +175,7 @@ Guides:
- path: /develop/develop-images/dockerfile_best-practices/
title: Overview
- path: /develop/develop-images/guidelines/
title: General guidelines
title: General guidelines
- path: /develop/develop-images/instructions/
title: Best practices for Dockerfile instructions
- path: /develop/security-best-practices/
@ -936,7 +936,7 @@ Reference:
- path: /compose/compose-file/deploy/
title: Compose Deploy Specification
- path: /compose/compose-file/develop/
title: Compose Develop Specification
title: Compose Develop Specification
- sectiontitle: Legacy versions
section:
- path: /compose/compose-file/compose-versioning/
@ -1087,7 +1087,7 @@ Manuals:
- path: /desktop/use-desktop/volumes/
title: Explore Volumes
- path: /desktop/use-desktop/builds/
title: Explore Builds
title: Explore Builds
- path: /desktop/use-desktop/resource-saver/
title: Resource Saver mode
- path: /desktop/use-desktop/pause/
@ -1106,6 +1106,8 @@ Manuals:
section:
- path: /desktop/hardened-desktop/enhanced-container-isolation/
title: What is Enhanced Container Isolation?
- path: /desktop/hardened-desktop/enhanced-container-isolation/config/
title: Advanced Configuration (Beta)
- path: /desktop/hardened-desktop/enhanced-container-isolation/how-eci-works/
title: How does it work?
- path: /desktop/hardened-desktop/enhanced-container-isolation/features-benefits/
@ -2077,7 +2079,7 @@ Manuals:
- sectiontitle: Two-factor authentication
section:
- path: /security/for-developers/2fa/
title: Enable two-factor authentication
title: Enable two-factor authentication
- path: /security/for-developers/2fa/disable-2fa/
title: Disable two-factor authentication
- path: /security/for-developers/2fa/recover-hub-account/