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

    Shielded VM mit Hyper-V 2016Der 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.

    Lab-Infrastruktur zum Einrichten von Shielded VMs

    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.

    Guarded Fabric überprüfen mit dem Cmdlet Get-HgsClientConfiguration

    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.

    RDP im Gast-OS der künftigen Shielded VM aktivieren

    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:

    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.

    Virtuelle Maschine offline mit PowerShell abschirmen

    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:

    Eine Verbindung via VMConnect lässt sich mit der abgeschirmten VM nicht herstellen.

    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.

    Über die Remotedesktop-Verbindung kann man nun das Laufwerk mit BitLocker verschlüsseln.

    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.

    Keine Kommentare