Azure Confidential Computing - Virtual Machines & Containers

QUICK LINKS: 

00:00 — Introduction 

01:24 — Options for implementing confidential computing 

03:12 — Types of attacks to protect against 

04:00 — Confidential VM protections 

05:56 — How to create Confidential VMs 

08:01 — Container-based architecture advantages 

09:38 — Azure Container Instances 

11:23 — Wrap up

Link References: 

More information on Azure confidential computing at https://aka.ms/AzureCC 

Sign up to preview confidential containers on ACI at https://aka.ms/ConfidentialACI 

Get tools for generating attestation reports at https://aka.ms/CVMAttestation 

Watch our migration series at https://aka.ms/mechanicsazuremigrate 

Unfamiliar with Microsoft Mechanics? 

As Microsoft’s official video series for IT, you can watch and share valuable content and demos of current and upcoming tech from the people who build it at Microsoft. 

• Subscribe to our YouTube: https://www.youtube.com/c/MicrosoftMechanicsSeries?sub_confirmation=1 
• Talk with other IT Pros, join us on the Microsoft Tech Community: https://techcommunity.microsoft.com/t5/microsoft-mechanics-blog/bg-p/MicrosoftMechanicsBlog
• Watch or listen from anywhere, subscribe to our podcast: https://microsoftmechanics.libsyn.com/website
• To get the newest tech for IT in your inbox, subscribe to our newsletter: https://www.getrevue.co/profile/msftmechanics 

Keep getting this insider knowledge, join us on social: 

• Follow us on Twitter: https://twitter.com/MSFTMechanics 
• Share knowledge on LinkedIn: https://www.linkedin.com/company/microsoft-mechanics/ 
• Enjoy us on Instagram: https://www.instagram.com/msftmechanics/
• Loosen up with us on TikTok: https://www.tiktok.com/@msftmechanics 

Video Transcript:

- Up next, we revisit Zero Trust security and confidential computing with a deep dive on the latest silicon level advances, which combined with Azure’s stringent attestation measurements, let you lift and shift your confidential VM and container workloads to the cloud without code changes for higher levels of data protection. Now we’ll show you your options with data encryption and isolation, starting with the virtual machine layer, to containers running in the encrypted VM, and ultimately Azure Container Instances, and how this collectively compares to other options such as encryption using application enclaves. And to walk us through all this, we’re joined today by Michael McReynolds from the Azure confidential computing team in Microsoft. Welcome.

- Really happy to be here. Thanks for having me on the show.

- And thanks so much for joining us today. You know, as a primer for people that are still new to the topic of confidential computing, while we protect your data while it’s in rest in our data centers, and also encrypt it while it’s in transit, confidential computing is really about protecting your highly sensitive data while it’s in use. This is important, because if you’re from a highly regulated industry or have privacy and compliance concerns over your data, or how it’s accessed by apps, processes, or even rogue admins, to solve for this, you know, one approach is to use secure application enclaves at the silicon level, and those protect confidential data and code in your applications, which we covered on our recent show with Intel. And today we want to look at recent innovations that expand your options for implementing confidential computing as you assess moving your workloads to the cloud. So, Michael, can you explain what these options are and how it changes things?

- Sure. This is all about layering additional hardware defenses that protect your data while it’s in the cloud. At the end of the day, we know that even your cloud service provider, whoever it is, shouldn’t be in your trust boundary. So we give you a spectrum of choices to minimize this. On the right of the spectrum, this approach to confidential computing implements an application enclave to protect right down to the line of code. Of course, Intel really blazed the path forward here with Intel SGX. This technology enables you to shrink your trust boundary requiring an attestation before data and code can be processed. To use this, you need to enlighten or containerize your applications. So a lot of people tend to use this approach for new apps. This is so they can define down to the line of code and data that they want the enclaves to protect.

- Okay, so while this is the highest level of protection, there’s a bit more work to do here in this case.

- Exactly. And this is why on the left of the spectrum, we’re investing in ease of use. With this, you can bring your existing VMs and containers with sensitive data into Azure without any code changes, using confidential VMs and containers.

