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.

Vorbereitungen

Wir benötigen zunächst einen Testbenutzer in der SSO-Domäne des vCenters. Dazu gehen wir auf Administration > Single Sign On > Users and Groups.

Mit ‚ADD‘ fügen wir einen neuen Benutzer hinzu.

Wir erzeugen ihn in der SSO-Domäne vsphere.local und nennen ihn TestUser1. Dieser Testuser soll auch Teil einer Nutzergruppe ‚TestGroup1‚ sein. Unter dem Register Groups klicken wir auf ‚ADD‘.

Wir geben dieser Nutzergruppe eine globale Berechtigung. Dazu wählen wir Administration > Access Control > Global Permissions > Add.

Wichtig ist, dass wir die SSO-Domäne wählen (hier: vsphere.local) und die Rolle vererben (Propagate to children).

Der User TestUser1 aus der Gruppe TestGroup1 hat damit die Administrator-Rolle auf allen Objekten. Wir können dies auf einem beliebigen Objekt überprüfen.

Soweit, so gut.

Neue Anforderung: Rechte auf bestimmten VMs einschränken

In unserem fiktiven Szenario kommt nun die Anforderung der Geschäftsleitung, dass TestUser1 keinen Zugriff auf bestimmte VMs haben soll. Dazu werden die VMs in einen VM-Ordner gepackt und der Gruppe TestGroup1 die Privilegien entzogen. Sie erhält die No-Access Rolle.

Die hochgeheime VM LinuxFTTest1 wird in den Ordner ‚NoAccess4UserGroup1‚ verschoben.

Direkt auf dem Ordner setzen wir für die Gruppe TestGroup1 die Rolle „No-Access“. Damit wird die geerbte Rolle Administrator überschrieben, da die No-Access Rolle näher am Objekt gesetzt wurde.

Wir überprüfen das Ergebnis als administrator@vsphere.local. Die Rechte auf den Ordner „NoAccess4UserGroup1“ sind korrekt gesetzt. Interessant ist aber die Berechtigung auf die VM LinuxFTTest1. Dort hat die Gruppe UserGroup1 die geerbte Rolle Administrator und die No-Access Rolle aus dem Ordner darüber. Wir werden gleich sehen, welche Konsequenzen das hat.

Wir überprüfen das Ergebnis, indem wir uns als Testuser1 am vSphere-Client anmelden.

Beim Blick in die Ansicht VMs and Folders können wir den Ordner „NoAccess4UserGroup1“ nicht sehen. Das ist soweit genau was wir erreichen wollten.

Wechseln wir jedoch die Ansicht in „Hosts & Clusters“, so ist die geheime VM aus dem verborgenen Ordner dort sichtbar. Damit nicht genug. Die VM ist sogar startbar, obwohl wir dort eigentlich die No-Access Rolle haben sollten.

Gleicher Versuch ohne Gruppe

Einerseits unsichtbar, andererseits Administrator. Verhält sich das bei diskreten Usern anstatt Gruppen genauso?

Wir wiederholen den oben beschriebenen Versuch. Diesesmal jedoch ohne Gruppen, sondern direkt mit dem TestUser1. Dieser User erhält global die Administrator-Rolle und die No-Access Rolle auf dem Ordner „NoAccess4UserGroup1“.

Das Ergebinis ist vergleichbar mit dem Test der Gruppe. Der TestUser1 hat auf die VM sowohl die Rolle „No-Access“ als auch „Administrator“.

Erklärung

Was wir hier sehen ist kein Bug oder eine Fehlfunktion im vCenter. Vielmehr macht vCenter genau was ihm aufgetragen wurde.

Wie ich in der Begriffsdefinition zu Eingang erklärt habe, ist die „No-Access“-Rolle mitnichten ein Verbot, sondern nur das Fehlen von Privillegien. Ich erkläre das in meinen Kursen gerne mit einem Schlüsselbund. Ein Privilleg ist ein Schlüssel und eine Rolle ein Schlüsselbund. Verleihe ich einer Person oder Gruppe die Administrator-Rolle, so ist das mit einem Schlüsselbund vergleichbar, der alle Schlüssel enthält. Im Gegensatz dazu ist die „No-Access“-Rolle ein leerer Schlüsselbund ohne Schlüssel. Übergebe ich einer Person den vollen Schlüsselbund und den leeren, so hat sie im Ergebnis immer noch den vollen Schlüsselbund. Allso alle Privilegien.

