Bestehende vSphere Cluster mit TPM Chip nachrüsten

Die zunehmenden Bedrohungen im IT-Sektor und die steigenden Anforderungen an die Systemsicherheit haben dazu geführt, dass viele Unternehmen ihre bestehende Infrastruktur neu überdenken. Für Kunden, die ältere VMware vSphere Cluster betreiben, bietet die Nachrüstung mit TPM 2.0 Chips eine wirkungsvolle Möglichkeit, die Sicherheitsarchitektur zu modernisieren. TPM 2.0 stellt dabei die Basis für eine verbesserte Vertrauenswürdigkeit der Systeme dar, indem es kryptografische Schlüssel sicher speichert und Manipulationen am System frühzeitig erkennt.

Was ist TPM?

Das Trusted Platform Module (TPM) ist ein hardwarebasierter Sicherheitschip, der in Computern und anderen Geräten verbaut wird. Es dient zur sicheren Speicherung von kryptografischen Schlüsseln, zur Authentifizierung und zum Schutz sensibler Daten. TPM unterstützt Sicherheitsfunktionen wie Geräteverschlüsselung, sicheres Booten und die Integritätsprüfung des Systems.

Warum TPM

In meiner Rolle als Datencenter-Architekt und Senior Consultant begegne ich einer Vielzahl unterschiedlicher Kundenumgebungen. Einerseits sind viele dieser Umgebungen fabrikneu und auf dem modernsten Stand, andererseits gibt es auch zahlreiche ältere Cluster, die bereits seit fünf oder mehr Jahren in Betrieb sind. Dies muss nicht zwangsläufig ein Nachteil sein, da diese älteren Cluster oft sehr gut auf die spezifischen Anforderungen der jeweiligen Kunden zugeschnitten sind. Sie weisen keine Leistungsengpässe auf und der Hardware-Support ist gewährleistet. Vor diesem Hintergrund stellt sich die Frage, ob eine Investition in neue Hardware tatsächlich erforderlich ist.

Ein wesentlicher Vorteil moderner Hardware-Sicherheitsmodule ist die Integration von Secure Boot.Diese Technologie gewährleistet, dass beim Systemstart ausschließlich signierte und vertrauenswürdige Software geladen wird. Dadurch wird das Risiko erheblich reduziert, dass Schadsoftware oder unerlaubte Bootloader in den Startprozess eingreifen. Dadurch können Unternehmen nicht nur Angriffe auf Firmware-Ebene besser abwehren, sondern auch sicherstellen, dass alle nachfolgenden Softwarekomponenten aus einer gesicherten und verifizierten Quelle stammen.

In diesem Blogbeitrag beleuchte ich, warum gerade die Nachrüstung mit TPM 2.0 in älteren VMware vSphere Umgebungen ein bedeutender Schritt ist – und wie die Kombination mit Secure Boot einen essenziellen Beitrag zum Schutz moderner IT-Infrastrukturen leistet.

Wir werden sehen, welche Schritte unternommen werden müssen, um bestehende Systeme mit TPM-Chips nachzurüsten ohne Neuinstallation des ESXi Hosts.

„Bestehende vSphere Cluster mit TPM Chip nachrüsten“ weiterlesen

Passwort Richtline bei VMware Linux Appliances einstellen

Über den Sinn von regelmäßigen Passwortwechseln lässt sich lange streiten. Der Zwang, alle x Tage ein neues Kennwort zu vergeben, welches sich vom vorherigen stark unterscheiden muss, halte ich für kontraproduktiv. Aber das ist ein anderes Thema.

Das Szenari, über das ich sprechen möchte, sieht folgendermaßen aus: eine nicht produktive Labor-Umgebung, bei der immer genau dann das Passwort abgelaufen ist, wenn man gerade wichtigeres zu tun hat. Die Appliance xy zeigt mir den virtellen Mittelfinger und nötigt mich zur Eingabe eines neuen Passwortes, das mindestens 5 klingonische Sonderzeichen enthalten muss. Grrr! Dies ist ein nicht-produktives Lab und ich verwende für alle – ja, alle – Dienste und Logins das gleiche Passwort. Es geht um Machbarkeit – nicht Sicherheit.

Bevor das jetzt jemand falsch versteht: 
Ja, im Live-Betrieb wäre das eine sehr dumme Idee.

Password Expiration

Der erste Schritt ist, die Ablaufzeit des Kennworts auf Null (Achtung! nicht bei VCF!) oder einen sehr langen Zeitraum zu setzen. Standardmäßig setze ich hier 9000 Tage ein. Das sind umgerechnet etwa 24 Jahre und 7 Monate. Das sollte reichen 😉

