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

ESXi Config-Backup mit PowerCLI benötigt HTTP

Es gibt einen wirklich nützlichen und komfortablen PowerCLI One-Liner zur Sicherung der Hostkonfiguration. Ich verwende ihn seit Jahren und hatte diesen auch in einem alten Blogpost im Detail erklärt.

Get-Cluster -Name myCluster | Get-VMHost | Get-VMHostFirmware -BackupConfiguration -DestinationPath 'C:\myPath'

Im Rahmen meiner VMware Kurse ist dies ein Befehl, den ich meinen Studenten immer mit auf den Weg gebe. Die Sicherung der Host-Konfiguration ist geradezu Pflicht vor Änderungen am Host, Installation von Patches und Treibern, oder Host-Updates. Nur ein paar Sekunden mehr Aufwand, aber diese Konfigurations-Backups haben mir schon mehr als einmal größeren Ärger und viele Stunden Arbeit erspart.

Kürzlich war ich in einem größeren Datacenter mit der Sicherung der Host-Konfigurationen beschäftigt. Überraschenderweise funktionierte der Befehl auf einigen der vCenter-Instanzen nicht und brach mit einer Fehlermeldung ab.

Get-VMHostFirmware : 18.08.2023 12:05:49 Get-VMHostFirmware An error occurred while sending the request.
At line:1 char:28
+… et-VMHost | Get-VMHostFirmware -BackupConfiguration -DestinationPath …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Get-VMHostFirmware], ViError
+ FullyQualifiedErrorId : Client20_SystemManagementServiceImpl_BackupVmHostFirmware_DownloadError,VMware.VimAutomation.ViCore.Cmdlets.Commands.Host.GetVMHostFirmware

Um den Fehler zu verstehen muss man zunächst verstehen, wie das PowerCLI Kommando arbeitet. Zunächst wird über vCenter auf dem Host ein Backup der Host-Konfiguration getriggert. Diese legt der Host lokal als gezipptes TAR Archiv (.tgz) ab. Der Name lautet configBundle-HostFQDN.tgz (Beispiel: configBundle-esx01.lab.local.tgz). Das Archiv wird dann in einem zweiten Schritt vom Host geladen. Die URL hierfür lautet:

http://[HostFQDN]/downloads/[Host-UUID]/configBundle-HostFQDN.tgz

Liest man die obige Fehlermeldung, gab es ganz offensichtlich ein Problem beim Download des TGZ-Files. Mit Hilfe der Netzwerk Admins wurde schnell klar, was hier passierte. Meine Arbeitsstation, von der ich den PowerCLI Befehl absendete, versuchte erfolglos eine HTTP Verbindung zum ESXi-Host aufzubauen. Dies wurde jedoch durch eine Firewall Regel geblockt.

Ich fragte mich, warum der Transfer über unverschlüsseltes HTTP abgewickelt wird. Im Log der Firewall sieht man einen Verbindungsversuch zum ESXi-Host mit HTTP und HTTPS.

Gibt es eine Möglichkeit, den Transfer über HTTPS zu erzwingen?

Der erste Gedanke war, dass es vielleicht einen Parameter zum Kommando gibt, der das HTTPS Protokoll erzwingt. Eine Anfrage im VMTN-Forum brachte leider Ernüchterung.

Es ist etwas erstaunlich, dass VMware für diese durchaus sensitiven Daten ein unverschlüsseltes Protokoll verwendet. Umso mehr da die PowerCLI Session zum vCenter ohnehin schon über HTTPS läuft. Die plausibelste Erklärung wäre, dass schlicht ‚vergessen‘ wurde bei diesem doch recht alten Befehl, den Transfer über SSL abzusichern.

Es bleibt derzeit also keine andere Wahl, als eine Firewall-Regel zu erzeugen, die den Download über HTTP erlaubt.

Tanzu K8s mit Runecast überwachen

Die Konformität eines Clusters in Bezug auf Sicherheit oder versteckte Probleme zu überprüfen gehört inzwischen zum Standard. Hierfür gibt es automatisierte Hilfsmittel wie zum Beispiel VMware Skyline oder Runecast Analyzer. Letzterer kann neben klassischen vSphere Clustern auch vSAN, NSX-T, AWS, Kubernetes und seit Version 5.0 auch Azure auf Konfomität prüfen.

Ich möchte in diesem Beitrag die Anbindung einer vSphere with Tanzu [*] Umgebung an Runcast Analyzer beschreiben. [* native Kubernetes Pods und TKG auf vSphere]

Einige Schritte sind vereinfacht, da es sich um eine Lab Infrastruktur handelt. Ich werde zu gegebenem Zeitpunkt darauf hinweisen.

Bevor wir Tanzu in Runecast registrieren können, benötigen wir ein paar Informationen.

  • IP Adresse oder FQDN der SupervisorControlPlane
  • Dienstkonto mit Zugriff auf die SupervisorControlPlane
  • Token des Dienstkontos
„Tanzu K8s mit Runecast überwachen“ weiterlesen

Veeam Immutable Backups auf vorhandenen Linux XFS Repositories aktivieren

Veeam backup & Replication v11 steht kurz vor der Veröffentlichung. Diese ist für Mittwoch den 24.2.2021 geplant. Partner und Service Provider hatten einige Tage Vorsprung und Zugriff auf den sogenannten RTM Build (ready to manufactoring).

Eine der (wie ich meine) spannensten neuen Funktionen in Version 11 ist die Einführung der sogenannten Immutable Backups. Ich hatte bereits in meinem Beitrag „Strategien zum Schutz von Veeam Backups durch unveränderliche Repository Server mit Linux XFS“ berichtet.

Einige von Euch setzen möglicherweise schon Linux Repository Server mit dem XFS Dateisystem und Fastclone produktiv ein und möchten diese nun im die Funktion Immutable-Backups erweitern. Ich werde in diesem Beitrag erklären, wie sich dies mit wenigen Schritten bewerkstelligen lässt.

Schutz aktivieren

Um die Funktion zum Schutz der Backupdaten auf bestehenden XFS Repositories zu aktivieren, müssen wir diese im Veeam Backup Client v11 bearbeiten (Bild unten). Ab Version 11 ist im Abschnitt Repository eine neue Checkbox zu sehen („make recent backups immutable for [x] days“). Dabei ist 7 Tage der kleinstmögliche Zeitraum für den Schutz. Sobald man die Checkbox aktiviert wird sehr wahrscheinlich eine Benachrichtigung wie unten dargestellt erscheinen. „Unable to set the immutability option: cannot find the transport service on server <your repo server>. Configure the server anyway?„. Wir bestätigen diese mit [Yes].

Wir müssen zur Aktivierung des Immutable Flags den Veeam Transport Service auf dem Ziel neu konfigurieren.

„Veeam Immutable Backups auf vorhandenen Linux XFS Repositories aktivieren“ weiterlesen