I used to use Qubes for pentesting for quite a while and it worked rather well. As you wrote, one set of netVM-firewallVM-appVM stack per customer to ensure nothing nasty can cross, separate netVMs for separate network zones back at the company, separate color-coded VMs for random web browsing, general office stuff and accessing sensitive data.
The cons: no hardware video acceleration (video conferences or youtube will spin the CPU like it’s 2005), Windows (you can run Windows VMs and they are usable but not nearly as polished as the Linux ones) and hypervisors (there is no nested virtualization so if you want to e.g. hack KVM, you’re out of luck).
Also regarding hardware compatibility: if Qubes runs on something that doesn’t mean it runs securely because it will try to partition the PCI devices across VMs and what can be partitioned where depends on the exact architecture of the mainboard. Expect some deep-dive into the wonderful world of VT-d domains and PCI BARs.
I used to use Qubes for pentesting for quite a while and it worked rather well. As you wrote, one set of netVM-firewallVM-appVM stack per customer to ensure nothing nasty can cross, separate netVMs for separate network zones back at the company, separate color-coded VMs for random web browsing, general office stuff and accessing sensitive data. The cons: no hardware video acceleration (video conferences or youtube will spin the CPU like it’s 2005), Windows (you can run Windows VMs and they are usable but not nearly as polished as the Linux ones) and hypervisors (there is no nested virtualization so if you want to e.g. hack KVM, you’re out of luck). Also regarding hardware compatibility: if Qubes runs on something that doesn’t mean it runs securely because it will try to partition the PCI devices across VMs and what can be partitioned where depends on the exact architecture of the mainboard. Expect some deep-dive into the wonderful world of VT-d domains and PCI BARs.