You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/_index.md
+24-49Lines changed: 24 additions & 49 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,49 +13,41 @@ weight: 20
13
13
>
14
14
> Enhanced Container Isolation is available to Docker Business customers only.
15
15
16
-
Enhanced Container Isolation provides an additional layer of security to prevent malicious workloads running in containers from compromising Docker Desktop or the host.
16
+
Enhanced Container Isolation (ECI) provides an additional layer of security to prevent malicious workloads running in containers from compromising Docker Desktop or the host.
17
17
18
-
It uses a variety of advanced techniques to harden container isolation, but without impacting developer productivity. It is available with [Docker Desktop 4.13.0 and later](/manuals/desktop/release-notes.md).
18
+
It uses a variety of advanced techniques to harden container isolation, but without impacting developer productivity.
19
19
20
-
These techniques include:
21
-
- Running all containers unprivileged through the Linux user-namespace, even those launched with the `--privileged` flag. This makes it harder for malicious container workloads to escape the container and infect the Docker Desktop VM and host.
22
-
- Ensuring Docker Desktop VM immutability (e.g., its internal settings can't be modified by containers or users).
23
-
- Vetting some critical system calls to prevent container escapes, and partially virtualizing portions of `/proc` and `/sys` inside the container for further isolation.
24
-
- Preventing user console access to the Docker Desktop VM.
25
-
26
-
When Enhanced Container Isolation is enabled, these mechanisms are applied automatically and with minimal functional or performance impact to developers. Developers continue to use Docker Desktop as usual, but the containers they launch are more strongly isolated.
27
-
28
-
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](/manuals/security/for-admins/hardened-desktop/registry-access-management.md) or with [Settings Management](../settings-management/_index.md).
20
+
Enhanced Container Isolation ensures stronger container isolation and also locks in any security configurations that have been created by administrators, for instance through [Registry Access Management policies](/manuals/security/for-admins/hardened-desktop/registry-access-management.md) or with [Settings Management](../settings-management/_index.md).
29
21
30
22
> [!NOTE]
31
23
>
32
-
> Enhanced Container Isolation is in addition to other container security techniques used by Docker. For example, reduced Linux Capabilities, Seccomp, AppArmor.
24
+
> ECI is in addition to other container security techniques used by Docker. For example, reduced Linux Capabilities, Seccomp, AppArmor.
33
25
34
-
###Who is it for?
26
+
## Who is it for?
35
27
36
28
- For organizations and developers that want to prevent container attacks and reduce vulnerabilities in developer environments.
37
29
- For organizations that want to ensure stronger container isolation that is easy and intuitive to implement on developers' machines.
38
30
39
-
###What happens when Enhanced Container Isolation is turned on?
31
+
## What happens when Enhanced Container Isolation is turned on?
40
32
41
-
When Enhanced Container Isolation is turned on, the following features are enabled:
33
+
When Enhanced Container Isolation is turned on, the following features and security techniques are enabled:
42
34
43
-
- All user containers are automatically run in Linux User Namespaces which ensures stronger isolation. Each container runs in a dedicated Linux user-namespace.
35
+
- All user containers are automatically run in Linux user namespaces which ensures stronger isolation. Each container runs in a dedicated Linux user-namespace.
44
36
- The root user in the container maps to an unprivileged user inside the Docker Desktop Linux VM.
45
-
- Containers become harder to breach. For example, sensitive system calls are vetted and portions of `/proc` and `/sys` are emulated.
37
+
- Containers become harder to breach. For example, sensitive system calls are vetted and portions of `/proc` and `/sys` are emulated inside the container.
46
38
- Users can continue using containers as usual, including bind mounting host directories, volumes, etc.
47
39
- No change in the way developers run containers, and no special container images are required.
48
-
- Privileged containers (e.g., `--privileged` flag) work, but they are only privileged within the container's Linux User Namespace, not in the Docker Desktop VM. Therefore they can't be used to breach the Docker Desktop VM.
40
+
- Privileged containers (e.g., `--privileged` flag) work, but they are only privileged within the container's Linux user namespace, not in the Docker Desktop VM. Therefore they can't be used to breach the Docker Desktop VM.
49
41
- Docker-in-Docker and even Kubernetes-in-Docker works, but run unprivileged inside the Docker Desktop Linux VM.
50
42
51
43
In addition, the following restrictions are imposed:
52
44
53
45
- Containers can no longer share namespaces with the Docker Desktop VM (e.g., `--network=host`, `--pid=host` are disallowed).
54
46
- Containers can no longer modify configuration files inside the Docker Desktop VM (e.g., mounting any VM directory into the container is disallowed).
55
-
- 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).
47
+
- Containers can no longer access the Docker Engine. For example, mounting the Docker Engine's socket into the container is restricted which prevents malicious containers from gaining control of the Docker Engine. Administrators can relax this for [trusted container images](config.md).
56
48
- Console access to the Docker Desktop VM is forbidden for all users.
57
49
58
-
These features and restrictions ensure that containers are better secured at runtime, with minimal impact to developer experience and productivity.
50
+
These features and restrictions ensure that containers are better secured at runtime, with minimal impact to developer experience and productivity. Developers can continue to use Docker Desktop as usual, but the containers they launch are more strongly isolated.
59
51
60
52
For more information on how Enhanced Container Isolation work, see [How does it work](how-eci-works.md).
61
53
@@ -65,20 +57,9 @@ For more information on how Enhanced Container Isolation work, see [How does it
65
57
> Kubernetes pods and Extension containers. For more information on known
66
58
> limitations and workarounds, see [FAQs](faq.md).
67
59
68
-
### What host OSes / platforms is Enhanced Container Isolation supported on?
69
-
70
-
Enhanced Container Isolation (ECI) was introduced in Docker Desktop 4.13, for all platforms (Windows, Mac, and Linux).
71
-
72
-
For Windows hosts, ECI works with both the Docker Desktop Hyper-V and WSL 2 backends, as follows:
60
+
## How do I enable Enhanced Container Isolation?
73
61
74
-
- Docker Desktop 4.19 or prior: ECI only works with Hyper-V.
75
-
- Docker Desktop 4.20 or later: ECI Works with both Hyper-V and WSL 2 (with WSL version 1.1.3.0 and above).
76
-
77
-
See [ECI Support for WSL](limitations.md#eci-support-for-wsl) for further info as well as security caveats when using Enhanced Container Isolation on WSL 2.
78
-
79
-
### How do I enable Enhanced Container Isolation?
80
-
81
-
#### As a developer
62
+
### As a developer
82
63
83
64
To enable Enhanced Container Isolation as a developer:
84
65
1. Ensure your organization has a Docker Business subscription.
@@ -92,19 +73,13 @@ To enable Enhanced Container Isolation as a developer:
92
73
>
93
74
> Enhanced Container Isolation does not protect containers created prior to enabling ECI. For more information on known limitations and workarounds, see [FAQs](faq.md).
94
75
95
-
#### As an admin
96
-
97
-
##### Prerequisite
76
+
### As an administrator
98
77
99
-
To enable Enhanced Container Isolation as an admin, you first need to [enforce
100
-
sign-in](/manuals/security/for-admins/enforce-sign-in/_index.md). This is
101
-
because the Enhanced Container Isolation feature requires a Docker Business
102
-
subscription and therefore your Docker Desktop users must authenticate to your
103
-
organization for this configuration to take effect.
78
+
#### Prerequisite
104
79
105
-
Enforcing sign-in ensures that your Docker Desktop developers always authenticate to your organization.
80
+
You first need to [enforce sign-in](/manuals/security/for-admins/enforce-sign-in/_index.md) to ensure that all Docker Desktop developers authenticate with your organization. Since Settings Management requires a Docker Business subscription, enforced sign-in guarantees that only authenticated users have access and that the feature consistently takes effect across all users, even though it may still work without enforced sign-in.
106
81
107
-
#####Setup
82
+
#### Setup
108
83
109
84
[Create and configure the `admin-settings.json` file](../settings-management/configure.md) and specify:
110
85
@@ -118,13 +93,13 @@ Enforcing sign-in ensures that your Docker Desktop developers always authenticat
118
93
}
119
94
```
120
95
121
-
By setting `"value": true`, the admin ensures ECI is enabled by default. By
122
-
setting `"locked": true`, the admin ensures ECI can't be disabled by
123
-
developers. If you wish to give developers the ability to disable the feature,
96
+
Setting `"value": true` ensures ECI is enabled by default. By
97
+
setting `"locked": true`, ECI can't be disabled by
98
+
developers. If you want to give developers the ability to disable the feature,
124
99
set `"locked": false`.
125
100
126
-
In addition, starting with Docker Desktop 4.27, admins can also configure Docker
127
-
socket mount permissions for containers, as described [here](config.md).
101
+
In addition, you can also [configure Docker
102
+
socket mount permissions for containers](config.md).
128
103
129
104
For this to take effect:
130
105
@@ -135,7 +110,7 @@ For this to take effect:
135
110
>
136
111
> Selecting **Restart** from the Docker menu isn't enough as it only restarts some components of Docker Desktop.
137
112
138
-
###What do users see when this setting is enforced by an admin?
113
+
## What do users see when this setting is enforced by an administrator?
139
114
140
115
When Enhanced Container Isolation is enabled, users see:
141
116
-**Use Enhanced Container Isolation** toggled on in **Settings** > **General**.
Copy file name to clipboardExpand all lines: content/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/config.md
+29-41Lines changed: 29 additions & 41 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,25 +8,18 @@ aliases:
8
8
weight: 30
9
9
---
10
10
11
-
> [!NOTE]
12
-
>
13
-
> This feature is available with Docker Desktop version 4.27 (and later) on Mac, Linux, and Windows (Hyper-V).
14
-
> For Windows with WSL 2, this feature requires Docker Desktop 4.28 and later.
15
-
16
-
This page describes optional, advanced configurations for ECI, once ECI is enabled.
17
-
18
11
## Docker socket mount permissions
19
12
20
-
By default, when ECI is enabled, Docker Desktop does not allow bind-mounting the
13
+
By default, when Enhanced Container Isolation (ECI) is enabled, Docker Desktop does not allow bind-mounting the
21
14
Docker Engine socket into containers:
22
15
23
16
```console
24
17
$ docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock docker:cli
25
18
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.
26
19
```
27
20
This prevents malicious containers from gaining access to the Docker Engine, as
28
-
such access could allow them to perform supply chain attacks (e.g., build and
29
-
push malicious images into the organization's repositories) or similar.
21
+
such access could allow them to perform supply chain attacks. For example, build and
22
+
push malicious images into the organization's repositories or similar.
30
23
31
24
However, some legitimate use cases require containers to have access to the
32
25
Docker Engine socket. For example, the popular [Testcontainers](https://testcontainers.com/)
@@ -35,11 +28,11 @@ manage them or perform post-test cleanup. Similarly, some Buildpack frameworks,
35
28
for example [Paketo](https://paketo.io/), require Docker socket bind-mounts into
36
29
containers.
37
30
38
-
Starting with Docker Desktop 4.27, admins can optionally configure ECI to allow
31
+
Administrators can optionally configure ECI to allow
39
32
bind mounting the Docker Engine socket into containers, but in a controlled way.
40
33
41
34
This can be done via the Docker Socket mount permissions section in the
42
-
[admin-settings.json](../settings-management/configure.md) file. For example:
35
+
[`admin-settings.json`](../settings-management/configure.md) file. For example:
43
36
44
37
```json
45
38
{
@@ -64,15 +57,14 @@ This can be done via the Docker Socket mount permissions section in the
64
57
}
65
58
```
66
59
67
-
As shown above, there are two configurations for bind-mounting the Docker
68
-
socket into containers: the `imageList` and the `commandList`. These are
69
-
described below.
60
+
There are two configurations for bind-mounting the Docker
61
+
socket into containers - the `imageList` and the `commandList`.
70
62
71
63
### Image list
72
64
73
65
The `imageList` is a list of container images that are allowed to bind-mount the
74
-
Docker socket. By default the list is empty (i.e., no containers are allowed to
75
-
bind-mount the Docker socket when ECI is enabled). However, an admin can add
66
+
Docker socket. By default the list is empty, no containers are allowed to
67
+
bind-mount the Docker socket when ECI is enabled. However, an administrator can add
76
68
images to the list, using either of these formats:
77
69
78
70
| Image Reference Format | Description |
@@ -83,7 +75,7 @@ images to the list, using either of these formats:
83
75
The image name follows the standard convention, so it can point to any registry
84
76
and repository.
85
77
86
-
In the example above, the image list was configured with three images:
78
+
In the previous example, the image list was configured with three images:
87
79
88
80
```json
89
81
"imageList": {
@@ -107,11 +99,10 @@ $ docker run -it -v /var/run/docker.sock:/var/run/docker.sock docker:cli sh
107
99
108
100
> [!TIP]
109
101
>
110
-
> Be restrictive on the images you allow, as described in [Recommendations](#recommendations) below.
102
+
> Be restrictive with the images you allow, as described in [Recommendations](#recommendations).
111
103
112
-
In general, it's easier to specify the image using the tag wildcard format
113
-
(e.g., `<image-name>:*`) because then `imageList` doesn't need to be updated whenever a new version of the
114
-
image is used. Alternatively, you can use an immutable tag (e.g., `:latest`),
104
+
In general, it's easier to specify the image using the tag wildcard format, for example `<image-name>:*`, because then `imageList` doesn't need to be updated whenever a new version of the
105
+
image is used. Alternatively, you can use an immutable tag, for example `:latest`,
115
106
but it does not always work as well as the wildcard because, for example,
116
107
Testcontainers uses specific versions of the image, not necessarily the latest
117
108
one.
@@ -122,8 +113,7 @@ memory. Then, when a container is started with a Docker socket bind-mount,
122
113
Docker Desktop checks if the container's image digest matches one of the allowed
123
114
digests. If so, the container is allowed to start, otherwise it's blocked.
124
115
125
-
Note that due to the digest comparison mentioned in the prior paragraph, it's
126
-
not possible to bypass the Docker socket mount permissions by retagging a
116
+
Due to the digest comparison, it's not possible to bypass the Docker socket mount permissions by re-tagging a
127
117
disallowed image to the name of an allowed one. In other words, if a user
128
118
does:
129
119
@@ -139,11 +129,9 @@ ones in the repository.
139
129
140
130
### Docker Socket Mount Permissions for derived images
141
131
142
-
> [!NOTE]
143
-
>
144
-
> This feature is available with Docker Desktop version 4.34 and later.
0 commit comments