- So compared to application enclaves, you know, this approach to confidential computing, it lets you lift and shift what you already have without any modification, right? So, how does this level of protection then compare versus other options?

- To be clear, everything on this spectrum gives you significant protection. Taking a Zero Trust mindset within the spectrum itself is the best way to think about this. The more code you put inside your trusted computing base, the more exposure that you have. At the end of the day, the VM level encryption will meet the needs for most workloads. That said, you can go even further if you prefer.

- Makes sense. So what types of attacks then are we protecting against? And how does this map to maybe an organization who’s thinking about moving their workloads to the cloud?

- You know, from a Zero Trust perspective, we never want to underestimate the sophistication of attackers. For example, what happens if a platform vulnerability has been discovered, that’s exploited by a bad actor to try copy over data from neighboring VMs on the server? Even though it’s unlikely that an attack like a memory dump could be performed, if a person or process has unchallenged access to a running physical server or VM, we want to protect against the contents being exposed in the clear, which would put the data at risk. And we don’t underestimate that bad actors with enough knowledge to the inner workings of a system may take additional steps to try and cover their tracks by manipulating audit logs.

- Okay, so what kind of protections then do confidential VMs give you for a scenario like this?

- So with confidential VMs, the attack surface has been reduced. That’s because confidential VMs are protected. Even if a bad actor breaches the hypervisor with a zero-day vulnerability, and they attempt to perform a memory dump on the VM, it will only return ciphertext.

- So they can’t read then what’s in the memory of that neighboring VM. But what happens if they get access to memory and try to overwrite the memory of that VM?

- In that case, it will also fail. If they try to corrupt the data in memory and overwrite what’s there, their attempt to write wouldn’t work as only the VM is allowed to write to memory. And from this perspective, confidential VMs really help defend against a broad range of attacks, even cold boot attacks.

- Which, by the way, is something that we covered on a recent show with Intel. In this case, confidential VMs in Azure are available for both the DC and EC series. And these currently use the latest AMD EPYC processors that support Secure Encrypted Virtualization with Secure Nested Paging. That said though, how would an organization using confidential VMs ensure that that VM is secured at the hardware root of trust?

- First off, confidential VMs offer verifiable remote attestation with a third-party hardware root of trust. These VMs protect the OS disk with encryption keys that are bonded with a secure key release policy. Once the conditions of the attestation policy have been met, only then can the encryption keys be released to enable the OS to boot. If any malicious code tries to infect an offline VM disk and boot it, attestation will fail, the keys will not be released, and the VM will not boot. You can control the keys, and we’re investing in alternative integrity methods that allow you to secure the early boot flow.

- And that’s really a lot of control, and it’s on a different level of protection compared to other approaches out there. Of course, the huge benefit is being able to easily leverage these protections by bringing your existing apps to confidential VMs without any code changes.

- That’s right. In fact, let me show you how easy it is to create a confidential VM. I’ll do this right from the Azure portal. You can also script this to use Azure CLI, ARM templates, or other tools, too. I’ll create a VM. From the virtual machine blade, I filled in the standard fields for name, resource group, and then I’ve selected here the “confidential VM” security type. To find an image like this one, it’s best to filter security type on “confidential” in the gallery. Here I can choose from either the DC or the EC series VMs. There are all sizes that you can choose from based on the performance level that you need. I’ll pick this one. In this case, I’ll also create a new SSH keypair. Then I’ll navigate to Disks, where we recommend that you check the confidential compute disk encryption box. I can configure my key management choices, but I will keep with the platform managed key as default. And that’s it. In a couple of minutes, I’ll have a VM where my data is protected in use. And from that, you can also run an attestation report to help ensure that this is a genuine, confidential VM. In fact, here’s the JSON Web Token that it returns. And here’s what it looks like after it’s been decrypted. And by the way, in GitHub, we’ve open sourced this tool for generating attestation reports in the VM at aka.ms/CVMAttestation.

- So now you’ve got your confidential VM running. And from there, you can actually start to migrate your applications into the VM. And that’s something that we’ve covered extensively in our migration series at aka.ms/mechanicsazuremigrate. So I’ve got to ask though, does the encryption actually affect the performance of that VM?

