VMs vs VDI vs Containers

[JGillam]

The core objective of SamuraiWTF is to facilitate the construction of laboratory environments for the purpose of teaching web application security and penetration testing. In the past, this meant the management of a virtual machine (VM) equipped with necessary tools and laboratory targets. Additionally, we've ventured into utilizing virtual desktop infrastructure (VDI) through Amazon Web Services (AWS) Workspaces. However, every solution we've pursued comes with its own unique set of difficulties.

Virtual Machines (VMs)

VMs have presented several issues. The preferred VM solution has evolved over time, with VMWare initially leading the pack, then succeeded by VirtualBox, and more recently, Hyper-V, which has enhanced its desktop environment support. Apple's M-chip series MacBooks introduced a phase during which no VMs seemed to function. Despite the benefits of Vagrant, maintaining a desktop environment (particularly one compatible with VirtualBox, Hyper-V, and VMWare) is a recurring struggle. Moreover, stringent corporate regulations on VMs can add complexities to the setup of such lab environments.

Virtual Desktop Infrastructures (VDIs)

Our journey with VDIs showed promise initially. The process of building them was fairly direct, and we bypassed the issues associated with different hypervisors' support. This was especially beneficial for organizations seeking a lab setup without the red tape associated with VM permissions. However, our AWS Workspaces solution faced disruptions at the start of 2023. We could still establish an environment, but reliably generating an image from it became challenging. We suspect that this may be tied to the virtual network configuration for containers.

Containers

The need for numerous tools in web applications penetration testing has reduced over time, easing the transition towards a container-focused solution. But there are certain obstacles to overcome. For corporate classes and beginner students, ensuring the correct setup and functioning of Docker can be challenging, especially for remote classes. If we decide to establish remote infrastructure, we'll need to implement controls to segregate each student's environment and secure it from external internet access. Bear in mind, a standard long-form class may require the use of 3-5 different applications.

What's the next step?

I envision a specialized form of container orchestration as our solution moving forward. This would involve defining the target labs through the use of containers, which aligns with the trend of most labs already transitioning to a containerized format. The solution should incorporate a hosting provider interface capable of deploying labs remotely (for instance, allowing an instructor to deploy multiple environments for students), with different providers for AWS, Azure, etc. Additionally, there should be a simplified provider for local lab deployments. Here are some additional considerations:

• The solution should be straightforward to maintain and as uncomplicated as possible, hence, a simple container definition (such as docker compose) would be preferable to something complex like Kubernetes.
• Whenever possible, existing and proven solutions should be utilized rather than inventing new ones.
• The solution needs to operate on Windows, OSX, and Linux.
• It should scale efficiently and remain cost-effective in terms of cloud infrastructure.
• The system must allow for lab setup in the cloud, a local environment, or on a local network (for instance, in a class at a conference where internet access may be unreliable).