Seit vSphere 4 hat VMware damit begonnen, neben dem klassischen Windows-Client auch einen Webclient anzubieten, um die Abhängigkeit von Windows und den generellen Verwaltungsaufwand der Umgebung zu reduzieren. Anfangs war der Webclient in seiner Funktion recht beschränkt und vSphere-Administratoren kamen am Windows-Client nicht vorbei. Doch mit vSphere 6.5 war die Funktionsparität erreicht, und der klassische Client wird nicht mehr ausgeliefert.

Die Verwaltung im Browser erspart nicht nur den Administratoren die Installation, Konfiguration und Pflege eines zusätzlichen Clientprogramms, sondern eröffnet ganz neue Möglichkeiten, Fachabteilungen und Anwendungsverwalter an der Plattformadministration zu beteiligen. Es wäre jedoch grob fahrlässig, jeden Anwendungsverwalter gleich zum vSphere-Administrator zu machen, nur weil seine Anwendung auf vSphere-VMs läuft.

Doch auch die Schnittstellen zur Automatisierung von vSphere, allen voran PowerCLI und der ihr zugrundeliegende API-Zugriff, werden ständig weiterentwickelt und kommen bei zahlreichen Fachanwendungen zum Einsatz. Oft handelt es sich bei der Integration um reine Status- und Performanceabfragen. In anderen Fällen möchte die Drittanbieter-Anwendung eine VM neu starten, die vApp um eine zusätzliche VM erweitern oder eine virtuelle Festplatte vergrößern. Auch hier müssen jedem Account exakt die Berechtigungen zugewiesen werden, die er tatsächlich benötigt, um einem möglichen Angriff auf die Plattform über die API vorzubeugen und die Flexibilität der Infrastruktur dennoch zu erhalten.

VMware hat diese Notwendigkeit bereits früh erkannt und allen administrativen Zugriffen auf vSphere die rollenbasierte Zugriffssteuerung (Role Based Access Control, RBAC) zugrunde gelegt.

Objekte, Rollen und alles dazwischen

Das RBAC in vSphere ist auf API-Ebene implementiert. Dadurch sehen Sie mit einem Account immer nur diejenigen Objekte, auf die für dieses Konto zumindest Leserechte bestehen, und können nur diejenigen Operationen an diesen Objekten ausführen, für die dieser Account berechtigt ist. "Objekte" können dabei nahezu alle in vSphere verwaltbaren Assets sein – vCenter, Datacenter, Cluster, Hosts, VMs, Datastores, vSwitches und weitere Objektarten. In einem frisch installierten vCenter 8 lassen sich 457 verschiedene Einzelberechtigungen auf 64 Objektarten vergeben. Partnersysteme, die sich in vCenter integrieren, können das Modell um eigene Objektklassen und Berechtigungen erweitern.

Selbst den nebensächlich erscheinenden Objekten wie Tags und Tag-Kategorien können Berechtigungen zugewiesen werden. In modernen Infrastrukturen ist die Rechtebeschränkung allerdings sehr wichtig, denn viele Automatisierungsmechanismen orientieren sich ausschließlich an Tags zur Durchführung ihrer Aktivitäten und vertrauen darauf, dass die Tags korrekt vergeben sind.

Hunderte von möglichen Einzelberechtigungen machen das Design Ihres Berechtigungskonstrukts recht aufwendig. Oft sind es Rechte aus verschiedenen Kategorien, die Sie benötigen, um dem Rechteinhaber scheinbar einfache Operationen zu ermöglichen. Ein "Vollzugriff" auf eine virtuelle Maschine reicht beispielsweise nicht aus, um deren virtuelle Festplatten zu vergrößern – dafür benötigt der ausführende Account auch die Berechtigung "Speicher zuteilen" auf den Datastore, in dem diese Festplatte liegt. Sind Sie es aus der Vergangenheit gewohnt, vSphere-Umgebungen als Mitglied einer globalen Administratorengruppe zu verwalten, wird es Ihnen anfangs vermutlich schwerfallen, ein geeignetes Least-Privilege-Modell zu finden.

Passgenaue Berechtigungen