- Well, this additional encryption does come with some added performance tax. However, with the first generation of confidential VMs, overheads are minimal, and we expect to further improve this over time.

- So the encrypted VMs are going to add a lot of protection then for apps that are running in virtual machines, but more and more organizations are opting for cloud-native container-based architectures. So are there any protections with those more modern architectures?

- Great point. There’s so many advantages to container-based architectures. AKS is actually the first Kubernetes-based cloud service to support confidential VM node pools. These enable straight lift and shift migration of your existing container workloads, and they effectively leverage the same technology used with our confidential VMs, with one exception: the encryption on the node pool VMs running AKS extend the memory protection directly to the containers. So without needing to re-code your apps, you get the same hardened security profile, and it’s also pretty straightforward to deploy. Let me show you. From the Kubernetes blade in Azure portal, I’ll start by creating a new cluster. Again, I’ve already filled in some of the standard fields. Where you can opt to make this confidential is with the node size control. So I’ll change the size. I’m showing DC here, but EC is also available. And here you can see all the different options. I’ll choose this option again. And when I click into the node pools config, you’ll see the at-rest encryption type. And as you know, confidential computing extends encryption to also protect this while it’s in use. Next, I’ll go through the normal steps to configure the node pools. And I’ll save time by leaving the rest of the defaults as is and go straight to review and create. And that’s going to build my AKS cluster running on confidential VM nodes. And of course, you can run the same type of attestation report that we saw before.

- And that’s one of those details that often gets overlooked, is that the containers themselves in AKS ultimately run on VMs that you need to provision.

- Right. So in that case, you inherit the protections of the confidential VMs. But let me show you another option with Azure Container Instances. This lets you use containers without having to provision the underlying virtual machine infrastructure, as that is all taken care of by the Azure service. The good news is that even with ACI, you can still get the protections of confidential computing. The memory encryption in this case is running at the container group level and it provides an even tighter trust boundary. And of course, with the benefits of containers, you’re also running less code. Let me show you how easy it is to deploy a confidential container instance using a JSON template. So here I’m in Visual Studio Code. To provision ACI containers, you’ll need to add “confidential compute properties.” For “isolationType,” you can see I have “SevSnp” defined. And the “ccePolicy,” in this case, I’m using a general purpose string, although you can create your own custom policy. Jumping back over to Azure portal, I can see that my container instance is there and it’s running. The container I just deployed is running an image that fetches a hardware attestation report from the CPU. So even though this is a Hello World app, and I’ve reached it using my IP and port, in this case, it’s showing me the SEV-SNP Attestation Report with a measurement, host data, chip ID, and a signature. These properties can then be validated using Azure Attestation or a third party service. Everything is encrypted in my container instance, and we’ve done all the work to let you run the attestation without creating any custom code for that. And to explain a little bit more about what’s going on under the covers, every container group deployed to confidential containers on ACI will get its own trusted execution environment with a memory encryption key generated by the hardware to give you even more isolation.

- And it’s really great seeing all the flexibility that you have for different architectures, and also how you can just bring your own virtual machines and containers into confidential compute in addition to the options that we’ve shown before using Intel SGX. Now, for anyone who is watching right now, looking to bring their apps and VMs and containers into Azure confidential computing, what do you recommend?

- So to be clear, for the majority of workloads that you’re going to bring into Azure, standard compute options are going to be just fine. But if you’re in a highly regulated industry or you have privacy and compliance requirements over your data, how it’s accessed by apps, processes, or you even have concerns about rogue admins, Azure confidential computing can help unblock your path to cloud. And to learn more, you can check out aka.ms/AzureCC. Also confidential VMs and confidential VM node pools in AKS are now generally available and accessible from the Azure portal. And we just released the preview of confidential containers on ACI at aka.ms/ConfidentialACI.

- Thanks so much for joining us today, Michael, and showing us everything that’s new and all your options for Azure confidential computing. Of course, keep checking back to Microsoft Mechanics for all the latest tech updates, and subscribe to our channel if you haven’t already. And as always, thank you for watching.