Veraltete vShield Plattform durch NSX für vSphere ersetzen

VMware vShield ist Teil der vCloud Networking und Security Suite (vCNS). Die neueste verfügbare Version 5.5 erreichte ihr Supportende (end of general support – EOGS) im September 2016 und wurde durch das Produkt NSX für vSphere ersetzt.

 

Es gibt immer noch viele vShield Installationen in Produktivumgebungen. Hauptsächlich in Kombination mit agentenloser Guest-Introspection und Sicherheitslösungen wie z.B. DeepSecurity von Trendmicro oder MOVE von McAfee. Da mittlerweile viele Kunden über eine Migration zu vSphere 6.5 nachdenken, müssen sie sich auch mit der Tatsache auseinandersetzen, daß vShield ab vSphere 6.5 nicht mehr unterstützt wird. Es ist absolut wichtig, Produktabhängigkeiten zwischen Versionen von vSphere, NSX und Sicherheitslösung zu beachten.

Aus diesem Grund zeige ich unterschiedliche Migrationspfade in diesem Artikel auf.

Vor dem Upgrade

Unbedingt die Product Compatibility Matrix von VMware studieren. So vermeidet man unangenehme Überraschungen schon im Vorfeld.

Im unten dargestellten Beispiel hatten wir eine Umgebung mit ESXi 6.0 U2, geschützt mit vShield 5.5.4 und TrendMicro DeepSecurity 9.6. An dieser Stelle möchte ich noch lobend die sehr übersichtliche und hilfreiche Produktmatrix von TrendMicro hervorheben. Man kann dort sehen, daß vSphere 6.0 U3 das Ende der Fahnenstange für vCNS (vShield) ist. Bevor man also auf eine höhere vSphere Version upgraden kann, muß die Plattform von vShield nach NSX gewechselt werden.

Welche NSX Version ist verwendbar? In der Matrix unten kann man erkennen, daß z.B. NSX 6.3.3 mit allen ESXi Versionen von 6.0 bis 6.5 U1 kompatibel ist. Sie ist außerdem kompatibel mit DeepSecurity 9.6 und 10.0.

 

 

Rettungsanker

Ich kann nur dringend empfehlen, vor der Migration Backups und Snapshots von vCenter, vShield-Manager und DeepSecurity-Manager (DSM) zu erstellen. Nur für den Fall, daß man irgendwo unterwegs auf schwere Probleme stößt (wir hatten das Vergnügen) und ein komplettes Rollback triggern muss.

Migrations-Optionen

Der Gesamtablauf gliedert sich in mehrere aufeinander aufbauende Abschnitte: Plattformwechsel von vShield nach NSX, vSphere Upgrade, Update der Sicherheitslösung (optional).

Im Prinzip hat man zwei Wahlmöglichkeiten für den Wechsel auf NSX:

• Inplace Migration: Installation einen Upgrade-Paketes auf dem vShield-Manager.
• Neuinstallation von NSX: Entfernung aller vShield-Spuren aus dem Cluster und Bereitstellung eines frischen NSX-Managers.

Inplace Migration

Die Inplace Migration von vShield nach NSX hat den Charme, daß man lediglich ein Update-Paket auf den vShield-Manager laden, und “install” klicken muss. Am Ende hat man einen voll funktionalen NSX-Manager mit vCenter Plugin und den gleichen Netzwerk-Einstellungen wie zuvor.  Der Nachteil besteht darin, daß es keine Update Pakete für jede beliebige NSX-Version gibt. Das neueste verfügbare Upgrade Paket ist vShield to NSX 6.2.9. Die NSX-Version 6.2 ist jedoch nahe am Ende ihres Supports (EOGS) und nicht kompatibel mit vSphere 6.5. Das bedeutet, daß man nach der Migration zu NSX noch ein NSX-Update installieren muß, bevor ein vSphere Upgrade möglich ist.

NSX Neuinstallation

Für eine neue Bereitstellung müssen zunächst alle vShield Komponenten aus dem Cluster und der Sicherheitslösung (hier DeepSecurity) entfernt werden. Wir entschieden uns dennoch für diesen Weg, da man so bereits im ersten Schritt genau die NSX Version festlegen kann, welche kompatibel mit beiden vSphere Versionen (6.0 und 6.5)  ist. Ausserdem hat man dann eine frische NSX-Manager Appliance und Altlasten über Bord geworfen. Die Bereitstellung des NSX-Managers ist nicht schwierig.

Deinstallation von vShield Endpoint Service auf ESX Servern

Die ESX Hosts dürfen für diesen Schritt nicht im Wartungsmodus sein. Ein Neustart des Hosts sollte nicht erforderlich sein. Wir konnten dies im laufenden Betrieb tun.

vShield Manager von vCenter trennen

Im vShield Manager zu “Settings and Reports” wechseln und dort auf “Configuration”. Dort die Einstellungen für Lookup-Service und vCenter löschen. Falls eine Eingabe obligatorisch ist, kann man den alten Wert stehen lassen. Das ist kein Problem.

vCenter vom DeepSecurity Manager (DSM) trennen

Dieser Schritt ist optional, aber wir wollten es sauber haben. 😉

