(bright music)
- 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.
(bright music)