Windows Server 2016 Hyper-V introduces the ability to create a Shielded VM. This new feature leverages the vTPM in a Generation-2 VM. The vTPM enables the use of BitLocker on the boot volume of the VM, to secure the data at rest. Shielded VMs also have many other key characteristics, which make the running VMs much more resilient to malicious administrators and malware.
Shielded VMs run within a guarded fabric, and this is typically comprised of the Host Guardian Service (HGS), this is normally a three-node cluster running the Windows Server 2016 role, and one or more guarded hosts, running Windows Server 2016 Hyper-V. The HGS has two components, and they perform the following functions:
Before you deploy a guarded fabric, you have to decide which type of attestation to use. There are two methods of attestation that can be adopted for a guarded fabric:
- Admin-trusted
- Trusted Platform Module (TPM) trusted
Admin-trusted attestation requires less configuration and is compatible with standard servers. TPM-trusted attestation is more involved: Hyper-V hosts must include both hardware and firmware support for TPM v2.0 and UEFI v2.3.1, and have secure boot at the host layer enabled. However, TPM-trusted attestation offers the strongest possible protection available.
The HGS requires its own Active Directory (AD) forest for security and management purposes or access to an existing bastion AD forest. The AD forest used by the HGS is sensitive, because its administrators have access to the keys that control shielded VMs.
Finally, you need to configure the HGS with two certificates, and these certificates will be used for signing and encryption purposes. There are three possible ways this can be achieved:
- You have your own PKI certificate and a PFX (Personal Information Exchange) file is available
- You have a PKI certificate backed by a Hardware Security Module (HSM)
- You use a self-signed certificate, which is only recommended for test or POC environments
Note
To ensure a successful deployment, you will need to ensure that you have the following prerequisites met:
- You have a dedicated bastion AD forest that is separate from your production AD forest, which can be used to host the HGS.
- You have a standalone non-domain-joined server deployed, which will act as the HGS and will host a replica of the previous dedicated AD forest.
The following steps will show you how to deploy the HGS, using its own newly created Active Directory forest, with Admin-trusted attestation. Ensure the HGS machine is not joined to a domain before performing these steps:
- On the production or fabric AD forest, open an elevated PowerShell command prompt and use the following PowerShell command to create a Global Security Group, which contains all the hosts that you consider secure and will run Shielded VMs:
New-ADGroup -Name 'Guarded Hosts' -SamAccountName 'GuardedHosts' -GroupCategory Security -GroupScope Global - Ensure that your deployed guarded Hyper-V host is a member of the global security group created in step 1, which can be achieved with
Add-AdGroupmember - On the HGS server, open an elevated PowerShell command prompt and use the following PowerShell command to install the HGS role:
Install-WindowsFeature –Name HostGuardianServiceRole –IncludeManagementTools –Restart - After the VM restarts, log in. Then, open an elevated PowerShell command prompt and use the following PowerShell command to deploy the HGS server using its own newly created AD forest:
$adminPassword = ConvertTo-SecureString -AsPlainText 'Password1' –Force Install-HgsServer -HgsDomainName 'hgs.local' -SafeModeAdministratorPassword $adminPassword –Restart
- The next step is to generate and use a self-signed certificate. To do that, after the VM restarts, log in. Then, open an elevated PowerShell command prompt and type the following:
$certificatePassword = ConvertTo-SecureString -AsPlainText 'Password1' –Force - Now create and export the signing certificate by running the following PowerShell commands:
$signingCert = New-SelfSignedCertificate -DnsName "signing.hgs.local" Export-PfxCertificate -Cert $signingCert -Password $certificatePassword -FilePath 'C:signingCert.pfx'
- Next, create and export the encryption certificate by running the following PowerShell commands:
$encryptionCert = New-SelfSignedCertificate -DnsName "encryption.hgs.local" Export-PfxCertificate -Cert $encryptionCert -Password $certificatePassword -FilePath 'C:encryptionCert.pfx'
- Now go ahead and initialize the HGS server with Admin-trusted attestation, open an elevated PowerShell command prompt, and type the following:
Initialize-HGSServer -HgsServiceName 'hgs01' -SigningCertificatePath 'C:signingCert.pfx' -SigningCertificatePassword $certificatePassword -EncryptionCertificatePath 'C:encryptionCert.pfx' -EncryptionCertificatePassword $certificatePassword –TrustActiveDirectory -Force - You need to configure DNS forwarding between the HGS and the production or fabric domain. This then allows for name resolution of resources located in this production or fabric domain:
Add-DnsServerConditionalForwarderZone -Name "demo.local" -ReplicationScope "Forest" -MasterServers 192.168.1.1 - Next you need to configure a one-way forest trust from the HGS domain to the production or fabric domain:
netdom trust hgs.local /domain:demo.local /userD:demo.localAdministrator /passwordD:Password1 /add - Now the guarded hosts needs be able to resolve the HGS cluster. You need to configure a DNS forwarder from the production or fabric domain to the HGS domain. On the production or fabric AD forest, open an elevated PowerShell command prompt and use the following PowerShell command:
Add-DnsServerConditionalForwarderZone -Name "hgs.local" -ReplicationScope "Forest" -MasterServers 192.168.15.1 - Next, on the HGS server, run the following command to register the security group that was created earlier, as an Attestation Host Group:
Add-HgsAttestationHostGroup -Name "<GuardedHostGroup>" –Identitifier "<SID>"To obtain the groups SID, you can use the PowerShell cmdlet,
Get-ADGroup. You will need to add those Hyper-V hosts that you trust to run Shielded VM to this global security group. - Now you can verify that the HGS is configured correctly, and you can do this by running the HGS diagnostic tool
Get-HgsTrace –RunDiagnostics. - At this stage, you can add secondary HGS nodes. In production, additional HGS servers should be set up in a high-availability cluster, and this will ensure that shielded VMs will be able to be powered on in the event that a HGS node fails.
- To add secondary nodes to the HGS cluster that you previously configured, install the HGS role, as described in step 3, by using the
Install-WindowsFeaturePowerShell cmdlet:Install-WindowsFeature –Name HostGuardianServiceRole –IncludeManagementTools –Restart - Ensure that DNS name resolution is functioning from this secondary node, by configuring at least one NIC and ensuring the DNS client is pointing to the DNS server that is running on your first HGS server.
- Next, install the HGS by running the following command in an elevated PowerShell command prompt:
$adSafeModePassword = ConvertTo-SecureString -AsPlainText '<password>' –Force $cred = Get-Credential 'hgsAdministrator' Install-HgsServer -HgsDomainName 'hgs.local' - HgsDomainCredential $cred -SafeModeAdministratorPassword $adSafeModePassword –Restart –Confirm:$false
- Wait for the secondary node to restart, then sign in with the HGS domain with administrator credentials.
- Initialize the HGS by running the following command in an elevated PowerShell command prompt:
$cred = Get-Credential 'hgsAdministrator' Initialize-HgsServer -HgsServerIPAddress <IP address of first HGS Server> -HgsDomainCredential $cred -Confirm:$false
- You can validate that everything is working as expected by running the following command in an elevated PowerShell command prompt:
Get-HGSTrace –RunDiagnostics - Once all your HGS nodes are configured, the next step is to configure the Hyper-V hosts, so that they can communicate with the HGS instance for attestation.
- Install the Host Guardian Hyper-V Support features with the following command:
Install-WindowsFeature HostGuardian –IncludeManagementTools –Restart - Next, configure the host's Key Protection and Attestation URLs by executing the following command in an elevated PowerShell command prompt:
Set-HgsClientConfiguration -AttestationServerUrl 'http://hgs.hgs.local /Attestation' -KeyProtectionServerUrl 'http:// hgs.hgs.local /KeyProtection' - Finally, to initiate an attestation attempt on the Hyper-V host and view the attestation status, run the following command in an elevated PowerShell command prompt:
Get-HgsClientConfiguration
When a user or tenant starts a Shielded VM, the guarded host must first be affirmatively attested to determine it is healthy. To prove its health, the guarded host must present a certificate of health to the Key Protection Service (KPS). The guarded host requests attestation, and the mode used is dictated by the Host Guardian Service.
For admin-trusted attestation, the Windows Server 2016 Hyper-V host sends a Kerberos ticket, which identifies the security groups that the guarded host is in. The HGS validates that the host belongs to a security group that was configured earlier by the trusted HGS admin.
For TPM-trusted attestation, the Windows Server 2016 Hyper-V host sends information that includes:
The attestation service uses the attestation mode to determine which checks should be carried out, for example, group membership or boot measurements, in order to affirmatively attest the host.
On the basis that the attestation was successful, a health certificate is sent to the host, and the host is considered a guarded host and is authorized to run shielded VMs. The host uses the health certificate to authorize the KPS to securely release the keys needed to work with shielded VMs.
Guarded hosts do not have the required keys to be able to power-on a shielded VM. To obtain the necessary keys, the guarded host must provide the following to KPS:
- The current health certificate
- An encrypted secret (a Key Protector) that contains the keys necessary to power on the requested VM. The secret is encrypted using other keys that only the KPS knows.
The KPS examines the health certificate from the guarded host to determine its validity. The certificate must not have expired and KPS must also trust the attestation service that issued the certificate. If the health certificate is valid, KPS attempts to decrypt the secret and securely return the keys needed to power on the VM.
Now that you have completed your deployment and configuration of both the HGS server and the guarded host, you will want to start thinking about shielding virtual machines. There are many scenarios here, and one such example would be shielding an existing VM.
For this example to work, you will need a running VM on a Windows Server 2016 Hyper-V host that is not already a guarded host. This is a great example, as it lets you simulate a scenario where you are a tenant who wants to take an existing unprotected VM and shield that VM before you move it to a guarded host that is operated by either your own IT department or a third-party service provider.
It is important to remember that this VM must be a Generation-2 VM and have a supported operating system installed. You also need to ensure that the remote desktop is enabled within the VM. This is an important point, as it is the only mechanism by which you will be able to connect to the VM. Before going any further, you may want to verify this point and establish an RDP session with your chosen VM.
The first step in shielding an existing VM is to get the HGS guardian metadata from the HGS server and use it to create the Key protector. To do this, run the following command from an elevated PowerShell command prompt, on a guarded host:
Invoke-WebRequest http://hgs01.hgs.local/KeyProtection/service/metadata/2014-07/metadata.xml -OutFile C:HGSGuardian.xml
Now, copy the C:HGSGuardian.xml file to the Windows Server 2016 Hyper-V host. Each shielded VM has a Key Protector, which contains metadata about the owner guardian, and one or more HGS guardians. The next step in the process imports that metadata in order to shield the VM, and enables the VM to be shielded:
$VMName = 'Shield01' Stop-VM –VMName $VMName $Owner = New-HgsGuardian –Name 'Owner' –GenerateCertificates $Guardian = Import-HgsGuardian -Path 'C:HGSGuardian.xml' -Name 'DemoFabric' –AllowUntrustedRoot $KP = New-HgsKeyProtector -Owner $Owner -Guardian $Guardian -AllowUntrustedRoot Set-VMKeyProtector –VMName $VMName –KeyProtector $KP.RawData Set-VMSecurityPolicy -VMName $VMName -Shielded $true Enable-VMTPM -VMName $VMName
Finally, log in to the newly shielded VM and enable BitLocker, before moving it to the guarded host.