MAX SALTONSTALL: Hi, I'm Max Saltonstall,
and today I'm going to talk through some simple things you
can do to secure your workloads and sensitive data
in the cloud, while still keeping it private.
We're going to talk about how shielded
VMs and confidential VMs can help you do this.
Let's start with creating a shielded VM in the Google Cloud
console.
Shielded VMs are virtual machine instances
that are hardened with a set of easily configurable security
features to ensure that when your VM boots,
it's running a verified bootloader and kernel.
Using shielded VMs helps protect workloads
from threats, like remote attacks, privilege escalation,
and malicious insiders.
And yes, everything we do here could also
be done through G Cloud and the command line.
Starting at Compute Engine, to to VM instances
and then Create.
Give it a name, then go down to Boot Disk and click Change.
Choose any image.
They're all shielded by default. Close that window with Select
at the bottom, and then go down to the tabs labeled
Management security disks, et cetera, and click Security.
You can see the default shielded VM settings.
Let's enable Secure Boot here for extra protection,
and then click Create to spin it up.
Turning on Secure Boot gives us added protection
from boot and kernel level malware.
Once it's ready, click on the new VM
and click on Stackdriver Logging under Logs on the Detail page.
At the Logs page, you can filter for just VM integrity logs
by clicking on the All Logs dropdown,
and choosing shielded underscore VM underscore integrity.
Now you can see just the shielded VM
offense for this instance.
Let's dig in further.
Click into the log for Early Boot Report Event.
Then expand the JSON payload, then the Early Boot Report
Event inside that.
You can confirm the VM's integrity state
from the early boot perspective from the line showing
policy evaluation past is true.
Early Boot encompasses firmware and other drivers
loaded during the boot process of the VM.
Back to the logs list, open up the log that
starts with boot counter, then expand JSON payload,
then Late Boot Report Event shows
you details about the integrity of the rest of your kernel
drivers.
Once again, you can confirm the boot integrity of the VM
from the line Policy Evaluation Past being true.
That shows that the VM passed all late boot checks,
and is running what we expect it to be running, no shenanigans.
Now head into Cloud Shell to disable Secure Boot so we
can test this integrity check.
Uh-oh.
First, stop the VM with G Cloud.
Next, disable Secure Boot using G Cloud Update.
Now restart the VM, and you can see in the console
that the integrity verification has failed by examining
the same logs as before.
Finally, make a new integrity baseline with G Cloud
so you can compare future measurements
against the current state.
Pretend that you already triaged this failure,
and consider it acceptable.
With this new baseline established,
go check the integrity state of the shielded VM
again in Stackdriver Logging.
Make sure you click Load Newer Logs to get the latest results.
Looking at the late boot report event again,
we can see that the policy evaluation passed is true
once again, showing that we have met our integrity
standards, the ones we just lowered, of course.
Finally, time to look at these metrics over time
via monitoring.
Open up monitoring, and head to Metrics Explorer.
Under Find resource, type, and metric,
choose the resource GCE VM Instance and the metric Early
Boot validation.
Then add a second metric, Late Boot validation.
We've got our graph, though it's going to make more
sense as a stacked bar graph.
Looks great.
Now you can keep track of your integrity
over time with gorgeous colors.
When our customers are ready to move their workloads
to the cloud, one of the biggest challenges
is securely processing sensitive data in the cloud
while keeping it private.
Google Cloud offers solutions to securely bring sensitive data
to the cloud, using encryption to protect data
in transit for offline or online ingestion.
But when we have to actually use the data,
it's much tougher to keep it encrypted.
With confidential computing now in beta,
Google Cloud lets you take data security
a step further by encrypting data
while it's being processed in a Google data center.
Confidential computing environments
can now enable encrypted data to be
processed in memory without exposing it
to the rest of the system.
And this can be done without the need
to make any changes in your workload or code.
Let's take a look at the product by making
a new confidential computing VM which contains a shielded
VM to perform the computation.
Inside Compute Engine, create a new VM instance.
Enable Confidential Computing service with a checkbox.
Note what changes are being made to your VMs with this setting,
then click Enable.
You can run any workload you want.
Your VM is now much safer and more
secure with all of the memory encrypted,
so your data is safe in use.
But what about instance templates and groups,
you might ask?
Well, we've got you covered.
The same confidential computing option
is available for instance templates,
and you can either use one of our premade images
or your own custom image that best fits your workload.
Now my template defines a shielded confidential VM setup,
and I can go to instance groups to make a managed instance
group with that template.
Beep, bop, boop, we're done, with a set of instances auto
scaling for my needs, secure and ready to work.
Confidential computing environments
can now enable encrypted data to be
processed in memory without exposing it
to the rest of the system.
And this can be done without the need
to make any changes in your applications.
Thanks for joining me today.
Enjoy shielded VMs and confidential computing
for your workloads on cloud, and check out the link below
to get started.
[MUSIC PLAYING]