Rollen werden in vCenter mit dem UNION Befehl kombiniert.

Alles + nichts = alles.

Rollen, die näher am Objekt gesetzt werden, überschreiben vererbte Rollen.

Betrachten wir uns die Rechte-Hierarchie in vCenter, so wird klar warum der erste Ansatz nicht unsere Anforderungen erfüllen konnte. Die Administrator-Rolle auf globaler Ebene (Top Level) wird auf alle Objekte darunter vererbt. Die „No-Access“-Rolle auf Ebene des VM-Ordners hatte den gewünschten Effekt, indem sie die Administrator-Rolle dort überschrieb. Über den Zweig „Host Folder“ gelangte die Administrator-Rolle über den Root Ressourcepool jedoch wieder auf die VM und wir hatten somit beide Rollen auf dem Objekt, die über UNION vereint wurden. Es blieb die Administrator-Rolle.

Lösung der Anforderung

Wie könnte nun die Anforderung umgesetzt werden, dass eine Gruppe die Administrator-Rolle auf fast alle VMs erhält, jedoch keinen Zugriff auf eine bestimmte Gruppe VMs?

Ein möglicher Lösungsansatz wäre folgender:

Wir vergeben keine globale Administrator-Rolle für die Gruppe TestGroup1. Wir Erzeugen einen VM-Folder „All-VMs“ unter dem wir alle anderen VM Folder organisieren. Zusätzlich erzeugen wir einen VM-Ordner „Restricted“, wie in der Abbildung unten dargestellt.

TestGroup1 erhält die Adminitrator-Rolle auf dem Ordner „All-VMs“ die nach unten vererbt wird. Auf dem Unterordner „Restricted“ vergeben wir der TestGroup1 die Rolle „No-Access“. Diese überschreibt die Administrator-Rolle, da sie näher am Objekt gesetzt wurde.

TestGroup1 hat keinen Zugriff auf die VM und den Folder „Restricted“.

Für alle anderen Ordner und VMs bleibt die Administrator-Rolle erhalten.

Da wir in diesem Experiment keine globalen Berechtigungen gesetzt hatten, wird auch in der Hosts & Cluster Ansicht die Berechtigung auf die VM nicht überschrieben und bleibt auf „No-Access“.

Noch nicht ganz am Ziel

Unsere Strategie hat noch einen Schönheitsfehler, den wir erkennen, sobald wir uns mit TestUser1 (aus der Gruppe TestGroup1) anmelden.

Da wir die Rechte nicht global gesetzt haben, fehlenTestUser1 sämtliche Berechtigungen aus dem Datacenter. Das ist nicht ausreichend für einen User, der eigentlich Administrator sein soll – mit Ausnahme der VMs unter „Restricted“.

Die Erklärung liefert das unten dargestellte Diagramm. Auf globaler Ebene sind keine Berechtigungen für die Gruppe TestGroup1 gesetzt, was mit einer No-Access Rolle gleichkommt. Erst ab dem VM Ordner „All-VMs“ greift die Administrator-Rolle. Objekte wie Netzwerk, Storage, Hosts, oder Data Center sind verborgen.

Wir behelfen uns, indem wir die Rolle Administrator klonen und alle VM-Berechtigungen entziehen. Wir nennen diese zum Beispiel „Infra-Admin“. Eine Zweite Rolle „VM-Admin“ enthält ausschließlich VM-Privillegien. Vereint man beide neuen Rollen, so ist das Resultat die Default-Administrator-Rolle.

Wir geben der TestGroup1 global die Infra-Admin Rolle und vererben sie nach unten. TestGroup1 hat somit alle Infrastruktur Privillegien auf allen Objekten mit Ausnahme der VM-Privillegien.

Auf Ordner „All-VMs“ vergeben wir die VM-Admin-Rolle und vererben diese nach unten. Auf Ordner „Restricted“ setzen wir die „No-Access“ Rolle, die die „VM-Admin“-Rolle dort überschreibt.

Der root Resource Pool überträgt die Infra-Admin Rolle auf die VMs. Der Zugriff auf die VMs unterhalb des Restricted-Ordners bleibt dennoch verwehrt, da die Infra-Admin Rolle keinerlei VM-Privillegien enthält.