Hyper-V 2016: Virtuelle Maschine in eine Shielded VM konvertieren

Der Host Guardian Service in Windows Server 2016 dient dazu, Hyper-V Hosts für inte­ger zu erklären, bevor auf ihnen Shielded VMs laufen und dort­hin mig­riert werden können. Die vir­tu­ellen Maschinen müs­sen ent­sprechend konfi­gu­riert werden, um als Shielded VMs zu gel­ten. Das lässt sich ohne VMM mit Power­Shell erledigen.

Ein Deployment des Host Guardian Service (HGS) samt Guarded Hosts ist Voraussetzung, um die in diesem Blog-Post beschriebene Konfiguration einer geschirmten VM nachzuvollziehen. Die Einrichtung des HGS im Admin-trusted Mode habe ich in diesem Beitrag beschrieben. Sollten Sie mit dem Konzept der Shielded VMs oder der Guarded Fabric noch nicht vertraut sein, dann empfehle ich Ihnen einen Blick in diesen Grundlagenbeitrag.

Konfiguration mit PowerShell und ohne VMM

Microsoft positioniert den Virtual Machine Manager als das bevorzugte Tool, um die Infrastruktur für Shielded VMs aufzubauen. Im Lab beschränke ich mich auf die Schirmung der VMs mit PowerShell unter einem Standalone Host außerhalb der Guarded Fabric.

Dabei werden bereits laufende VMs mit Windows Server 2012 R2, wie sie praktisch im Rechenzentrum vorkommen, zu Shielded VMs konfiguriert. Die vorbereiteten VMs gelangen durch einen Export/Import dann auf die Guarded Hosts. Erwähnens­wert ist außerdem, dass die Attestierung der Hyper-V Hosts hier im AD-trusted Modus passiert.

Meine vorhandene Gen2 VM leistet ihren Dienst auf einem Standalone Hyper-V-Host 2016 (violett) und führt das Gastbetriebs­system Windows Server 2012 R2 inklusive aller Updates aus. Die Guarded Fabric besteht aus zwei Guarded Hosts als S2D-Verbund (gelb) und dem dazugehörigen Active Directory (grün). Dazu kommt der Host Guardian Server (in der zweiten Zeile) samt dediziertem Forest.

Erreichbarkeit des HGS prüfen und Metadaten abgreifen

Bevor die 2012R2-Maschine auf dem Standalone Host geschirmt wird, sollte man kurz verifizieren, ob die Guarded Fabric funktioniert. Guarded Hosts müssen also den Attestierungs­status positiv bescheinigen und um diese Bescheinigung zu erhalten, wird auf den Guarded Hosts folgendes Cmdlet ausgeführt:

Get-HgsClientConfiguration

und sollte das Ergebnis

IsHostGuarded = True
AttestationStatus = Passed

liefern. Zusätzlich kann ein Get-HgsTrace -RunDiagnostics relevante Daten zur Lauffähigkeit der Guarded Fabric analysieren.

Bei diesem Resultat und der Erreichbarkeit des Host Guardian Service muss nun für eine spätere Verarbeitung die metadata.xml exportiert werden.

Dafür kann auf einem der beiden Guarded Host folgendes Cmdlet ausgeführt werden, der URL zum HGS muss entsprechend angepasst werden:

Invoke-WebRequest http://hgs.privatecloud.lab/KeyProtection/service/metadata/2014-07/metadata.xml -OutFile C:\META\HGSGuardian.xml

Die in diesem Fall erstellten Guardian Metadaten sind für die Autorisierung der Fabric-Struktur erforderlich und um unsere Shielded VM zu betreiben. Sie enthalten unter anderem die öffentlichen Schlüssel der HGS Zertifikate zur Verschlüsselung und Signierung. Das XML-File kopiert man nun in ein Verzeichnis auf den Standalone Hyper-V Host, wo es später für den Import mittels PowerShell-Befehl erreichbar sein sollte.

Remote Desktop Protokoll und Schirmung aktivieren

Bevor jetzt die Schirmung samt virtuellem TPM erfolgt, ist es wichtig, Remotedesktop auf dieser Maschine zu aktivieren. Eine Shielded VM auf einem Guarded Host kann nämlich durch den Fabric-Administrator nicht per VMConnect eingesehen und konfiguriert werden.

Nach dem Zulassen von Remote-Verbindungen in die 2012R2-VM wird die Maschine herunter­gefahren, um sie offline zu schirmen. Dafür benötigen wir einen Key Protector, welcher seinerseits einen definierten Owner in Form von lokalen Zertifikaten und einen Guardian (durch den Import der bereits erstellten XML-Datei) braucht. Der Owner (local Guardian) ist wichtig für den Start der VM, sollte der HGS nicht erreichbar sein. Dieser lässt es zu die Shielded VM auf dem lokalen Host zu entschlüsseln. Letztendlich bin ich imstande, die VM meines separat betriebenen Hyper-V Hosts folgendermaßen vorzubereiten:

$VMName = 'VM-02-2012R2' $Owner = New-HgsGuardian -Name 'Owner' -GenerateCertificates $Guardian = Import-HgsGuardian -Path C:\META\HGSGuardian.xml ` -Name 'LabFabric' -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

Den Schalter AllowUntrustedRoot verwende ich hier, da im Labor beim KPS selbstsignierte Zertifikate zum Einsatz kommen. Im letzten Cmdlet erkennt man die Aktivierung des vTPM, damit BitLocker später die VHDX verschlüsseln kann. Um eine encryption-supported VM zu konfigurieren, kann im Set-VMSecurityPolicy der Schalter Shielded von $true auf $false getauscht werden.

Export der Shielded VM und Import im Guardian Cluster

Da die VM nun vorbereitet ist, lässt sie sich über den Hyper-V Manager exportieren. Mit der rechten Maustaste erreicht man das Kontextmenü und führt dort wie gewohnt den Befehl Export aus. Die soeben exportierte VM kann dann auf dem Guarded Host wieder importiert und in meinem Fall hochverfügbar konfiguriert werden.

Der Versuch, nun eine Verbindung mit der geschirmten VM via VMConnect herzustellen, scheitert dann wie erwartet:

Somit kommt uns nun der zuvor konfigurierte Remotedesktop zugute, denn er erlaubt den internen Zugriff über den Gast. Auf diesem Weg können wir nun BitLocker in der Shielded VM aktivieren.

Nachdem das passiert ist und die Laufwerke verschlüsselt sind, migriere ich erfolgreich die VM live von Node A nach Node B. Das testweise Herunter­fahren des HGS-Knoten führt bei der Live Migration zum erwünschten Fehler.