Ein tieferer Blick in vSphere Rollen und Berechtigungen

Ursprünglich sollte dieser Artikel „Das Rollen Paradoxon“ lauten. Bei längerer Betrachtung kam ich zu dem Schluss, dass es sich hier um kein Paradoxon im eigentlichen Sinne handelt. Das vCenter macht hier nur seine ihm aufgetragene Arbeit.

Berechtigungen unter vSphere sind prinzipiell simpel (so lange wir keine eingeschränkten Berechtigungen verwenden möchten). Wenn wir Mitglied der Administratorengruppe sind und uneingeschränkt auf alle Objekte im Datacenter zugreifen dürfen, sind Privilegien und Rollen schnell erklärt.

Begriffs-Definition

Ein Privileg ist die kleinste Einheit. Es erlaubt die Ausführung einer ganz bestimmten Aktion.

Eine Rolle ist eine Sammlung von Privillegien. Die Administrator-Rolle enthält alle verfügbaren Privilegien. Die No-Access-Rolle enthält dagegen keinerlei Privilegien. „No-Access“ ist hierbei nicht als explizites Verbot zu verstehen, sondern als Fehlen von Berechtigungen. Was zunächst nach einer semantischen Spitzfindigkeit aussehen mag, ist ein wichtiger Unterschied zu anderen Berechtigungskonzepten wie beispielsweise Active-Directory.

Fehlendes Privilleg != Verbot

Eine Berechtigung (Permission) setzt sich immer aus drei Komponenten zusammen: Einem vSphere-Objekt, einer Rolle und einem Benutzer bzw. einer Benutzergruppe. Ein Benutzer (oder eine Gruppe) kann auf unterschiedlichen Objekten unterschiedliche Rollen haben. Berechtigungen auf Objekten können in der Hierarchie optional nach unten vererbt werden.

Das Problem

Interessant wird die Sache wenn ich Rechte global vergebe, diese dann aber auf bestimmten Objekten einschränken möchte.

Beispiel: Die Gruppe der Administratoren soll auf alle Objekte Zugriff haben, mit Ausnahme einiger VMs in einem definierten VM-Ordner. Klingt simpel – ist es aber nicht.

Aufmerksam wurde ich auf die hier beschriebene Problematik durch meinen Kollegen Alexej Prozorov, der in einem Kundeprojekt auf dieses Phänomen stiess. Das Thema war so interessant, dass ich es im Labor nachstellen musste.

„Ein tieferer Blick in vSphere Rollen und Berechtigungen“ weiterlesen

Fehler beim vCLS Retreat Mode führt zum Verlust aller Privilegien

Mit Einführung von vSphere 7.0 Update 1 erschienen in vSphere-Clustern erstmals die vSphere Cluster Services VMs (vCLS). Damit wurden Cluster Funktionen wie z.B. Distributed Resource Scheduler (DRS) und andere erstmals unabhängig von der Verfügbarkeit der vCenter Server Appliance (VCSA). Letztere stellt im Cluster immer noch einen Single-Point-of-Failure dar. Durch Auslagerung der DRS Funktion in die redundanten vCLS Maschinen wurde ein höheres Maß an Resilienz erreicht.

Retreat Mode

Der vSphere-Administrator hat nur wenig Einfluss auf die Bereitstellung dieser VMs. Gelegentlich ist es jedoch notwendig, diese VMs von einem Datastore zu entfernen wenn dieser beispielsweise in den Wartungsmodus versetzt werden soll. Dafür gibt es eine Prozedur, um den Cluster in den sogenannten Retreat-Mode zu setzen. Dabei werden temporäre erweiterte Einstellungen gesetzt, die zur Löschung der vCLS VMs durch den Cluster führen.

Laut Prozedur von VMware muss für die Aktivierung des Retreat Modes die Domain ID ermittelt werden. Die Domain ID ist der numerische Wert zwischen ‚domain-c‘ und dem folgenden Doppelpunkt. Im Beispiel aus meinem Labor ist es der Wert 8, aber die Zahl kann durchaus auch vierstellig sein.

Die Domain ID muss dann in den Advanced Settings des vCenters übergeben werden.

config.vcls.clusters.domain-c8.enabled = false
Korrekte Settings für den Retreat Mode.

Admin Fehler beim Retreat Mode

Nach Aktivierung des Retreat-Modes auf einem vSAN-Cluster hatten Administratoren sämtliche Privilegien auf alle Objekte im vSphere-Client verloren.

