Mention ECI in the Mac/Windows permission requirements section.

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

content/desktop/mac/permission-requirements.md

@@ -15,7 +15,7 @@ It also provides clarity on running containers as `root` as opposed to having `r
 ## Permission requirements
 
 Docker Desktop for Mac is run as an unprivileged user. However, Docker Desktop requires certain functionalities to perform a limited set of privileged configurations such as:
- - [Installing symlinks](#installing-symlinks) in`/usr/local/bin`. 
+ - [Installing symlinks](#installing-symlinks) in`/usr/local/bin`.
  - [Binding privileged ports](#binding-privileged-ports) that are less than 1024. The so-called "privileged ports" are not generally used as a security boundary, however operating systems still prevent unprivileged processes from binding them which breaks commands like `docker run -p 127.0.0.1:80:80 docker/getting-started`.
  - [Ensuring `localhost` and `kubernetes.docker.internal` are defined](#ensuring-localhost-and-kubernetesdockerinternal-are-defined) in `/etc/hosts`. Some old macOS installs don't have `localhost` in `/etc/hosts`, which causes Docker to fail. Defining the DNS name `kubernetes.docker.internal` allows Docker to share Kubernetes contexts with containers.
  - Securely caching the Registry Access Management policy which is read-only for the developer.
@@ -25,16 +25,16 @@ Depending on which version of Docker Desktop for Mac is used, privileged access
 {{< tabs >}}
 {{< tab name="Version 4.18 and later" >}}
 
-From version 4.18 and later, Docker Desktop for Mac provides greater control over functionality that's enabled during installation. 
+From version 4.18 and later, Docker Desktop for Mac provides greater control over functionality that's enabled during installation.
 
-The first time Docker Desktop for Mac launches, it presents an installation window where you can choose to either use the default settings, which work for most developers and requires you to grant privileged access, or use advanced settings. 
+The first time Docker Desktop for Mac launches, it presents an installation window where you can choose to either use the default settings, which work for most developers and requires you to grant privileged access, or use advanced settings.
 
 If you work in an environment with elevated security requirements, for instance where local administrative access is prohibited, then you can use the advanced settings to remove the need for granting privileged access. You can configure:
 - The location of the Docker CLI tools either in the system or user directory
 - The default Docker socket
-- Privileged port mapping 
+- Privileged port mapping
 
-Depending on which advanced settings you configure, you must enter your password to confirm. 
+Depending on which advanced settings you configure, you must enter your password to confirm.
 
 You can change these configurations at a later date from the **Advanced** page in **Settings**.
 
@@ -62,18 +62,18 @@ The Docker binaries are installed by default in `/Applications/Docker.app/Conten
 
 With version 4.18 and later, you can choose whether to install symlinks either in `/usr/local/bin` or `$HOME/.docker/bin` during installation of Docker Desktop.
 
