[raesene9]

Microsoft's guidance (last I looked) was that Windows containers (e.g. the non Hyper-V ones) were not a security boundary, only Hyper-V based Windows containers should be considered to provide isolation.

That has the slight clash with the fact that Hyper-V containers are not currently supported under Kubernetes (https://kubernetes.io/docs/setup/production-environment/wind...):)

For more depth on the challenges of securing Process isolation containers with Windows https://googleprojectzero.blogspot.com/2021/04/who-contains-... is a great read.

[OrvalWintermute]

To add to above:

Virtualization & Containerization security depends a great deal on the security of the underlying platform.

Hyper-V can be used on endpoints [1], similar to VMware Workstation.

It can also be installed as a role on top of Windows Server [2], and, used as bootable OS of its own[3] (likely deprecated in the future, so no hyper-v server past server 2019).

Related to this is the type of Windows server install, as it touches on attack surface also [4], but I believe there are constraints for the very small installs.

This matters because attack surface is likely to be, from smallest to largest: hyper-v server < Windows Server < Windows Endpoint

[1] https://docs.microsoft.com/en-us/virtualization/hyper-v-on-w...

[2] https://docs.microsoft.com/en-us/windows-server/virtualizati...

[3] https://www.microsoft.com/en-us/evalcenter/evaluate-hyper-v-...

[4] https://docs.microsoft.com/en-us/previous-versions/windows/d...

[hsbauauvhabzb]

It just changes complexity. The difference between a container on bare metal where the target is an adjacent application (or container image), and a container inside a vm where the target is an adjacent application on the host (or inside a vm/vm+Container) the attack chain includes a container breakout and* a hypervisor breakout, which is harder to do, but probably not beyond highly sophisticated threat actors.