Guarded fabric and shielded VMs overview

Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016

Virtualization security is a major investment area in Hyper-V. In addition to protecting hosts or other virtual machines from a virtual machine running malicious software, we also need to protect virtual machines from a compromised host. This is a fundamental danger for every virtualization platform today, whether it's Hyper-V, VMware or any other. If a virtual machine gets out of an organization (either maliciously or accidentally), that virtual machine can be run on any other system. Protecting high value assets in your organization, such as domain controllers, sensitive file servers, and HR systems, is a top priority.

To help protect against compromised virtualization fabric, Windows Server 2016 Hyper-V introduced shielded VMs. A shielded VM is a generation 2 VM (supported on Windows Server 2012 and later) that has a virtual TPM, is encrypted using BitLocker, and can run only on healthy and approved hosts in the fabric. Shielded VMs and guarded fabric enable cloud service providers or enterprise private cloud administrators to provide a more secure environment for tenant VMs.

A guarded fabric consists of:

• 1 Host Guardian Service (HGS) (typically, a cluster of 3 nodes).
• 1 or more guarded hosts.
• A set of shielded virtual machines. The diagram below shows how the Host Guardian Service uses attestation to ensure that only known, valid hosts can start the shielded VMs, and key protection to securely release the keys for shielded VMs.

When a tenant creates shielded VMs that run on a guarded fabric, the Hyper-V hosts and the shielded VMs themselves are protected by the HGS. The HGS provides two distinct services: attestation and key protection. The Attestation service ensures only trusted Hyper-V hosts can run shielded VMs while the Key Protection Service provides the keys necessary to power them on and to live migrate them to other guarded hosts.

To learn more, see this video on Introduction to shielded virtual machines.

Attestation modes in the Guarded Fabric solution

The HGS supports different attestation modes for a guarded fabric:

• TPM-trusted attestation (hardware-based)
• Host key attestation (based on asymmetric key pairs)

TPM-trusted attestation is recommended because it offers stronger assurances, as explained in the following table, but it requires that your Hyper-V hosts have TPM 2.0. If you currently don't have TPM 2.0 or any TPM, you can use host key attestation. If you decide to move to TPM-trusted attestation when you acquire new hardware, you can switch the attestation mode on the Host Guardian Service with little or no interruption to your fabric.

Another mode named Admin-trusted attestation is deprecated beginning with Windows Server 2019. This mode was based on guarded host membership in a designated Active Directory Domain Services (AD DS) security group. Host key attestation provides similar host identification and is easier to set up.

Assurances provided by the Host Guardian Service

HGS, together with the methods for creating shielded VMs, help provide the following assurances.

What is shielding data and why is it necessary?

A shielding data file (also called a provisioning data file or PDK file) is an encrypted file that a tenant or VM owner creates to protect important VM configuration information, such as the administrator password, RDP and other identity-related certificates, domain-join credentials, and so on. A fabric administrator uses the shielding data file when creating a shielded VM, but is unable to view or use the information contained in the file.

Among others, shielding data files contain secrets such as:

• Administrator credentials
• An answer file (unattend.xml)
• A security policy that determines whether VMs created using this shielding data are configured as shielded or encryption supported
  • Remember, VMs configured as shielded are protected from fabric admins whereas encryption supported VMs aren't
• An RDP certificate to secure remote desktop communication with the VM
• A volume signature catalog that contains a list of trusted, signed template-disk signatures that a new VM is allowed to be created from
• A Key Protector (or KP) that defines which guarded fabrics a shielded VM is authorized to run on

The shielding data file (PDK file) provides assurances that the VM will be created in the way the tenant intended. For example, when the tenant places an answer file (unattend.xml) in the shielding data file and delivers it to the hosting provider, the hosting provider can't view or make changes to that answer file. Similarly, the hosting provider can't substitute a different VHDX when creating the shielded VM, because the shielding data file contains the signatures of the trusted disks that shielded VMs can be created from.

The following figure shows the shielding data file and related configuration elements.

What are the types of virtual machines that a guarded fabric can run?

Guarded fabrics are capable of running VMs in one of three possible ways:

