This document describes the security-related aspects of the Hyper-V implementation in Docker Desktop.
On Windows the Docker Desktop Service listens on a named pipe //./pipe/dockerBackendV2
. The developer runs the Docker Desktop application, which connects to the named pipe and sends commands to the service.
This named pipe is protected, and only users that are part of the docker-users group can have access to it. It provides a very minimal subset of Hyper-V commands like create/start/stop/destroy DockerDesktopVM. The VM name is hard coded in the service code, so the user cannot create or manipulate any other VM.
The only parameters that can be configured through those APIs are number of CPUs, allocated memory size, and the disk location (disallowing non-sensible system locations).
The Docker Desktop VM is a minimal, special-purpose VM. It is immutable, meaning that users can’t extend it or change the installed software. Even if a user runs a privileged container, they will not be able to alter the VM, let alone escape from the VM to change anything on the host.
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.
Similarly, file sharing (bind mount from the host filesystem) uses a user-space crafted file server (running in com.docker.backend), so the VM can’t access any files other than those the user already has access to.