Anleitung: Host Guardian Service im Admin-trusted Mode installieren

Damit Shielded Virtual Machines auf einem Guarded Hyper-V-Host star­ten können, muss er durch den Host Guardian Service (HGS) als vertrauens­würdig attes­tiert werden. Dieser Dienst arbeitet unter Windows Server 2016 in einem eigens dafür ein­gerich­teten AD-Forest und ver­waltet auch die Keys zum Start der VMs.

Wie ich sie im vorangegangen Beitrag beschrieben habe, lässt sich die Guarded Fabric auf unterschiedliche Arten installieren und initialisieren. Eine Möglichkeit der Attestierung von Hyper-V Hosts beruht auf der deren Mitgliedschaft in einer globalen Sicherheits­gruppe. Dabei spricht man vom Admin-trusted Mode.

Anders als der TPM-trusted Mode lässt sich diese Active Directory-basierte Variante relativ schnell implementieren und kann den ersten Schritt beim Schutz virtueller Maschinen bedeuten, wenn ein TPM 2.0 auf den Hosts noch fehlt. Der Host Guardian Service stellt dabei eine Kernkomponente dar, welche kritisch ist und daher hochverfügbar ausgelegt werden sollte. Diese Anleitung zeigt die Initiali­sierung des HGS jedoch in einem Cluster mit nur einem Knoten, der sich aber bei Bedarf einfach erweitern lässt.

Fahrplan für die Installation

Meine verschachtelte virtuelle Umgebung besteht aus zwei hyper-converged Hosts mit Storage Spaces Direct (S2D), welche als Guarded Hosts später Shielded VMs ausführen sollen. Auf einem benachbarten Server wurden die Active Directory Domain Services (AD DS) installiert und beide On-Premises-S2D-Knoten sind Mitglied in dieser Domäne. Eine solche Umgebung repräsentiert somit unsere Fabric Domain.

Die HGS-Domain wird im Labor auf einem einzigen Knoten installiert. Dabei halte ich auf der virtuellen Maschine mit einem durchgepatchten Windows Server 2016 Standard folgenden Fahrplan ein:

• Ausbringen der HGS-Rolle samt AD DS, Failover-Clustering, IIS und erforderlichen Tools
• Installieren des HGS mit eigenem Forest
• Ausstellen von selbstsignierten Zertifikaten für die Testumgebung
• Initialisierung des HGS im AD-Modus
• Konfiguration von DNS-Forwarder und Vertrauensstellung
• Erstellen der Sicherheits­gruppe in der Fabric Domain und Bekannt­machung beim HGS
• Manuelle HTTP-Konfiguration zwischen Hosts und HGS

Grün: Fabric Domain, Blau: HGS Domain, Gelb: spätere guarded Hosts in der Fabric Domain

Ausbringen der HGS Rolle

Nach Best Practice sollte die Rolle des Host Guardian Service möglichst Bare Metal, hochverfügbar und auf Server Core installiert werden. Um im Lab flexibel zu bleiben, verwende ich aber die Desktop Experience in einer VM, wobei jedoch bei allen Konfigurations­schritten PowerShell zum Einsatz kommt. Der HGS benötigt parallel weitere Rollen, welche automatisch huckepack mit ausgebracht werden:

Install-WindowsFeature -Name HostGuardianServiceRole -IncludeManagementTools

Sobald die Rolle des HGS und die davon abhängigen Rollen wie AD DS, IIS oder das Feature Failover-Clustering installiert wurden, muss der Server neugestartet werden.

Host Guardian Service einrichten

Nach dem Neustart wird der Host Guardian Service isoliert konfiguriert, indem ich jeden Node zum Domänen-Controller heraufstufe. Ein HGS-Server sollte somit zuvor kein Mitglied in einem AD sein.

Das hier verwendete PowerShell-Cmdlet erstellt standardmäßig und empfehlenswert einen neuen HGS-Forest, jedoch können diese Server auch einem bereits bestehenden beitreten. In die Variable schreibe ich das nötige Verzeichnis­dienst­wieder­herstellungs­passwort:

$DSRMPassword = ConvertTo-SecureString -AsPlainText Passwort -Force Install-HgsServer -HgsDomainName hgsdomäne.com -SafeModeAdministratorPassword $DSRMPassword

Auch hier ist nach erfolgreicher Konfiguration ein Neustart erforderlich.

Ausstellen von selbstsignierten Zertifikaten