-If `/usr/local/bin` is chosen, and this location is not writable by unprivileged users, Docker Desktop requires authorization to confirm this choice before the symlinks to Docker binaries are created in `/usr/local/bin`. If `$HOME/.docker/bin` is chosen, authorization is not required, but the you must [manually add `$HOME/.docker/bin`](../settings/mac.md#advanced) to their PATH. 
+If `/usr/local/bin` is chosen, and this location is not writable by unprivileged users, Docker Desktop requires authorization to confirm this choice before the symlinks to Docker binaries are created in `/usr/local/bin`. If `$HOME/.docker/bin` is chosen, authorization is not required, but the you must [manually add `$HOME/.docker/bin`](../settings/mac.md#advanced) to their PATH.
 
-You are also given the option to enable the installation of the `/var/run/docker.sock` symlink. Creating this symlink ensures various Docker clients relying on the default Docker socket path to work without additional changes. 
+You are also given the option to enable the installation of the `/var/run/docker.sock` symlink. Creating this symlink ensures various Docker clients relying on the default Docker socket path to work without additional changes.
 
 As the `/var/run` is mounted as a tmpfs, its content is deleted on restart, symlink to the Docker socket included. To ensure the Docker socket exists after restart, Docker Desktop sets up a `launchd` startup task that creates the symlink by running `ln -s -f /Users/<user>/.docker/run/docker.sock /var/run/docker.sock`. This ensures the you aren't prompted on each startup to create the symlink. If you don't enable this option at installation, the symlink and the startup task is not created and you may have to explicitly set the `DOCKER_HOST` environment variable to `/Users/<user>/.docker/run/docker.sock` in the clients it is using. The Docker CLI relies on the current context to retrieve the socket path, the current context is set to `desktop-linux` on Docker Desktop startup.
 
 {{< /tab >}}
 {{< tab name="Version 4.17 and earlier" >}}
 
-For versions prior to 4.18, installing symlinks in `/usr/local/bin` is a privileged configuration Docker Desktop performs on the first startup. Docker Desktop checks if symlinks exists and takes the following actions: 
+For versions prior to 4.18, installing symlinks in `/usr/local/bin` is a privileged configuration Docker Desktop performs on the first startup. Docker Desktop checks if symlinks exists and takes the following actions:
 - Creates the symlinks without the admin prompt if `/usr/local/bin` is writable by unprivileged users.
-- Triggers an admin prompt for you to authorize the creation of symlinks in `/usr/local/bin`. If you authorizes this, symlinks to Docker binaries are created in `/usr/local/bin`. If you reject the prompt, are not willing to run configurations requiring elevated privileges, or don't have admin rights on your machine, Docker Desktop creates the symlinks in `~/.docker/bin` and edits your shell profile to ensure this location is in your PATH. This requires all open shells to be reloaded. 
+- Triggers an admin prompt for you to authorize the creation of symlinks in `/usr/local/bin`. If you authorizes this, symlinks to Docker binaries are created in `/usr/local/bin`. If you reject the prompt, are not willing to run configurations requiring elevated privileges, or don't have admin rights on your machine, Docker Desktop creates the symlinks in `~/.docker/bin` and edits your shell profile to ensure this location is in your PATH. This requires all open shells to be reloaded.
 The rejection is recorded for future runs to avoid prompting you again.
 For any failure to ensure binaries are on your PATH, you may need to manually add to their PATH the `/Applications/Docker.app/Contents/Resources/bin` or use the full path to Docker binaries.
 
@@ -93,7 +93,7 @@ With version 4.18 and later you can choose to enable privileged port mapping dur
 {{< /tab >}}
 {{< tab name="Version 4.17 and earlier" >}}
 
-For versions below 4.18 , if you run a container that requires binding privileged ports, Docker Desktop first attempts to bind it directly as an unprivileged process. If the OS prevents this and it fails, Docker Desktop checks if the `com.docker.vmnetd` privileged helper process is running to bind the privileged port through it. 
+For versions below 4.18 , if you run a container that requires binding privileged ports, Docker Desktop first attempts to bind it directly as an unprivileged process. If the OS prevents this and it fails, Docker Desktop checks if the `com.docker.vmnetd` privileged helper process is running to bind the privileged port through it.
 
 If the privileged helper process is not running, Docker Desktop prompts you for authorization to run it under [launchd](https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html).
 This configures the privileged helper to run as in the versions of Docker Desktop prior to 4.15. However, the functionality provided by this privileged helper now only supports port binding and caching the Registry Access Management policy.
@@ -125,7 +125,7 @@ With versions 4.18 and later, it is your responsibility to ensure that localhost
 {{< /tab >}}
 {{< tab name="Version 4.17 and earlier" >}}
 
-On first run, Docker Desktop checks if `localhost` is resolved to `127.0.0.1`. In case the resolution fails, it prompts you to allow adding the mapping to `/etc/hosts`. Similarly, when the Kubernetes cluster is installed, it checks that `kubernetes.docker.internal` is resolved to `127.0.0.1` and prompts you to do so. 
+On first run, Docker Desktop checks if `localhost` is resolved to `127.0.0.1`. In case the resolution fails, it prompts you to allow adding the mapping to `/etc/hosts`. Similarly, when the Kubernetes cluster is installed, it checks that `kubernetes.docker.internal` is resolved to `127.0.0.1` and prompts you to do so.
 
 {{< /tab >}}
 {{< /tabs >}}
@@ -141,29 +141,47 @@ The limitation of this approach is that Docker Desktop can only be run by one us
 
 ## Privileged helper
 
-In the limited situations when the privileged helper is needed, for example binding privileged ports or caching the Registry Access Management policy, the privileged helper is started by `launchd` and runs in the background unless it is disabled at runtime as previously described. The Docker Desktop backend communicates with the privileged helper over the UNIX domain socket `/var/run/com.docker.vmnetd.sock`. The functionalities it performs are: 
+In the limited situations when the privileged helper is needed, for example binding privileged ports or caching the Registry Access Management policy, the privileged helper is started by `launchd` and runs in the background unless it is disabled at runtime as previously described. The Docker Desktop backend communicates with the privileged helper over the UNIX domain socket `/var/run/com.docker.vmnetd.sock`. The functionalities it performs are:
 - Binding privileged ports that are less than 1024.
 - Securely caching the Registry Access Management policy which is read-only for the developer.
 - Uninstalling the privileged helper.
 
 The removal of the privileged helper process is done in the same way as removing `launchd` processes.
 
 ```console
-$ ps aux | grep vmnetd                                                
+$ ps aux | grep vmnetd
 root             28739   0.0  0.0 34859128    228   ??  Ss    6:03PM   0:00.06 /Library/PrivilegedHelperTools/com.docker.vmnetd
 user             32222   0.0  0.0 34122828    808 s000  R+   12:55PM   0:00.00 grep vmnetd
 
 $ sudo launchctl unload -w /Library/LaunchDaemons/com.docker.vmnetd.plist
 Password:
 
-$ ps aux | grep vmnetd                                                   
+$ ps aux | grep vmnetd
 user             32242   0.0  0.0 34122828    716 s000  R+   12:55PM   0:00.00 grep vmnetd
 
-$ rm /Library/LaunchDaemons/com.docker.vmnetd.plist 
+$ rm /Library/LaunchDaemons/com.docker.vmnetd.plist
 
-$ rm /Library/PrivilegedHelperTools/com.docker.vmnetd 
+$ rm /Library/PrivilegedHelperTools/com.docker.vmnetd
 ```
 
 ## Containers running as root within the Linux VM
 
-The Docker daemon and containers run in a lightweight Linux VM managed by Docker. This means that although containers run by default as `root`, this doesn't grant `root` access to the Mac host machine. The Linux VM serves as a security boundary and limits what resources can be accessed from the host. Any directories from the host bind mounted into Docker containers still retain their original permissions.
+With Docker Desktop, the Docker daemon and containers run in a lightweight Linux
+VM managed by Docker. This means that although containers run by default as
+`root`, this doesn't grant `root` access to the Mac host machine. The Linux VM
+serves as a security boundary and limits what resources can be accessed from the
+host. Any directories from the host bind mounted into Docker containers still
+retain their original permissions.
+
+## Enhanced Container Isolation
+
+In addition, Docker Desktop supports [Enhanced Container Isolation
+mode](../hardened-desktop/enhanced-container-isolation/_index.md) (ECI),
+available to Business customers only, which further secures containers without
+impacting developer workflows.
+
+ECI automatically runs all containers within a Linux user-namespace, such that
+root in the container is mapped to an unprivileged user inside the Docker
+Desktop VM. ECI uses this and other advanced techniques to further secure
+containers within the Docker Desktop Linux VM, such that they are further
+isolated from the Docker daemon and other services running inside the VM.

content/desktop/windows/permission-requirements.md

@@ -6,7 +6,7 @@ aliases:
 - /desktop/windows/privileged-helper/
 ---
 
-This page contains information about the permission requirements for running and installing Docker Desktop on Windows, the functionality of the privileged helper process `com.docker.service` and the reasoning behind this approach. 
+This page contains information about the permission requirements for running and installing Docker Desktop on Windows, the functionality of the privileged helper process `com.docker.service` and the reasoning behind this approach.
 
 It also provides clarity on running containers as `root` as opposed to having `Administrator` access on the host and the privileges of the Windows Docker engine and Windows containers.
 
@@ -34,18 +34,38 @@ The service performs the following functionalities:
 - Conducting healthchecks and retrieving the version of the service itself.
 
 The service start mode depends on which container engine is selected, and, for WSL, on whether it is needed to maintain `host.docker.internal` and `gateway.docker.internal` in the Win32 hosts file. This is controlled by a setting under `Use the WSL 2 based engine` in the settings page. When this is set, WSL engine behaves the same as Hyper-V. So:
-- With Windows containers, or Hyper-v Linux containers, the service is started when the system boots and runs all the time, even when Docker Desktop isn't running. This is required so you can launch Docker Desktop without admin privileges. 
+- With Windows containers, or Hyper-v Linux containers, the service is started when the system boots and runs all the time, even when Docker Desktop isn't running. This is required so you can launch Docker Desktop without admin privileges.
 - With WSL2 Linux containers, the service isn't necessary and therefore doesn't run automatically when the system boots. When you switch to Windows containers or Hyper-V Linux containers, or choose to maintain `host.docker.internal` and `gateway.docker.internal` in the Win32 hosts file, a UAC prompt is displayed which asks you to accept the privileged operation to start the service. If accepted, the service is started and set to start automatically upon the next Windows boot.
 
 ## Containers running as root within the Linux VM
 
-The Linux Docker daemon and containers run in a minimal, special-purpose Linux VM managed by Docker. It is immutable so you can’t extend it or change the installed software. 
-This means that although containers run by default as `root`, this doesn't allow altering the VM and doesn't grant `Administrator` access to the Windows host machine. The Linux VM serves as a security boundary and limits what resources from the host can be accessed. File sharing uses a user-space crafted file server and any directories from the host bind mounted into Docker containers still retain their original permissions. It doesn't give you access to any files that it doesn’t already have access to.
+The Linux Docker daemon and containers run in a minimal, special-purpose Linux
+VM managed by Docker. It is immutable so you can’t extend it or change the
+installed software.  This means that although containers run by default as
+`root`, this doesn't allow altering the VM and doesn't grant `Administrator`
+access to the Windows host machine. The Linux VM serves as a security boundary
+and limits what resources from the host can be accessed. File sharing uses a
+user-space crafted file server and any directories from the host bind mounted
+into Docker containers still retain their original permissions. It doesn't give
+you access to any files that it doesn’t already have access to.
+
+## Enhanced Container Isolation
+
+In addition, Docker Desktop supports [Enhanced Container Isolation
+mode](../hardened-desktop/enhanced-container-isolation/_index.md) (ECI),
+available to Business customers only, which further secures containers without
+impacting developer workflows.
+
+ECI automatically runs all containers within a Linux user-namespace, such that
+root in the container is mapped to an unprivileged user inside the Docker
+Desktop VM. ECI uses this and other advanced techniques to further secure
+containers within the Docker Desktop Linux VM, such that they are further
+isolated from the Docker daemon and other services running inside the VM.
 
 ## Windows Containers
 
 Unlike the Linux Docker engine and containers which run in a VM, Windows containers are an operating system feature, and run directly on the Windows host with `Administrator` privileges. For organizations who don't want their developers to run Windows containers, a `–no-windows-containers` installer flag is available from version 4.11 to disable their use.
 
 ## Networking
 
-For network connectivity, Docker Desktop uses a user-space process (`vpnkit`), which inherits constraints like firewall rules, VPN, HTTP proxy properties etc. from the user that launched it.
+For network connectivity, Docker Desktop uses a user-space process (`vpnkit`), which inherits constraints like firewall rules, VPN, HTTP proxy properties etc. from the user that launched it.