Encrypted vMotion: VMs verschlüsselt auf andere ESXi-Hosts verschieben

    vMotion von verschlüsselten VMs unter VMware vSphere 6.5Seit vSphere 6.5 las­sen sich virtu­elle Maschinen nicht nur ver­schlüs­selt speichern, sondern so auch live auf andere Hosts migrieren. Obwohl sich diese Funk­tion relativ ein­fach ein­setzen lässt, sollte man ihre Funktions­weise ver­stehen, um unlieb­same Über­raschungen zu vermeiden.

    Zwar wird vMotion-Traffic bei vSphere über einen speziellen VMKernel-Adapter abgewickelt, den man wahlweise durch eine geeignete physische Infrastruktur (separate Switches und dedizierte Uplink-Adapter) oder durch Verwendung von VLANs in einem eigenen Layer-2-Segment und Layer-3-Netzwerk platzieren sollte. vMotion-Traffic ist aber bis einschließlich vSphere 6 nicht verschlüsselt.

    Höhere Sicherheit für erweiterte VM-Migration erforderlich

    Mit der Möglichkeit, vMotion mittels Enhanced vMotion zwischen vCentern bzw. in Multi-Site-Umgebungen oder mit Long Distance vMotion auch zwischen weit entfernten Rechenzentren über das WAN einzusetzen, steigt auch der Bedarf für die Verschlüsselung bei vMotion.

    Das gilt auch für hybride Cloud-Umgebungen (vCloud Air, IBM Softlayer, Oracle/Ravello oder VMware Cloud on AWS), wo Workloads in die Public Cloud gelangen. Die Verschlüsselung gewährleistet dann, dass die migrierten Daten intakt und unverändert auf dem Ziel-Host ankommen.

    Wie Encrypted vMotion arbeitet

    Eine Besonderheit von Encrypted vMotion besteht darin, dass die Ver- und Entschlüsselung auf VM-Ebene erfolgt. Encrypted vMotion verschlüsselt mithin nicht die Netzwerk­verbindung, sondern die virtuelle Maschine. Das vermeidet von vorne herein Probleme bei einer Änderung der Netzwerk­konfiguration oder bei der Zertifikats-Veraltung.

    Für Encrypted vMotion erstellt vCenter (genauer: der vCenter KMS-Client) jeweils zufällige 256-Bit-Schlüssel sowie einen zufälligen 64-Bit-Einmal-Code und übertragt Code und Schlüssel auf den Quell- und Ziel-Host. Das Gastsystem hat keinen Zugriff auf die Schlüssel.

    Der Quell-Host nutzt Schlüssel und Code zur Verschlüsselung der virtuellen Maschine, der Ziel-Host zum Entschlüsseln. Potenzielle Angreifer können den vMotion-Datenstrom aufgrund des zufälligen Einmal-Codes weder auslesen noch manipulieren.

    Verschlüsselte vMotion konfigurieren

    Konfigurieren lässt sich die Verschlüsselung via vMotion jeweils auf VM-Ebene in den Einstellungen der virtuellen Maschine. Hierzu wechselt man im Kontextmenü Einstellungen Bearbeiten zum Tab VM-Optionen und navigiert dort zum Anschnitt Verschlüsselung.

    Verschlüsseltes vMotion wird über die Einstellungen einer VM konfiguriert.

    Im zugehörigen Listenauswahlfeld kann der Nutzer dann zwischen den Einstellungen Deaktiviert, Opportunistisch und Erforderlich wählen. Die Unterschiede erschließen sich, wenn man die zugrundeliegende Funktion verstanden hat.

    Hierbei gilt Folgendes:

    1. Eine virtuelle Maschine, die bereits auf Platte verschlüsselt ist, wird immer per Encrypted vMotion migriert. Die Verschlüsselung In flight lässt sich also nicht deaktivieren, wenn sie At rest bereits besteht. Encrypted vMotion wird sogar dann weiterhin verwendet, wenn der Nutzer die VM-Verschlüsselung später wieder deaktiviert, sofern er nicht die oben erwähnten Migrations­einstellungen ausdrücklich manuell von Erforderlich auf Opportunistisch ändert.
    2. Ist eine VM noch nicht verschlüsselt, kann der Nutzer wahlweise auf die Verschlüsselung bei vMotion verzichten ("Deaktiviert"), die Verschlüsselung aktivieren, sofern der Host mit ESXi 6.5 kompatibel ist ("opportunistisch") oder die Verschlüsselung mit Erforderlich zu erzwingen versuchen. Letzteres wird allerdings scheitern (d. h. vMotion ist dann nicht möglich), wenn der Ziel-Host z. B. nicht auf dem Level 6.5 ist, weil er dann die Verschlüsselung nicht unterstützt.
    3. Storage vMotion unterstützt die Verschlüsselung In flight ebenfalls nur, wenn die dabei verwendete Festplatte bereits At rest verschlüsselt ist.

    Keine Kommentare