This page discusses key concepts and terminology for Shielded VM. To get started using Shielded VM, try the quickstart or see Modifying Shielded VM options.
Shielded VM offers verifiable integrity of your Compute Engine VM instances, so you can be confident your instances haven't been compromised by boot- or kernel-level malware or rootkits.
Shielded VM's verifiable integrity is achieved through the use of the following features:
Secure Boot
Secure Boot helps ensure that the system only runs authentic software by verifying the digital signature of all boot components, and halting the boot process if signature verification fails.
Shielded VM instances run firmware which is signed and verified using Google's Certificate Authority, ensuring that the instance's firmware is unmodified and establishing the root of trust for Secure Boot. The Unified Extensible Firmware Interface (UEFI) 2.3.1 firmware, securely manages the certificates that contain the keys used by the software manufacturers to sign the system firmware, the system boot loader, and any binaries they load. Shielded VM instances use UEFI firmware.
On each boot, the UEFI firmware verifies the digital signature of each boot component against the secure store of approved keys. Any boot component that isn't properly signed, or isn't signed at all, isn't allowed to run.
If this occurs, the VM instance's serial console log will have an entry containing the strings UEFI: Failed to load image and Status: Security Violation, along with a description of the boot option that failed. To troubleshoot the failure, disable Secure Boot by using the instructions in Modifying Shielded VM options so that you can boot the VM instance, diagnose and resolve the issue, then re-enable Secure Boot.
Virtual Trusted Platform Module (vTPM)
A vTPM is a virtualized trusted platform module, which is a specialized computer chip you can use to protect objects, like keys and certificates, that you use to authenticate access to your system. The Shielded VM vTPM is fully compatible with the Trusted Computing Group (TPM) library specification 2.0 and uses the BoringSSL library. The BoringSSL library relies on the BoringCrypto module. For FIPS 140-2 details about to the BoringCrypto module, see NIST Cryptographic Module Validation Program Certificate #3678.
The Shielded VM vTPM enables Measured Boot by performing the measurements needed to create a known good boot baseline, called the integrity policy baseline. The integrity policy baseline is used for comparison with measurements from subsequent VM boots to determine if anything has changed.
You can also use the vTPM to protect secrets through shielding or sealing. See the Go-TPM project on GitHub for Go language examples that illustrate how to use a vTPM for this purpose.
Measured Boot
During Measured Boot, a hash of each component (for example, the firmware, bootloader, or kernel) is created as the component is loaded, and that hash is then concatenated and rehashed with the hashes of any components that have already been loaded, as illustrated here:
This information identifies both the components that were loaded, and their load order.
The first time you boot a VM instance, Measured Boot creates the integrity policy baseline from the first set of these measurements, and securely stores this data. Each time the VM instance boots after that, these measurements are taken again, and stored in secure memory until the next reboot. Having these two sets of measurements enables integrity monitoring, which you can use to determine if there have been changes to a VM instance's boot sequence.
Integrity monitoring
Integrity monitoring helps you understand and make decisions about the state of your VM instances.
Integrity monitoring relies on the measurements created by Measured Boot, which use platform configuration registers (PCRs) to store information about the components and component load order of both the integrity policy baseline (a known good boot sequence), and the most recent boot sequence.
Integrity monitoring compares the most recent boot measurements to the integrity policy baseline and returns a pair of pass/fail results depending on whether they match or not, one for the early boot sequence and one for the late boot sequence. Early boot is the boot sequence from the start of the UEFI firmware until it passes control to the bootloader. Late boot is the boot sequence from the bootloader until it passes control to the operating system kernel. If either part of the most recent boot sequence doesn't match the baseline, you get an integrity validation failure.
If the failure is expected, for example if you applied a system update on that VM instance, you should update the integrity policy baseline. Updating the integrity policy baseline sets the baseline to the measurements captured from the most recent boot sequence. If it is not expected, you should stop that VM instance and investigate the reason for the failure.
You can view integrity reports in Cloud Monitoring, and set alerts on integrity failures. You can review the details of integrity monitoring results in Cloud Logging. For more information, see Monitoring integrity on Shielded VM instances.
Integrity monitoring events
Shielded VM creates log entries for the following types of events:
clearTPMEvent
: Identifies if the vTPM has been cleared, which deletes any secrets stored in it. This doesn't affect any aspect of Shielded VM, so you will only care about this if you use the vTPM to shield sensitive data as described in Virtual Trusted Platform Module (vTPM).earlyBootReportEvent
: Identifies whether the early boot sequence integrity check passed, and provides details on the PCR values from the baseline and the most recent boot sequence that were compared to make that determination.lateBootReportEvent
: Identifies whether the late boot sequence integrity check passed, and provides details on the PCR values from the baseline and the most recent boot sequence that were compared to make that determination.setShieldedInstanceIntegrityPolicy
: Logged each time you update the integrity policy baseline.shutdownEvent
: Logged each time the VM instance is stopped.startupEvent
: Logged each time the VM instance is started. The interesting information in this event is thebootCounter
value, which identifies how many times this instance has been restarted.updateShieldedInstanceConfig
: Logged each time you enable or disable one of the Shielded VM options.
The typical event progression you see in the logs is startupEvent
,
earlyBootReportEvent
, lateBootReportEvent
, and eventually shutdownEvent
,
all with the same bootCounter
value to identify them as describing the same
VM instance boot sequence.
If you update the integrity policy baseline in response to an
expected integrity failure on a VM instance, you will see additional
earlyBootReportEvent
and lateBootReportEvent
events that describe the new
integrity policy baseline measurements. The following example shows the
expected sequence:
startupEvent
earlyBootReportEvent
that compares original baseline to latest boot sequence (passes)lateBootReportEvent
that compares original baseline to latest boot sequence (fails)setShieldedInstanceIntegrityPolicy
when you update the integrity policy baseline, which sets the baseline to the measurements captured from the latest boot sequenceearlyBootReportEvent
that compares new baseline to latest boot sequence (passes)lateBootReportEvent
that compares new baseline to latest boot sequence (passes)
Windows
earlyBootReportEvent
earlyBootReportEvent
contains the following sections and elements:
actualMeasurements
: Contains the platform configuration register (PCR) values for the latest boot sequence. The PCR values are what identify the boot components and component load order used by the latest boot sequence, and are what are compared to the integrity policy baseline (whose values are captured in thepolicyMeasurements
section) to determine if there has been any change in the VM instance boot sequence. The elements of theactualMeasurements
section can vary, based on the OS, distribution, and configuration. The section typically includes the following elements:0
: Contains the value for PCR0, which contains information about firmware components and the memory encryption technology that is active. This PCR diverges from the TCG PCClient platform firmware profile in that it measures only the following events:EV_S_CRTM_VERSION
, the Compute Engine firmware versionEV_NONHOST_INFO
, representing the memory encryption technologyEV_SEPARATOR
, the specified delimiter event firmware measures when it will add no more PCR0 events. This means PCR0 has a static value for the lifetime of a VM. The value only changes for new VMs after major version firmware updates or change in encryption technology. It is not used when validating the latest boot sequence against the integrity policy baseline.
1
: Contains the value for PCR4, which contains information about the UEFI boot manager code and boot attempts.2
: Contains the value for PCR5, which contains information about the disk's GUID partition table. It is not used when validating the latest boot sequence against the integrity policy baseline.3
: Contains the value for PCR7, which contains information about the instance's Secure Boot policy.
policyEvaluationPassed
: Identifies whether the given section of the boot sequence passed verification against the integrity policy baseline.policyMeasurements
: Contains the baseline PCR values that integrity validation uses as expected values. ThepolicyMeasurements
section can vary based on the OS, distribution and configuration, but typically includes the following elements:0
: Contains the value for PCR0, which contains information about firmware components and the memory encryption technology that is active. This PCR diverges from the TCG PCClient platform firmware profile in that it measures only the following events:EV_S_CRTM_VERSION
, the Compute Engine firmware versionEV_NONHOST_INFO
, representing the memory encryption technologyEV_SEPARATOR
, the specified delimiter event firmware measures when it will add no more PCR0 events. This means PCR0 has a static value for the lifetime of a VM. The value only changes for new VMs after major version firmware updates or change in encryption technology. It is not used when validating the latest boot sequence against the integrity policy baseline.
1
: Contains the value for PCR4, which contains information about the UEFI boot manager code and boot attempts. This value is not included in first boot.2
: Contains the value for PCR7, which contains information about the instance's Secure Boot policy.
To learn how to use earlyBootReportEvent
PCR values to diagnose a boot
integrity validation failure, see Determining the cause of boot integrity
validation
failure.
lateBootReportEvent
lateBootReportEvent
contains the following sections and elements:
actualMeasurements
: Contains the platform configuration register (PCR) values for the latest boot sequence. The PCR values are what identify the boot components and component load order used by the latest boot sequence, and are what are compared to the integrity policy baseline (whose values are captured in thepolicyMeasurements
section) to determine if there has been any change in the VM instance boot sequence. The elements of theactualMeasurements
section can vary, based on the OS, distribution, and configuration. The section typically includes the following elements:0
: Contains the value for PCR0, which contains information about firmware components and the memory encryption technology that is active. This PCR diverges from the TCG PCClient platform firmware profile in that it measures only the following events:EV_S_CRTM_VERSION
, the Compute Engine firmware versionEV_NONHOST_INFO
, representing the memory encryption technologyEV_SEPARATOR
, the specified delimiter event firmware measures when it will add no more PCR0 events. This means PCR0 has a static value for the lifetime of a VM. The value only changes for new VMs after major version firmware updates or change in encryption technology. It is not used when validating the latest boot sequence against the integrity policy baseline.
1
: Contains the value for PCR4, which contains information about the UEFI boot manager code and boot attempts.2
: Contains the value for PCR5, which contains information about the disk's GUID partition table. It is not used when validating the latest boot sequence against the integrity policy baseline.3
: Contains the value for PCR7, which contains information about the instance's Secure Boot policy.4
: Contains the value for PCR11, which contains information about BitLocker Drive Encryption access control.5
: Contains the value for PCR12, which contains information about data events. It is not used when validating the latest boot sequence against the integrity policy baseline.6
: Contains the value for PCR13, which contains information about Windows kernel and boot drivers.7
: Contains the value for PCR14, which contains information about Windows boot authorities.
policyEvaluationPassed
: Identifies whether the given section of the boot sequence passed verification against the integrity policy baseline.policyMeasurements
: Contains the baseline PCR values that integrity validation uses as expected values. ThepolicyMeasurements
section can vary based on the OS, distribution and configuration, but typically includes the following elements:0
: Contains the value for PCR0, which contains information about firmware components and the memory encryption technology that is active. This PCR diverges from the TCG PCClient platform firmware profile in that it measures only the following events:EV_S_CRTM_VERSION
, the Compute Engine firmware versionEV_NONHOST_INFO
, representing the memory encryption technologyEV_SEPARATOR
, the specified delimiter event firmware measures when it will add no more PCR0 events. This means PCR0 has a static value for the lifetime of a VM. The value only changes for new VMs after major version firmware updates or change in encryption technology. It is not used when validating the latest boot sequence against the integrity policy baseline.
1
: Contains the value for PCR4, which contains information about the UEFI boot manager code and boot attempts.2
: Contains the value for PCR7, which contains information about the instance's Secure Boot policy.3
: Contains the value for PCR11, which contains information about BitLocker Drive Encryption access control.4
: Contains the value for PCR13, which contains information about Windows kernel and boot drivers.5
: Contains the value for PCR14, which contains information about Windows boot authorities.
To learn how to use lateBootReportEvent
PCR values to diagnose a boot
integrity validation failure, see Determining the cause of boot integrity
validation
failure.
Linux
earlyBootReportEvent
earlyBootReportEvent
contains the following sections and elements:
actualMeasurements
: Contains the platform configuration register (PCR) values for the latest boot sequence. The PCR values are what identify the boot components and component load order used by the latest boot sequence, and are what are compared to the integrity policy baseline (whose values are captured in thepolicyMeasurements
section) to determine if there has been any change in the VM instance boot sequence. The elements of theactualMeasurements
section can vary, based on the OS, distribution, and configuration. The section typically includes the following elements:0
: Contains the value for PCR0, which contains information about firmware components and the memory encryption technology that is active. This PCR diverges from the TCG PCClient platform firmware profile in that it measures only the following events:EV_S_CRTM_VERSION
, the Compute Engine firmware versionEV_NONHOST_INFO
, representing the memory encryption technologyEV_SEPARATOR
, the specified delimiter event firmware measures when it will add no more PCR0 events. This means PCR0 has a static value for the lifetime of a VM. The value only changes for new VMs after major version firmware updates or change in encryption technology. It is not used when validating the latest boot sequence against the integrity policy baseline.
1
: Contains the value for PCR4, which contains information about the operating system shim.2
: Contains the value for PCR7, which contains information about the instance's Secure Boot policy.
policyEvaluationPassed
: Identifies whether the given section of the boot sequence passed verification against the integrity policy baseline.policyMeasurements
: Contains the baseline PCR values that integrity validation uses as expected values. ThepolicyMeasurements
section can vary based on the OS, distribution and configuration, but typically includes the following elements:0
: Contains the value for PCR0, which contains information about firmware components and the memory encryption technology that is active. This PCR diverges from the TCG PCClient platform firmware profile in that it measures only the following events:EV_S_CRTM_VERSION
, the Compute Engine firmware versionEV_NONHOST_INFO
, representing the memory encryption technologyEV_SEPARATOR
, the specified delimiter event firmware measures when it will add no more PCR0 events. This means PCR0 has a static value for the lifetime of a VM. The value only changes for new VMs after major version firmware updates or change in encryption technology. It is not used when validating the latest boot sequence against the integrity policy baseline.
1
: Contains the value for PCR4, which contains information about the operating system shim. This value is not included in first boot.2
: Contains the value for PCR7, which contains information about the instance's Secure Boot policy.
To learn how to use earlyBootReportEvent
PCR values to diagnose a boot
integrity validation failure, see Determining the cause of boot integrity
validation
failure.
lateBootReportEvent
lateBootReportEvent
contains the following sections and elements:
actualMeasurements
: Contains the platform configuration register (PCR) values for the latest boot sequence. The PCR values are what identify the boot components and component load order used by the latest boot sequence, and are what are compared to the integrity policy baseline (whose values are captured in thepolicyMeasurements
section) to determine if there has been any change in the VM instance boot sequence. The elements of theactualMeasurements
section can vary, based on the OS, distribution, and configuration. The section typically includes the following elements:0
: Contains the value for PCR0, which contains information about firmware components and the memory encryption technology that is active. This PCR diverges from the TCG PCClient platform firmware profile in that it measures only the following events:EV_S_CRTM_VERSION
, the Compute Engine firmware versionEV_NONHOST_INFO
, representing the memory encryption technologyEV_SEPARATOR
, the specified delimiter event firmware measures when it will add no more PCR0 events. This means PCR0 has a static value for the lifetime of a VM. The value only changes for new VMs after major version firmware updates or change in encryption technology. It is not used when validating the latest boot sequence against the integrity policy baseline.
1
: Contains the value for PCR4, which contains information about the second stage boot loader and the kernel.2
: Contains the value for PCR5, which contains information about the disk's GUID partition table. It is not used when validating the latest boot sequence against the integrity policy baseline.3
: Contains the value for PCR7, which contains information about the instance's Secure Boot policy.
policyEvaluationPassed
: Identifies whether the given section of the boot sequence passed verification against the integrity policy baseline.policyMeasurements
: Contains the baseline PCR values that integrity validation uses as expected values. ThepolicyMeasurements
section can vary based on the OS, distribution and configuration, but typically includes the following elements:0
: Contains the value for PCR0, which contains information about firmware components and the memory encryption technology that is active. This PCR diverges from the TCG PCClient platform firmware profile in that it measures only the following events:EV_S_CRTM_VERSION
, the Compute Engine firmware versionEV_NONHOST_INFO
, representing the memory encryption technologyEV_SEPARATOR
, the specified delimiter event firmware measures when it will add no more PCR0 events. This means PCR0 has a static value for the lifetime of a VM. The value only changes for new VMs after major version firmware updates or change in encryption technology. It is not used when validating the latest boot sequence against the integrity policy baseline.
1
: Contains the value for PCR4, which contains information about the second stage boot loader and the kernel.2
: Contains the value for PCR7, which contains information about the instance's Secure Boot policy.
To learn how to use lateBootReportEvent
PCR values to diagnose a boot
integrity validation failure, see Determining the cause of boot integrity
validation
failure.
Using BitLocker with Shielded VM images
You can enable BitLocker for Windows boot disks that are part of Shielded VM images. Shielded VM images offer security features such as UEFI-compliant firmware, Secure Boot, vTPM-protected Measured Boot, and integrity monitoring. vTPM and integrity monitoring are enabled by default, and Google recommends enabling Secure Boot if possible.
If you choose to enable BitLocker on a Windows boot disk that is part of a Shielded VM image, we strongly recommend saving the recovery key to a safe location, because if you don't have the recovery key, you can't recover the data.
Take the following into account before enabling BitLocker on a Windows boot disk that is part of a Shielded VM image:
On Shielded VM boot disks, BitLocker uses the vTPM to store the encryption keys, and the vTPM is permanently associated with the VM on which it was created. This means that you can restore a snapshot of a Shielded VM boot disk to another persistent disk, but you can't decrypt it because the vTPM containing the BitLocker keys isn't available. If you have a recovery key, you can recover data by following the instructions in the BitLocker recovery guide. If you don't have a recovery key, the data on the disk is unrecoverable.
On Shielded VM data disks, persistent disk data is encrypted by default. Enabling BitLocker on top of persistent disk encryption doesn't affect throughput, but it might increase vCPU utilization slightly. Enabling BitLocker on data disks that are attached to the VM doesn't pose the same recovery challenges as for boot disks. This is because the BitLocker encryption keys for data disks aren't stored on the vTPM. If you have lost the ability to unlock the disk normally and have the recovery key, you can attach the disk to another unencrypted VM and recover it from there. If you don't have a recovery key, the data on the disk is unrecoverable.
Identity and Access Management authorization
Shielded VM uses IAM for authorization.
Shielded VM operations use the following Compute Engine permissions:
compute.instances.updateShieldedInstanceConfig
: Allows the user to change the Shielded VM options on a VM instance.compute.instances.setShieldedInstanceIntegrityPolicy
: Allows the user to update the integrity policy baseline on a VM instance.compute.instances.getShieldedInstanceIdentity
: Allows the user to retrieve endorsement key information from the vTPM.
Shielded VM permissions are granted to the following Compute Engine roles:
roles/compute.instanceAdmin.v1
roles/compute.securityAdmin
You can also grant Shielded VM permissions to custom roles.
Organization policy constraints for Shielded VM
You can set the constraints/compute.requireShieldedVm
organization policy
constraint
to True
to require that Compute Engine VM instances created in your
organization be Shielded VM instances.
Learn how to set the constraints/compute.requireShieldedVm
constraint in
Using boolean constraints in organization
policy.
You must be an organization policy
administrator
to set a constraint.
Limitations
Shielded VM isn't supported on bare-metal instances.
What's next
- Learn about retrieving the endorsement key from the vTPM.
- Learn about one approach to automating responses to integrity monitoring events.