Eine Überprüfung der Dienste zeigte, dass der vCenter Server Daemon (vpxd) nicht gestartet war.

„Fehler beim vCLS Retreat Mode führt zum Verlust aller Privilegien“ weiterlesen

ESXi Bootmedium – Neue Anforderungen in v8

Die Anforderungen an ESXi Bootmedien haben sich mit ESXi v7 Update3 grundlegend gewandelt. Die Partitionierung wurde verändert und auch die Anforderungen an die Belastbarkeit des Mediums waren gestiegen. Ich hatte darüber in meinem Blogartikel „ESXi Bootmedium – Neuerungen in v7“ berichtet.

USB-Bootmedien erwiesen sich als nicht robust genug und wurden daher ab v7U3 nicht mehr unterstützt. Es ist zwar immer noch möglich, ESXi auf ein USB-Medium zu installieren, jedoch muss dann die ESX-OSData Partition auf einen dauerhaften Speicher umgeleitet werden.

Achtung! USB-Medien und SD-Karten sollten nicht für produktive ESXi Installationen verwendet werden!

Erlaubte Ziele für die ESXi Installation

SD-Karten und USB-Medien scheiden als Installationsziel wegen ihrer schlechten Write-Endurance aus. Weiterhin erlaubt und empfohlen sind dagegen magnetische Disks, SSD und SATA-DOM (Disk-on-Module).

SATA-DOM auf Supermicro E300-9D

Neue Anforderungen ab ESXi v8

Mein Homelab lief bisher unter vSAN 7 und damit unter der klassischen OSA-Architektur. Um den Cluster unter der neuen vSAN ESA Architektur zu betreiben, brauchte es vSphere 8 und neue Speichergeräte.

Ich habe die Installation und Hardware-Kompatibilität auf einem 64 GB USB-Medium getestet (nicht empfohlen!). Während der Installation gab es erwartungsgemäße Warnungen bezüglich des USB-Mediums. Dennoch konnte ich erfolgreich die Erkennung der NVMe Devices und das vCenter Deployment testen.

Setup Warnung bei installation auf ein USB-Flashmedium

Nach erfolgreicher Testphase installierte ich ESXi 8U2 auf das SATA-DOM meines Supermicro E300 Servers. Zu meiner Überraschung scheiterte das Setup sehr früh mit der Meldung: „disk device does not support OSDATA„.

RTFM

Die Erklärung hierfür ist simpel: „Read the fine manual!“

Mein 16 GB SATA-DOM von Supermicro war schlicht zu klein.

Der Setup-Guide für ESXi 8 benennt die Anforderungen ganz klar inter dem Punkt „Storage Requirements for ESXi 8.0 Installation or Upgrade„:

For best performance of an ESXi 8.0 installation, use a persistent storage device that is a minimum of 32 GB for boot devices. Upgrading to ESXi 8.0 requires a boot device that is a minimum of 8 GB. When booting from a local disk, SAN or iSCSI LUN, at least a 32 GB disk is required to allow for the creation of system storage volumes, which include a boot partition, boot banks, and a VMFS-L based ESX-OSData volume. The ESX-OSData volume takes on the role of the legacy /scratch partition, locker partition for VMware Tools, and core dump destination.

VMware vSphere product doumentation

Mit anderen Worten: Neuinstallationen benötigen ein Bootmedium von mindestens 32 GB (128 GB empfohlen) und Upgrade von einer ESXi v7 Version benötigt mindestens 8 GB, jedoch muss in dieser Installation die OSData Partition bereits auf einen alternativen Datenträger umgeleitet sein.

Dirty Trick?

Natürlich versuchte ich es mit einem schmutzigen Trick. Ich installierte zunächst erfolgreich ein ESXi 7U3 auf dem 16 GB SATA-DOM und führte danach eine Upgrade Installation auf v8U2 durch. Auch dieser Versuch scheiterte, da in der frischen v7 Installation der OSData Bereich nicht umgeleitet wurde.

Ich möchte keine Installation auf einem USB-Medium durchführen, da ich bereits zu viele Fälle gesehen habe, in denen diese Medien versagt haben. Bleibt eigentlich nur die Investition in ein größeres SATA-DOM.

Ich habe mich für das 64-GB-Modell entschieden, da es ein guter Kompromiss zwischen Mindestanforderungen und Wirtschaftlichkeit ist.

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.