1. A normal VM offering no protections above and beyond previous versions of Hyper-V
2. An encryption-supported VM whose protections can be configured by a fabric admin
3. A shielded VM whose protections are all switched on and can't be disabled by a fabric admin

Encryption-supported VMs are intended for use where the fabric administrators are fully trusted. For example, an enterprise might deploy a guarded fabric in order to ensure VM disks are encrypted at-rest for compliance purposes. Fabric administrators can continue to use convenient management features, such VM console connections, PowerShell Direct, and other day-to-day management and troubleshooting tools.

Shielded VMs are intended for use in fabrics where the data and state of the VM must be protected from both fabric administrators and untrusted software that might be running on the Hyper-V hosts. For example, shielded VMs will never permit a VM console connection whereas a fabric administrator can turn this protection on or off for encryption supported VMs.

The following table summarizes the differences between encryption-supported and shielded VMs.

¹ Traditional debuggers that attach directly to a process, such as WinDbg.exe, are blocked for shielded VMs because the VM's worker process (VMWP.exe) is a protected process light (PPL). Alternative debugging techniques, such as those used by LiveKd.exe, aren't blocked. Unlike shielded VMs, the worker process for encryption supported VMs doesn't run as a PPL so traditional debuggers, such as WinDbg.exe, will continue to function normally.

Both shielded VMs and encryption-supported VMs continue to support commonplace fabric management capabilities, such as Live Migration, Hyper-V replica, VM checkpoints, and so on.

The Host Guardian Service in action: How a shielded VM is powered on

1. VM01 is powered on. Before a guarded host can power on a shielded VM, it must first be affirmatively attested that it's healthy. To prove it's healthy, it must present a certificate of health to the Key Protection service (KPS). The certificate of health is obtained through the attestation process.

2. Host requests attestation. The guarded host requests attestation. The mode of attestation is dictated by the Host Guardian Service:

   • TPM-trusted attestation: Hyper-V host sends information that includes:

     • TPM-identifying information (its endorsement key)

     • Information about processes that were started during the most recent boot sequence (the TCG log)

     • Information about the Code Integrity (CI) policy that was applied on the host.

       Attestation happens when the host starts and every 8 hours thereafter. If for some reason a host doesn't have an attestation certificate when a VM tries to start, this also triggers attestation.

   • Host key attestation: Hyper-V host sends the public half of the key pair. HGS validates the host key is registered.

   • Admin-trusted attestation: Hyper-V host sends a Kerberos ticket, which identifies the security groups that the host is in. HGS validates that the host belongs to a security group that was configured earlier by the trusted HGS admin.

3. Attestation succeeds (or fails). The attestation mode determines which checks are needed to successfully attest the host is healthy. With TPM-trusted attestation, the host's TPM identity, boot measurements, and code integrity policy are validated. With host key attestation, only registration of the host key is validated.

4. Attestation certificate sent to host. Assuming attestation was successful, a health certificate is sent to the host and the host is considered "guarded" (authorized to run shielded VMs). The host uses the health certificate to authorize the Key Protection Service to securely release the keys needed to work with shielded VMs

5. Host requests VM key. Guarded host does not have the keys needed to power on a shielded VM (VM01 in this case). To obtain the necessary keys, the guarded host must provide the following to KPS:

   • The current health certificate
   • An encrypted secret (a Key Protector or KP) that contains the keys necessary to power on VM01. The secret is encrypted using other keys that only KPS knows.

6. Release of key. KPS examines the health certificate to determine its validity. The certificate must not have expired and KPS must trust the attestation service that issued it.

7. Key is returned to host. If the health certificate is valid, KPS attempts to decrypt the secret, and securely return the keys needed to power on the VM. The keys are encrypted to the guarded host's VBS.

8. Host powers on VM01.

Guarded fabric and shielded VM glossary

Additional References

• Guarded fabric and shielded VMs
• Blog: Datacenter and Private Cloud Security Blog
• Video: Introduction to Shielded Virtual Machines
• Video: Dive into Shielded VMs with Windows Server 2016 Hyper-V