Die Identitäten, die Sie für die verschiedenen Zugriffe berechtigen können, stammen aus mehreren möglichen Quellen. Eine frisch installierte vCenter-Appliance liefert bereits zwei Identitätsquellen mit: "localos" und die SSO-Domäne, die Sie bei der Installation vergeben haben. In vielen Umgebungen wird der vom Installationsassistenten vorgeschlagene Wert "vsphere.local" übernommen, andere Administratoren vergeben einen eigenen Domänennamen. Die SSO-Domäne ist nachträglich nicht änderbar, sie sollte sich daher von jeder anderen Anmeldedomäne unterscheiden, die Sie zukünftig an vSphere anbinden wollen.

Quellen für Identitäten

Die Quelle "localos" stammt noch aus der Zeit, als vCenter ausschließlich als Windows-Dienst lief; damit ließen sich lokale Windows-Benutzer des vCenter-Servers zur Verwaltung der Umgebung berechtigen. Sie sollten diese Identitätsquelle heutzutage nicht mehr verwenden, zumal Sie mit der vSphere-API keine neuen Benutzer dort anlegen können. Die SSO-Domäne hingegen ist eine valide Quelle für Accounts und Gruppen mit vSphere-Verwaltungsaufgaben und Sie können dort eine Kennwort- und Sperrrichtlinie definieren.

Auch Partnersysteme, die sich in VMware vSphere integrieren, profitieren von dieser Identitätsquelle und mittels Enhanced Linked Mode [1] lassen sich mehrere vCenter-Instanzen an eine gemeinsame SSO-Domäne anschließen. Eine separate Bereitstellung gemeinsamer Platform Services Controller, wie sie noch in vSphere 6 verfügbar war, wird indes nicht mehr unterstützt.

Zusätzlich zu den mitgelieferten Identitätsquellen können Sie eine beliebige Anzahl an AD- oder OpenLDAP-Domänen anbinden. Im Fall des AD gibt es traditionell zwei alternative Verfahren:

• Klassischer LDAP-Bind mit einem hinterlegten Serviceaccount: Es wird nur die Domäne durchsucht, zu der Sie anbinden, und der Account sollte über ein nicht ablaufendes Kennwort verfügen. Das Verfahren ist identisch mit dem Anbinden von OpenLDAP.
• AD-Beitritt der vCenter-Appliance und "Integrierte Windows-Authentifizierung" (IWA): Da der Zugriff hier mit der Maschinenidentität erfolgt, müssen Sie kein Servicekonto hinterlegen. Auch ist auf diese Weise das Durchsuchen anderer Domains im Forest und sogar vertrauter Domänen mit gewissen Einschränkungen möglich. Unter [2] finden Sie unterstützte Szenarien.

Die zweite Variante sieht auf den ersten Blick vielversprechend aus, besonders wenn Ihre Umgebung mehrere AD-Domänen beinhaltet, aus denen Benutzer und Gruppen stammen können. Bevor Sie sich jedoch dafür entscheiden, müssen Sie bedenken, dass die Mitgliedschaft von vSphere-Komponenten im AD vor dem Hintergrund zahlreicher Ransomware-Angriffe auf virtualisierte Infrastrukturen nicht unumstritten ist. Sie sollten dies noch einmal kritisch hinterfragen, falls Ihr vCenter und vielleicht sogar ESXi-Hosts bisher Mitglied im AD waren.

Ferner wird die IWA bereits seit vSphere 7 nicht mehr weiterentwickelt und ist mit vSphere 8 offiziell abgekündigt. Damit wird das Feature zwar noch unterstützt, jedoch können Sie nicht damit rechnen, es in einer späteren vSphere-Version noch vorzufinden. Die Verbundauthentifizierung mit ADFS, die seit vSphere 7 bequem möglich ist, setzt IWA übrigens nicht voraus – diese Integration kommt mit einem einfachen LDAP-Bind bestens zurecht.

Ganz gleich, wie viele Identitätsquellen Sie an Ihr vCenter-SSO angebunden haben, nur eine davon kann als Standarddomäne fungieren. Benutzer aus allen anderen Domänen müssen die Domäne bei der Anmeldung – sei es am Webclient oder über PowerCLI – explizit mit angeben.

Berechtigungskonzept planen und umsetzen

