I know the blog title is pretty clickbaity, and for that I sincerely apologise. This is a subject that’s pretty near and dear to my heart though, so I thought I’d dedicate a post to what options we have for protecting the contents of VMs from the fabric on which they run in Hyper-V, Azure, and Azure Stack. I’m particularly passionate about this subject as I’ve worked at hosting providers for the past decade or so, and so protecting and ensuring availability of customer workloads is pretty much my raison d’être.
Before we touch on practical steps we can take today, we need some positional work to set context.
Here is a representation of some of the key places we can deploy workloads, the hardware they live on, their management experience, and the built-in options we have for securing workloads against malicious admins or compromised credentials. You’ll note that there is a hole in there today.
Shielded VMs in Hyper-V 2016 are just awesome – a fantastic way to rigorously protect your VM estate both in single and multi-tenanted environments, and I’ve previously blogged and spoken quite extensively publicly about the benefits you can achieve through this feature, as well as with just about every customer I’ve met with in the last year and a half.
Secure Enclaves in Azure through Azure Confidential Computing are similarly awesome, and achieve many of the same benefits for VMs running in Azure, however architecturally they are completely different from Shielded VMs.
Each of these features is dependent on trust rooted in their hardware – this is critical to each model being able to achieve its goals, trust cannot be with an individual, it must be in the physical hardware.
So then if we look back to our diagram above, we can immediately see the problem we are faced with! Azure Stack has a stated design goal, which I completely agree with, to be consistent with Azure. If a feature is not available in Azure then it won’t be brought into Stack. This is a line in the sand that I stand 100% behind as consistency should absolutely be the key here.
That being the case though, unless Shielded VMs as a feature come to Azure, they won’t be brought forward from Hyper-V 2016 to Azure Stack, and until the Azure Stack hardware can support Azure Confidential Computing’s Secure Enclaves, that feature cannot be brought back from Azure to Stack.
It leaves us in this really weird position where both Hyper-V and Azure are able to provide a higher level of assurance than Azure Stack can for VM workloads, despite Azure Stack inheriting many of the benefits of the Hyper-V 2016 Guarded Fabric that I cover off in this blog. In fact, pretty much everything other than VM Shielding is in there right now.
It’s important to note that the level of assurance provided by VM Shielding and Azure Confidential Computing outstrips anything else in the hypervisor or cloud space, so Azure Stack isn’t in any way behind other parts of the industry, only its peers in Microsoft-land.
Some may question the need to protect VMs from compromised fabric credentials, when Azure Stack is delivered as an appliance which is locked down and makes extensive use of Just in Time and Just Enough Administration to remove admin exposure to the physical hardware and hypervisor. I would pose the same question of Azure though, where Secure Enclaves are provided – assurance isn’t all about protecting against the likely, or the maybe possible, but sometimes the only slightly potentially possible. Assurance is about showing that you will go to the nth degree to protect your customer workloads in any eventuality, as trust once broken can be extremely hard to regain.
So how then can we work around this in the interim, and provide that absolute rigour and assurance offered in both Azure and Hyper-V 2016 to Azure Stack? The answer, it turns out, is quite simple.
Firstly, the option exists to make use of Dell EMC CloudLink SecureVM, an Azure Stack validated solution to enable many of the protections offered by Hyper-V 2016’s VM Shielding feature at the VM level. When combined with the Guarded Fabric infrastructure features which Azure Stack does inherit from Hyper-V, this goes a huge way towards plugging that gap within Azure Stack.
That said, I’ve always been quite vehemently outspoken about the fact that not all VMs should be Shielded in this way by default – this is a technology which exists to protect sensitive workloads, not every workload, as there is both a resource and management overhead associated. Domain Controllers, finance data, HR data, IPR, these are the sorts of workloads which should be appropriately protected, anything which holds the keys to your proverbial kingdom.
This being the case then, such workloads don’t have to reside within the Azure Stack infrastructure itself, they only have to be managed by Azure Stack, and for that we have the WAP Connector for Azure Stack. Shielded workloads can indeed run alongside and be managed by Azure Stack… soon. This is by no means a perfect solution, and while this is in no way a deal breaker for most, and while Dell EMC gallantly step in for now, I sincerely hope that the gap in the image above is filled in natively some day.
This does open up a question for a whole other blog though… What workloads should you run within your Azure Stack environment? One thing has become abundantly clear to me over the last couple of years working deeply in these technologies, Hyper-V 2016 and Azure Stack are deeply symbiotic, and the best architected solutions around Stack will make appropriate use of both to give the best mix of cloud consistency, resiliency, security, performance, and cost possible.