Die vSphere Trust Authority (vTA) bestätigt die Vertrauenswürdigkeit von ESXi-Hosts, welche dann kryptografische Operationen ausführen können. Die Infrastruktur besteht aus vTA- und vertrauenswürdigen Clustern sowie einem externen KMIP-Server. Auf den ESXi-Hosts laufen zudem mehrere Dienste für vTA.
Trust Authority-Cluster und die vertrauenswürdigen Cluster werden jeweils in separaten vCenter verwaltet. vCenter selbst fungiert aber im Hinblick auf kryptografische Operationen anders als unter 6.5/6.7 nur noch als eine Art Passthrough für Informationen zur vTA-Konfiguration und zum Trust-Authority-Status.
Die meisten Konfigurations- und -Statusinformationen für vSphere Trust-Authority werden auf den ESXi-Hosts in der ConfigStore-Datenbank gespeichert, einige auch in vCenter-Datenbank. Allerdings verwaltet vCenter im vertrauenswürdigen Cluster die API-Aufrufe der Trust Authority und repliziert sie auf alle seine ESXi-Host.
Wichtig ist zudem, dass vSphere Trust Authority keine neuen Kryptografie-Berechtigungen einführt. Die in Version 6.5 vorhandenen Kryptografie-Berechtigungen und Rollen gelten uneingeschränkt, auch für vTA.
ESXi-Komponenten für Trusted Authority
Jeder ESXi-Host in einer vTA-Infrastruktur führt die Dienste der vSphere Trust Authority aus. Diese sind der Bescheinigungs- bzw. Bestätigungsdienst (attestd) und der Schlüsselanbieterdienst (kmxd). Darüber hinaus ist jeder ESXi-Host mit einem vertrauenswürdigen Infrastrukturagent (kmxa) ausgestattet.
Der Attestierungsdienst überprüft die Software und Hardware des Hosts. Dazu erzeugt er ein signiertes Dokument, das Zusicherungen enthält und den Binär- sowie Konfigurationsstatus der ESXi-Hosts im vertrauenswürdigen Cluster beschreibt.
Zudem bestätigt er den Status der ESXi-Hosts mithilfe eines TPM 2.0-Chips. Dieser misst den Software-Stack sowie die Konfigurationsdaten und meldet sie an den Attestierungsdienst. Letzterer überprüft auch, ob er die Software-Mess-Signatur einem zuvor konfigurierten vertrauenswürdigen TPM-Endorsement-Schlüssel (EK) zuordnen kann, und stellt sicher, dass die Software-Messung mit einem Satz zuvor kompatibler ESXi-Images übereinstimmt.
Schließlich signiert der Dienst ein SAML-Token, das der ESXi-Host erhält, und gibt die Aussagen zur Identität, Gültigkeit und Konfiguration des ESXi-Hosts an.
Da der Attestierungsdienst von sich aus nicht weiß, wem oder was er vertrauen soll, muss der zuständige Trust-Authority-Administrator vorher konfigurieren, welche ESXi-Versionen, welche TPM-Geräteherstellern und (optional) welche spezifischen TPM-Geräten vertrauenswürdig sind.
Der Key Provider-Dienst (kmxd) schließlich bietet ein Verfahren zum Kapseln von Verschlüsselungsschlüsselquellen. Er unterstützt (derzeit) nur KMIP-kompatible Schlüssel-Server und ermöglicht den Zugriff auf die Encryption Keys nur, wenn ein Client einen gültigen Bestätigungsbericht vorlegt.
Dank des neuen Key Provider-Dienstes brauchen vCenter-Server und ESXi-Hosts in vSphere 7 keine KMS-Anmeldeinformationen (Direct Key Management Server) mehr. In vSphere Trust Authority kann ein ESXi-Host einfach auf einen Verschlüsselungsschlüssel zugreifen, indem er sich beim Key Provider-Dienst und nicht mehr wie in vSphere 6.7 bei vCenter authentifiziert.
Damit der Key-Provider-Dienst eine Verbindung zu einem KMS herstellen kann, muss der Administrator ein Vertrauens-Setup konfigurieren. Für die meisten Server, die mit dem Key Management Interoperability Protocol (KMIP) kompatibel sind, erstellt man dieses mittels Client- und Server-Zertifikaten.
Der vertrauenswürdige Infrastrukturagent (kmxa) kommuniziert also mit einem vertrauenswürdigen Key Provider-Dienst und einem Attestierungsdienst. Dabei ruft er die Verschlüsselungsschlüssel vom Dienst für vertrauenswürdige Schlüsselanbieter (kmxd) ab. Diesem Agenten können nur dann Verschlüsselungsschlüssel ausgestellt werden, wenn der ESXi-Host die Bescheinigung besteht.
Wichtig: Der ESXi-Host empfängt keine Verschlüsselungsschlüssel von vCenter Server, wenn der Host einen vertrauenswürdigen Schlüsselanbieter benutzt.
Alle vTA-Dienste werden hinter dem Reverse Proxy und der API-Weiterleitung ausgeführt. Der kmxa kommuniziert zunächst über Port 443 extern mit den Hosts der vSphere Trust Authority. Intern verwendet der attestd den Port 7889, der kmxd den Port 7888 und kmxa den Port 7890.
VM-Verschlüsselung
Die Benutzererfahrung der VM-Verschlüsselung ändert sich nicht, wenn man vSphere 7 mit Trust Authority verwendet. Admins können also VMs nach wie vor verschlüsseln, indem sie eine Speicherrichtlinie zur Verschlüsselung auf die VM anwenden oder der VM ein virtuelles TPM-Gerät hinzufügen oder wenn die VM in einem attestierten Cluster mit vertrauenswürdigen Schlüsselanbieter ausführt wird.
Man kann aber problemlos auch eine Mischung aus einem vertrauenswürdigen Schlüsselanbieter und einem Standardschlüsselanbieter in derselben vSphere-Umgebung verwenden. Bei vSphere 7 kann man in der VM-Zusammenfassung anhand des Symbols den Typ des Schlüsselanbieters erkennen, der für die Verschlüsselung verwendet wird.