Oftmals lässt sich dieser Wert nicht in der GUI konfigurieren. Dann ist ist die CLI gefragt. Die Einstellung verbirgt sich bei den meisten Linux Varianten in einer Konfigurationsdatei namens login.defs. Wir können auf der shell eine schnelle Abfrage machen.

cat /etc/login.defs | grep PASS

PASS_MAX_DAYS 90
PASS_MIN_DAYS 0
PASS_MIN_LEN 8
PASS_WARN_AGE 7

Voila! PASS_MAX_DAYS ist unsere Passwort Ablaufzeit.

Zur Veränderung müssen wir den vi verwenden, da nur selten andere Editoren in diesen Systemen verfügbar sind. Aber keine Angst vor vi. De ist eigentlich ganz nett. 🙂 Wir öffnen die Konfiguration mit:

vi /etc/login.defs

Jetzt Ruhe bewahren und nur die Taste i (für insert) drücken. Jetzt suchen wir in der Datei die Zeile mit PASS_MAX_DAYS und ändern den Wert auf beispielsweise 9000. Wer möchte, kann auch das Mindestalter PASS_MIN_DAYS auf 0 setzen. Damit kann das Passwort ohne Wartezeit erneut gewechselt werden.

Um unsere Änderung zu speichern drücken wir die ESC-Taste und danach die Taste mit dem Doppelpunkt. Unten links erscheint ein Doppelpunkt und zeigt, dass wir im Command-Modus sind. Wir geben die Zeichen wq (write, quit) und drücken Enter.

Sonderfall NSX-T mit VCF

Die Ablaufzeit der vordenfinierten Konten admin, root und audit unter NSX-T werden auf der Shell des NSX-Mangers mit einem eigenen Kommando gesetzt. Dazu verbindet man sich per SSH mit der Virtual-IP (VIP) des Management Clusters und wird zum aktuellen Master-Knoten weitergeleitet.

Um die Ablaufzeit der drei Konten auf 9000 Tage festzulegen, gibt man folgende drei Befehle ein:

set user admin password-expiration 9000
set user root password-expiration 9000
set user audit password-expiration 9000

In NSX-T Umgebungen ohne VCF dürfen die Ablaufzeiten der Passwörter ganz deaktiviert werden.

Achtung! bei NSX-T in Verbindung mit VCF führt dies aber zu Problemen beim Upgrade. Der Vollständigkeit halber hier die Befehle zur Deaktivierung:

clear user admin password-expiration
clear user root password-expiration
clear user audit password-expiration

Kontrolle

Die Ablaufzeit in NSX-T kann mit folgenden Kommandos abgefragt werden:

get user admin password-expiration
get user root password-expiration
get user audit password-expiration

Passwort History

Normalerweise reichen die obigen Änderungen aus. Wenn wir aber das Ablaufdatum verpasst haben und beim Login ein neues Passwort setzen mussten, dann können wir nicht wieder auf unser altes Passwort zurück wechseln. Das System merkt sich eine definierte Anzahl vergangener Passworte und erlaubt hier kein Recycling. Aber auch das können wir ändern. In vielen Linux Varianten gibt es dafür den daemon für pluggable authentication modules (pam.d). Die Konfiguration liegt unter /etc/pam.d/common-password. Systeme mit root Zugang können statt dessen auch die Konfiguration in /etc/pam.d/system-password haben.

vi /etc/pam.d/system-password

Hier setze ich den Wert remember=0. Damit kann das Wunschpasswort sofort neu gesetzt werden. Als root User genügt auf der shell das Kommando:

passwd

2024 – Zeit, sich von liebgewonnenen Ressourcen bei VMware zu verabschieden

Seit Jahren lehre ich den Studenten in meinen VMware Kursen, sich nur wenige wichtige URLs zu merken.

  • docs.vmware.com
  • configmax.vmware.com
  • VMware HCL
  • core.vmware.com

Nach der Übernahme durch Broadcom ergeben sich hier verständlicherweise Veränderungen. Wir schauen uns an, wohin die einzelnen Informationsquellen gewandert sind und welche noch verfügbar bleiben.

Goodbye Docs – Hello Techdocs

Besucht man heute (Dezember 2024) die Seite von VMware-Docs, so sticht folgene Info ins Auge:

