6 ms·

Curious to know whether anyone here can speak to how much safer Hyper V isolation[1] is than process isolation and whether it negates some of the concerns in th

by danjc 5y ago

Curious to know whether anyone here can speak to how much safer Hyper V isolation[1] is than process isolation and whether it negates some of the concerns in the article. 1. https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container https://docs.microsoft.com/en-us/virtualization/windowsconta...

invokestatic 5y ago
Virtualization-backed container technologies are a definite security improvement over traditional containers (including Hyper-V), but most of the measures in this article are still important. Remember, security-in-depth. Virtualization mainly protects against zero-day kernel exploits, limiting the "blast radius" to a single container. You still need to monitor dependencies, isolation, signing, scanning, and have a vulnerability management program, among other things.
raesene9 5y ago
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/windows/intro-windows-in-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-containers.html https://googleprojectzero.blogspot.com/2021/04/who-contains-... is a great read.
- OrvalWintermute 5y ago
  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-windows/ https://docs.microsoft.com/en-us/virtualization/hyper-v-on-w... [2] https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/get-started/install-the-hyper-v-role-on-windows-server https://docs.microsoft.com/en-us/windows-server/virtualizati... [3] https://www.microsoft.com/en-us/evalcenter/evaluate-hyper-v-server-2019 https://www.microsoft.com/en-us/evalcenter/evaluate-hyper-v-... [4] https://docs.microsoft.com/en-us/previous-versions/windows/desktop/legacy/mt588479(v=vs.85) https://docs.microsoft.com/en-us/previous-versions/windows/d...
- hsbauauvhabzb 5y ago
  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.

by danjc 5y ago

invokestatic 5y ago

Virtualization-backed container technologies are a definite security improvement over traditional containers (including Hyper-V), but most of the measures in this article are still important. Remember, security-in-depth. Virtualization mainly protects against zero-day kernel exploits, limiting the "blast radius" to a single container. You still need to monitor dependencies, isolation, signing, scanning, and have a vulnerability management program, among other things.

raesene9 5y ago

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/windows/intro-windows-in-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-containers.html https://googleprojectzero.blogspot.com/2021/04/who-contains-... is a great read.

OrvalWintermute 5y ago
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-windows/ https://docs.microsoft.com/en-us/virtualization/hyper-v-on-w... [2] https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/get-started/install-the-hyper-v-role-on-windows-server https://docs.microsoft.com/en-us/windows-server/virtualizati... [3] https://www.microsoft.com/en-us/evalcenter/evaluate-hyper-v-server-2019 https://www.microsoft.com/en-us/evalcenter/evaluate-hyper-v-... [4] https://docs.microsoft.com/en-us/previous-versions/windows/desktop/legacy/mt588479(v=vs.85) https://docs.microsoft.com/en-us/previous-versions/windows/d...
hsbauauvhabzb 5y ago
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.