Das Ziel der Berechtigungsvergabe ist es also, jedem Account, der irgendwelche Verwaltungsaufgaben in vSphere wahrnehmen soll, genau die Berechtigungen auf genau diejenigen Objekte zu erteilen, die er zur Erfüllung seiner Aufgaben tatsächlich benötigt. Natürlich werden Berechtigungen nicht für einzelne Benutzer und meistens auch nicht für einzelne Objekte in Kleinarbeit zugewiesen. Vielmehr hält das RBAC-Modell von vSphere gleich drei Abstraktionsschichten bereit, um das Gesamtkonstrukt möglichst transparent und flexibel zu halten. So werden Berechtigungen stets Rollen zugewiesen. Jede Rolle kann Berechtigungen auf unterschiedliche Objektarten beinhalten, die dann zum Tragen kommen, wenn der Zugriff auf ein Objekt der jeweiligen Art versucht wird.

Nicht nur ein Benutzer, sondern auch eine Gruppe kann Mitglied einer Rolle sein. Haben Sie externe Identitätsquellen angebunden (mehr dazu später), können Sie Rollengruppen aus diesen Quellen auch für die Verwaltung benötigter vSphere-Objekte und -Dienste berechtigen. Die tatsächliche Berechtigungsvergabe erfolgt, indem Sie einem Benutzer oder einer Gruppe an einem bestimmten Objekt eine Rolle zuweisen. So kann ein und dieselbe Gruppe beispielsweise Administrator auf einem ESXi-Cluster sein, in einem anderen Cluster jedoch lediglich virtuelle Maschinen konsumieren. Die Zuweisung ist auf Unterobjekte vererbbar. Und da ein Ordner durchaus ein möglicher Ort der Berechtigungszuweisung sein kann, gestaltet sich die Berechtigungsvergabe in vSphere ähnlich wie beispielsweise in einem Dateisystem.

Es gibt jedoch auch Unterschiede und bei der Konstruktion der Rollen sind einige Besonderheiten zu beachten. So erfolgt die Überlagerung von Rollen ausschließlich additiv und es gibt keine "Verweigerungsberechtigungen". Jede Berechtigung, die aus irgendeiner Rolle, die der Account angehört, auf irgendeiner Ebene geerbt wird, ist Bestandteil des effektiven Berechtigungssatzes. Direkte Rollenzuweisungen überschreiben zudem sämtliche geerbten Zuweisungen am jeweiligen Objekt, vererben alle Zuweisungen jedoch weiter, sofern die Vererbung aktiviert ist.

Damit können Sie durchaus hochprivilegierte Accounts auf Objektebene "aussperren", wenn Sie ihnen dort Rollen mit wenigen Privilegien zuweisen. Am selben Objekt kann dem gleichen Sicherheitsprinzipal (Benutzer oder Gruppe) außerdem stets nur eine Rolle explizit zugewiesen werden. Möchten Sie Kombinationen aus mehreren Rollen bilden, müssen Sie den zugreifenden Benutzer entweder in mehrere Gruppen aufnehmen oder verschachtelte Ordnerstrukturen aufbauen, sodass verschiedene Rollen von verschiedenen Ebenen bis zum Objekt vererbt werden.

Bei der Definition Ihrer Rollen lässt VMware Sie nicht allein: vCenter kommt mit über 30 Vorlagen daher, an denen Sie sich orientieren können. Haben Sie eine Rolle gefunden, die einer von Ihnen gewünschten neuen Rolle fast entspricht, können Sie sich viele Klicks ersparen, indem Sie die fertige Rolle einfach klonen und nur die Unterschiede einarbeiten. Ihre eigenen Rollen können Sie natürlich ebenfalls klonen. So ist es beispielsweise eine valide Designentscheidung, für jeden Anwendungsbetreiber eine Rolle mit zunächst den gleichen Berechtigungen zu definieren. Sind später zusätzliche Rechte notwendig oder müssen sogar einzelne Rechte entfallen, führen Sie dies durch, ohne die anderen Anwendungsbetreuer zu beeinträchtigen.

Im zweiten Teil der Workshopserie zählen wir auf, welche Quellen für Identitäten in Frage kommen und beschreiben, wie Sie Berechtigungskonzept in der Praxis planen und umsetzen. Im dritten und letzten Teil schildern wir, wie Sie auf dem Hostclient die gesamte Palette an Berechtigungen administrieren und wie Ihnen die PowerShell bei dieser Aufgabe hilft.

Ü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.