Nach dem 31.12.2024 wird die Seite offline gehen und künfig müssen Informationen über die Broadcom-Techdocs Seite bezogen werden. Hier finden sich nicht nur VMware Informationen, sondern Dokumente zu nahezu allen Produkten, die Broadcom im Portfolio hat. Macht Euch nicht die Mühe, bis zum Buchstaben „V“ zu scrollen. Das ist verschwendete Lebenszeit. Tippt stattdessen den Namen des gesuchten Produkts ein.

PDF Export?

Eine Eigenart, die ich an der bisherigen VMware Dokumentation sehr schätzte, war der angenehm lesbare HTML Fliesstext, die klar strukturierte Gliederung und der optionale Export der Dokumentation als PDF.

Der Fliesstext und die Gliederung ist im Techdocs-Portal zwar vorhanden, jedoch fehlt der Download als PDF. Vielleicht gibt es den Link und ich habe ihn nur noch nicht gefunden. Wenn ihn jemand findet -> bitte eine Info in die Kommentare senden.

Configmax

Der Link zu configmax.vmware.com funktioniert schon gar nicht mehr. Anstatt eines Redirects gibt es nur einen Timeout. Schade.

Die neue Ressource ist erreichbar unter https://configmax.broadcom.com.

Erfreulicherweise sieht diese noch genauso aus wie zuvor – nur die TLD hat sich geändert.

VMware HCL

Der zentrale Anlaufpunkt im Cluster-Design war bisher immer die VMware Host Compatibility List (HCL). Wohin ist diese gewandert? Es ist keine Überraschung, dass diese auch unter die TLD von Broadcom migriert wurde. Die neue URL lautet https://compatibilityguide.broadcom.com

Das Dashboard zur Auswahl der unterschiedlichen Compatibility Guides ist etwas übersichtlicher im Vergleich zur alten HCL. Wir haben auf oberster Ebene eine Schnellauswahl gruppiert nach Anwendungsbereichen.

Was es nicht mehr gibt

Was es sonst (noch) gibt

Wenn es um Design-Guides ging, so war bisger die URL core.vmware.com ein wichtiger Anlaufpunkt. Folgt man der URL, so kommt man auf das VMware Resource Center. Immerhin wurde hier ein Redirect gesetzt. Die Navigation ist etwas umständlich und das Suchfeld nur wenig hilfreich. Es sei denn, man kennt den Namen des gesuchten Dokuments. Die Benamung der Produkte sind auch nicht intuitiv. NSX findet sich beispielsweise unter „Networking by NSX“ und vSAN unter „Storage by vSAN„. Mitunter muss man mit den Produktfiltern und Asset Types spielen, um zum gewünschten Ziel zu kommen.

Mit Freude habe ich festgestellt, dass die URL code.vmware.com weiterhin erreichbar und mit content gefüllt ist. Wir werden sehen, wie lange.

Da die oben genannten Ressourcen sich noch unter der TLD vmware.com befinden, wird es nur eine Frage der Zeit sein, bis diese unter die TLD broadcom.com wandern.

VMware Certified Professional – VMware Cloud Foundation Administrator 2024

Nicht nur ein weiterer Badge im CV, sondern eine Schlüsselrolle mit weitreichenden Auswirkungen.

Bis vor kurzem hatten Mitglieder des VMware vExpert Progamms Zugriff auf ein reichhaltiges Spektrum an VMware Testlizenzen. Somit konnte sichergestellt werden dass diese Spezialisten Praxiserfahrung mit VMware Software erlangen und dieses Wissen in Form von Blogs, Vorträgen oder Video-Tutorials weitergeben konnten.
Dies gilt auch weiterhin, jedoch mit einer Einschränkung:
Das VMware Kernprodukt VMware Cloud Foundation (VCF) ist hiervon ausgenommen.
Um Testlizenzen hierfür zu erhalten, müssen auch vExperts eine Qualifikation zum VMware Certified Professioanl (VCP) für VCF vorweisen können.
Das gleiche gilt für Inhaber der VMUG Adavantage Mitgliedschaft.
Auch hier gibt es künftig VCF Lizenzen nur noch gegen Nachweis der VCP-VCF Zertifizierung (2V0-11.24 oder folgende).
Als VMware Trainer hat es noch eine weitere Implikation. Eine der (vielen) Voraussetzungen, um künftig VCF Kurse lehren zu dürfen ist auch der VCP-VCF.

Um die Grundlagen dafür zu lernen gibt es ein on-demand Training von Broadcom.

Aber nicht nur in Bezug auf Lizenzen ist dieses Training und die Zertifizierung wichtig.
Alle die mit diesem Produkt künftig arbeiten werden, erhalten so Basiskenntnisse über die VCF-Architektur, die Bereitstellung und Day-2-Operations.