Zertifikate werden später bei der Initialisierung benötigt und sind für den Key Protection Service (KPS) des HGS erforderlich. Dieser entschlüsselt damit die Keys der Shielded VMs. Kommt eine eigene CA zum Einsatz, dann lassen sich diese zur Signierung und Verschlüsselung genutzten Zertifikate hier ausstellen. In meinem Lab erzeuge ich die Zertifikate und PFX Dateien nach diesem Muster:

$CertPassword = ConvertTo-SecureString -AsPlainText Passwort -Force $SigningCert = New-SelfSignedCertificate -DnsName "sign.hgsdomäne.com" Export-PfxCertificate -Cert $SigningCert -Password $CertPassword -FilePath C:\CERTS\SigningCert.pfx $EncryptionCert = New-SelfSignedCertificate -DnsName "encrypt.hgsdomäne.com" Export-PfxCertificate -Cert $EncryptionCert -Password $CertPassword -FilePath C:\CERTS\EncryptionCert.pfx

Initialisierung des HGS

Die eigentliche Initialisierung findet anschließend statt. Wie schon der Titel des Artikels ankündigt, verwenden wir den Admin-trusted Modus (-TrustActiveDirectory) und gebrauchen die eben ausgestellten Zertifikate im Cmdlet mit der zuvor schon festgelegten Variable für das Passwort:

Initialize-HgsServer -HgsServiceName HGSLAB -SigningCertificatePath C:\CERTS\SigningCert.pfx -SigningCertificatePassword $CertPassword -EncryptionCertificatePath C:\CERTS\EncryptionCert.pfx -EncryptionCertificatePassword $CertPassword -TrustActiveDirectory

Der Schalter für den HgsServiceName legt den HGS-Dienst-Namen fest und verankert das zugehörige Computerobjekt im entsprechenden Forest.

Konfiguration von DNS-Forwarder und Vertrauensstellung

Beim gebundenen AD-Modus ist eine bedingte DNS-Weiterleitung von der HGS-Domäne zur Fabric-Domäne erforderlich, sowie eine One-Way-Vertrauens­stellung zur Fabric-Domäne. Erst danach ist der HGS in der Lage, die Gruppen­mitgliedschaft der Hyper-V-Hosts zu attestieren. Für die Namens­auflösung des HGS in der Fabric wird ein Forwarder so konfiguriert:

Add-DnsServerConditionalForwarderZone -Name "fabric.com" -ReplicationScope Forest -MasterServers <DNSserverIP>

Der ausgehende externe Trust von der HGS-Domäne zur Fabric-Domäne wird wie folgt festgelegt:

netdom trust hgsdomäne.com /domain:fabric.com /userD:fabric.com\Administrator /passwordD:Passwort /add

Erstellen einer Sicherheitsgruppe in der Fabric Domäne

Unsere benötigte globale Sicherheits­gruppe sollte vor Bekannt­machung beim HGS in der Fabric angelegt worden sein. Sie umfasst alle Mitglieder der späteren Guarded Hyper-V-Hosts (siehe Screenshot):

Die SID (Security Identifier) der Gruppe muss dem HGS-Administrator dann zur Verfügung gestellt werden. Daraus resultierend erhält der HGS auf dem entsprechenden Knoten mit folgendem Cmdlet die nötigen Informationen:

Add-HgsAttestationHostGroup -Name "GuardedHostSecGroup" -Identifier "S-1-5-21-2339916985-2111451438-3938192235-1110"

Ein hier festgelegter Name muss nicht mit der globalen Gruppe übereinstimmen. Bevor nun die Konfiguration abgeschlossen und auch validiert werden kann, sollten die URLs zum entfernten KPS und Attestation Service auf den guarded Hosts manuell eingetragen werden, wenn kein VMM zum Einsatz kommt. Nötig wird zuerst auch hier ein conditional Forwarder von der Fabric in die HGS Domäne:

Add-DnsServerConditionalForwarderZone -Name "hgs.com" -ReplicationScope Forest -MasterServers <DNSserverIP>

Set-HgsClientConfiguration -KeyProtectionServerUrl http://hgs.privatecloud.lab/KeyProtection -AttestationServerUrl http://hgs.privatecloud.lab/Attestation

Das Cmdlet Get-HgsClientConfiguration validiert dies auf den Hosts, auf dem HGS-Knoten hingegen kann Get-HgsTrace -RunDiagnostics -Detailed ein betriebs­bereites Gesamt­ergebnis des Host Guardian Service bescheinigen. Shielded VMs dürfen nun erstellt und konfiguriert werden.