Docker on Windows has one big security feature that Docker on Linux does not have: extended isolation with Hyper-V containers. Containers running on Windows Server 2019 use the host's operating system kernel. You can see this when you run a container, and the process inside the container is listed on Task Manager on the host.
On Windows 10, the default behavior is different. With the Windows 1809 update, you can run Windows Server containers with process isolation on Windows 10 by adding the --isolation=process flag to your docker container run commands. You need to specify the isolation level in the command or in the Docker configuration file, because the default on Windows 10 is hyperv.
Containers with their own kernel are called Hyper-V containers. They are implemented with a lightweight virtual machine that provides the server kernel, but this is not a full VM and doesn't have the typical overhead of a VM. Hyper-V containers use normal Docker images and they run in the normal Docker engine in the same way as all containers. They don't show in the Hyper-V management tool because they are not full virtual machines.
Hyper-V containers can also be run on Windows Server using the isolation option. This command runs the IIS image as a Hyper-V container, publishing port 80 to a random port on the host:
docker container run -d -p 80 --isolation=hyperv `
mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
The container behaves in the same way. External users can browse to port 80 on the host and the traffic is handled by the container. On the host, you can run docker container inspect to see the IP address and go to the container directly. Features such as Docker networking, volumes, and swarm mode work in the same way for Hyper-V containers.
The extended isolation of Hyper-V containers offers additional security. There is no shared kernel, so even if a kernel vulnerability allowed the container application to access the host, the host is just a thin VM layer running in its own kernel. There are no other processes or containers running on that kernel, so there is no ability for attackers to compromise other workloads.
Hyper-V containers have additional overheads because of the separate kernels. They typically have a slower startup time, and by default they impose memory and CPU limits, restricting resources at the kernel level that the container can't exceed. In some scenarios, the trade-off is worthwhile. In multi-tenant situations, where you assume zero trust for every workload, extended isolation can be a useful defense.