Für das Design eines Rollen- und Berechtigungskonzepts kann es keine allgemeingültige Anleitung geben, denn sowohl die Anforderungen an die Verwaltung der Plattform als auch die Strukturen hinter den Identitätsquellen sind stets individuell und variieren stark zwischen verschiedenen vSphere-Umgebungen. Die folgenden Hinweise sind daher lediglich als Best Practice-Empfehlungen zu werten.

Rollen sollten Sie Gruppen, nicht einzelnen Accounts zuweisen. Serviceaccounts, zu denen Anwendungen mit einem sehr speziellen Berechtigungssatz gehören, können hier eine Ausnahme bilden; allerdings geht damit auch eine Ausnahme aus Ihren Identity-Management-Prozessen einher, was nicht zu empfehlen ist. Verwenden Sie keine vordefinierten AD-Gruppen wie "Domänen-Admins" oder "Hyper-V Administratoren" zur Berechtigungsvergabe in vSphere.

Welche Identitätsquellen Sie auch immer nutzen, Sie sollten einen oder zwei Break-Glass-Accounts aus der SSO-Domäne vorrätig halten, die eine globale Administratorrolle auf der obersten Ebene zugewiesen haben. Diese Accounts dürfen keinen Gruppen angehören. Setzen Sie Ordner ein, um Objekte so zu gruppieren, wie es Ihrem Berechtigungskonzept entspricht. Delegieren Sie zudem die Berechtigungsvergabe sowie die Anlage und das Bearbeiten der Ordnerhierarchie und der Tags nicht an Anwendungsverwalter. Das Verschieben von Objekten zwischen den "eigenen" Ordnern sowie das Zuweisen berechtigter Tags dürfen und sollten Sie hingegen delegieren.

Weisen Sie die Rollen möglichst einheitlich inklusive Vererbung zu. Dadurch wird Ihr RBAC-Konstrukt robuster gegenüber Änderungen in der Ordnerhierarchie. Verwenden Sie die vordefinierte Rolle "Kein Zugriff", um Anwendungsverwaltern den Zugang zu bestimmten Teilen der Hierarchie zu verwehren, beispielsweise zu Management-Clustern. Anwendungsadministratoren sollten außerdem keine Berechtigung dazu haben, Dateien in Datastores hoch- oder herunterzuladen (Low-Level-Operations). Diese Berechtigung birgt ein erhebliches Sicherheitsrisiko. Falls die Nutzer beispielsweise ISO-Dateien selbst hochladen müssen, delegieren Sie dies über Inhaltsbibliotheken.

Halten Sie die Anzahl der Rollen, die Sie einer Gruppe zuweisen, gering. Für einen typischen Anwendungsadministrator werden weitreichende Rechte auf virtuellen Maschinen und vApps und ein recht sparsamer Berechtigungssatz auf Datenspeichern und virtuellen Portgruppen benötigt. Diese Berechtigungen lassen sich innerhalb einer Rolle kombinieren, da sie stets auf eine bestimmte Objektart bezogen sind.

Die oberste Ebene der Berechtigungshierarchie verdient eine besondere Erwähnung. Diese Berechtigungen können ausschließlich von globalen Administratoren bearbeitet werden. Dafür hat der vCenter-Webclient einen eigenen Menüpunkt. Sie sollten auf dieser Ebene keine zusätzlichen Berechtigungen delegieren. Selbst wenn Sie Accounts aus dem AD oder openLDAP für hochprivilegierte Tätigkeiten verwenden, sollten Sie die Bearbeitung globaler Berechtigungen auf die Admin-Accounts aus der internen SSO-Domäne beschränken.

Im dritten Teil schildern wir, wie Sie auf dem Hostclient die gesamte Palette an Berechtigungen administrieren und wie Ihnen die PowerShell bei dieser Aufgabe hilft. Im ersten Teil sind wir kurz auf das Konzept von Objekten und Rollen eingegangen und haben erklärt, wie Sie mit passgenauen Berechtigungen für mehr Sicherheit sorgen.

Über den Autor: Evgenij Smirnov ist Senior Solutions Architect bei Semperis und Microsoft-MVP für Cloud & Datacenter Management sowie VMware Certified Implementation Expert für Datacenter-Virtualisierung.