vShield Plugin aus vCenter entfernen

Dieses bleibt meist zurück und muss manuell entfernt werden. Dazu folgende Adresse im Browser öffnen:

https://<vCenter FQDN>/mob

Login mit vCenter Administrator Credentials.

Klick auf  content -> extensionManager. Falls die Liste zu lang ist, diese mit “more…” erweitern.

In der Liste nach der Erweiterung “com.vmware.vShieldManager” suchen und anklicken.

Den String unter “key” in die Zwischenablage kopieren (ohne Anführungszeichen).

Im Browser einen Schritt zurück gehen und dort unter “Methods” auf “UnregisterExtension” klicken.

Den Key aus der Zwischenablage ins Wertefeld kopieren und “Invoke Method” klicken.

Damit ist das vShield Plugin entfernt.

Shutdown alter Appliances

An dieser Stelle können vShield-Manager und alte Helper-Appliances (z.B: DeepSecurity DSVA) der Sicherheitslösung heruntergefahren werden.

NSX – Manager Appliance bereitstellen

Der neue NSX-Manager in der gwünschten Version wird als OVA im Cluster bereitgestellt. Bei der Bereitstellung wird man vom Wizard geführt, der die Infrastruktur Parameter erfragt.

Noch ein Kommentar zum Netzwerk: NSX benötigt normalerweise zwingend dvSwitches und verteilte Portgruppen. Wenn man jedoch nur Guest Instospection verwenden möchte, so dürfen auch Standard-vSwitches benutzt werden.

Nach der Bereitstellung den NSX-Manager einschalten und nach Abschluss des Bootvorgangs dessen Management Webseite öffnen.

https://<NSX-Manager-IP>

Login mit admin und den beim Bereitstellen definierten Kennwort.

Zunächst werfen wir einen Blick auf “View Summary”

Hier ist zu prüfen, daß die Dienste vPostgres, RabbitMQ and NSX-Management-Service laufen.

Man gelangt zur Hauptseite über das Home-Icon links oben.

Im nächsten Schritt werden unter “Manage Appliance Settings” noch Syslog-Server und NTP-Server definiert.

Im letzten Schritt verbinden wir NSX-Manager mit vCenter.

Es muss die Adresse für den Lookup-Service und das vCenter eingegeben werden. Hilfe zu den Portnummern findet man im Dialog.

Nach Abschluss der NSX-Manager Konfiguration findet man im Webclient einen neuen Abschnitt “Networking & Security”.

Hosts für Guest Introspection vorbereiten

Wenn Standard vSwitches im Einsatz sind, muß auf den Hosts ein Zusatzschritt durchgeführt werden. Bei Verwendung von dvPortgruppen kann der nächste Schritt übersprungen werden.

Agent-VM Einstellungen auf den Hosts

Im Webclient zu “Hosts & Clusters” navigieren. Den ersten ESX Host markieren und auf der rechten Seite das Register “Manage” anklicken. und darunter auf “Settings” gehen. “Agent VM Settings” wählen und dort den Datenspeicher und die Standard Portgruppe festlegen. Den Vorgang auf allen Hosts wiederholen, die für Guest-Introspection vorbereitet werden sollen.

Guest Introspection Service installieren

Im Webclient auf Home klicken und “Network and Security” auswählen. Auf der linken Seite den Eintrag “Installation” wählen und auf der rechten Seite den Tab “Dienstbereitstellung” wählen.

Auf das grüne Plus klicken und “Guest Introspection” auswählen.

Datacenter und Cluster wählen.

Datenspeicher und dvPortgroup wählen. Wenn Standard Switches und Portgruppen verwendet werden und Agent-VM Einstellungen auf den Hosts definiert wurden (sh. oben), ist “Angegegeben auf dem Host” für Datenspeicher und Netzwerk zu wählen

Die IP Zuteilung kann dynamisch über DHCP, oder mittels IP-Pool erfolgen. Der IP-Pool lässt sich direkt im Wizard erzeugen.

Nach Abschluss des Wizards wird NSX-Manager damit beginnen, Guest-Introspection Appliances auf den Host zu verteilen.

An diesem Punkt liefen wir auf ein schwerwiegendes Problem, welches wir aber mit dem VMware Support eingrenzen und beheben konnten. Die Ursache lag nicht direkt bei NSX, sondern einem beschädigten Konfigurationsfile auf dem vCenter. Dieses verhinderte, dass der Agent-Manager-Dienst (eam-service) starten konnte. Nach der Reparatur des Files ließ sich der Guest-Introspection Dienst problemlos installieren.

Fast am Ziel

Herzlichen Glückwunsch! Wer bis hierhin vorgedrungen ist, der hat vShield erfolgreich durch NSX ersetzt. Je nach eingesetztem Sicherheitsprodukt müssen dort nun noch weitere Anpassungen erfolgen. Ich werde dies in einem weiteren Artikel beschreiben. Im jetzigen Zustand arbeitet der vSphere 6.0 Cluster mit NSX und kann auf vSphere 6.5 aktualisiert werden.

Nach Prüfung der Funktion darf nicht vergessen werden, die Snapshots vom Anfang wieder zu löschen.