Wie ein einzelner Proxmox-Node zur Multi-Tenant-Self-Service-Cloud wurde (ohne jemandem Root zu geben)

Jedes kleine Infra-Setup erreicht irgendwann einen ganz bestimmten Moment.

Aus einem Proxmox-Node wird dann ganz allmählich der Proxmox-Node.

Es fängt harmlos an, mit einer starken Kiste, reichlich Cores und viel zu viel RAM. Darauf laufen ein paar VMs für interne Dienste, vielleicht eine Testumgebung. Dann fragt ein anderes Team nach „nur einer VM", und noch ein Projekt startet. Plötzlich hostet dieser eine Node die halbe Entwicklungswelt eines Unternehmens, und jeder will Zugriff.

An dieser Stelle wird es normalerweise unangenehm, denn Proxmox ist von Haus aus schonungslos ehrlich darüber, wer das Sagen hat. Entweder ist man Root oder im Grunde nur Zuschauer. Wer echten Zugriff auf die GUI bekommt, sieht alles: die VMs anderer Teams, Storage, Netzwerkobjekte und den gesamten Datacenter-Baum. Wie groß der Blast Radius ist, liegt auf der Hand.

Also greifen Leute zu schlechten Kompromissen:

• Root vergeben, weil „es ja nur intern ist".
• Verschachtelte Virtualisierung nutzen, um Isolation vorzutäuschen.
• Für jedes Team einen separaten Host hochziehen und dabei zusehen, wie die Auslastung abstürzt.
• Oder alles dicht abriegeln und selbst zur menschlichen API für Start/Stopp/Snapshot-Anfragen werden.

Eine aktuelle, ausführliche Anleitung aus der Proxmox-Community zeigt eine bessere Option, die im Nachhinein naheliegend wirkt, aber überraschend selten genutzt wird.

Das Ergebnis ist ein physischer Proxmox-Node, aufgeteilt in vollständig isolierte Labs pro Projekt. Die Teams verwalten ihre eigenen VMs selbst über die Proxmox-GUI, bekommen dabei nie Root und sehen nichts, was ihnen nicht gehört.

Dafür braucht es weder Magie noch Forks, nur SDN, RBAC und etwas Disziplin.

Die Grundidee: Projekte wie Tenants behandeln, ohne eine Cloud zu spielen

Das Setup beginnt mit einer einfachen gedanklichen Verschiebung. Die „Tenants" sind hier keine beliebigen Hosting-Kunden, sondern interne Projektteams, PoCs, Schulungsgruppen oder kurzlebige Umgebungen, also Menschen, die Autonomie brauchen, aber keine Souveränität.

Zum Beispiel:

• App-Teams innerhalb eines kleinen Softwareunternehmens
• Von MSPs betriebene Dev-Labs
• Schulungs- oder Workshop-Umgebungen
• Security-Labs mit strikter Trennung

In all diesen Fällen wäre ein eigener Root-Server pro Team Verschwendung, und allen Root auf einer gemeinsamen Kiste zu geben wäre leichtsinnig.

Dieser Ansatz baut die Isolation pro Projekt deshalb entlang zweier Achsen auf. Bei der Netzwerkisolation lebt jedes Projekt in seiner eigenen SDN-Zone und seinem eigenen VNet. Bei der GUI-Isolation sorgt RBAC dafür, dass Nutzer nur ihre eigenen Ressourcen sehen und steuern.

Entscheidend ist, dass Proxmox beides selbst durchsetzt.

Ein Node, viele voneinander unsichtbare Welten

Im Zentrum steht ein einzelner Proxmox-VE-Node, auf dem mehrere vollständig isolierte „Projekt-Labs" laufen.

Jedes Projekt bekommt:

• Seine eigene SDN-Zone (devpj01, devpj02 usw.)
• Sein eigenes VNet innerhalb dieser Zone
• Seinen eigenen VPN-Einstiegspunkt
• Seinen eigenen Proxmox-Pool

Die SDN-Schicht sorgt dafür, dass Traffic die Projektgrenzen schlicht nicht überschreiten kann. VPN-Nutzer landen direkt im VNet ihres Projekts, und das war's, ganz ohne Routing-Tricks oder nachträgliche Firewall-Akrobatik.

Hier spielt Proxmox SDN seine Stärke aus, ohne viel Aufhebens darum zu machen. Mit Zones und VNets ist Isolation kein Best-Effort-Versprechen mehr, sondern Teil der Struktur.

Das menschliche Problem löst Netzwerkisolation allein aber nicht, denn Nutzer wollen mehr als Konnektivität. Sie wollen Knöpfe zum Drücken.

Die Proxmox-GUI als Self-Service-Portal

Das Setup beantwortet eine mutige Frage: Kann man VPN-Nutzer in die Proxmox-GUI lassen, ohne es zu bereuen?

Man kann, und zwar ziemlich gut, aber nur wenn man sich voll auf Proxmox-RBAC einlässt, so wie es gedacht ist. Der Trick sind Pools.

Jedes Projekt bekommt seinen eigenen Pool:

• pj01
• pj02
• und so weiter

Dann:

• Wird pro Projekt eine Gruppe angelegt (Pj01Admins)
• Werden Nutzer dieser Gruppe hinzugefügt
• Bekommt die Gruppe eine Rolle nur auf dem Pool, nicht auf dem Datacenter oder dem Node

Die Rolle ist PVEAdmin. Das klingt gefährlich, bis man merkt, dass der Scope mehr zählt als die Rolle. PVEAdmin innerhalb eines Pools bedeutet:

• VMs starten/stoppen
• Konsolen öffnen
• VM-Einstellungen ändern
• Snapshots erstellen
• Backups ausführen
• VMs erstellen und löschen

All das gilt aber nur für Ressourcen innerhalb dieses Pools. Was außerhalb liegt, könnte für die Nutzer genauso gut nicht existieren.

Loggt sich ein Projekt-Admin ein, schrumpft der Proxmox-Baum auf etwas fast verdächtig Übersichtliches:

• Keine Datacenter-Übersicht
• Keine anderen Projekte
• Keine clusterweiten Einstellungen
• Nur ihr Pool, ihre VMs und der ihnen ausdrücklich zugewiesene Storage

Es fühlt sich an wie eine eigene Proxmox-Instanz, obwohl es keine ist.

Storage und die unauffälligen Stellen, an denen RBAC bricht

An dieser Stelle scheitern die meisten RBAC-Experimente, und zwar oft, ohne dass klar wird, warum.

Wer dem Pool nicht ausdrücklich Storage hinzufügt, erlebt eine verwirrend fehlschlagende VM-Erstellung ohne Disks, ISOs oder EFI-Storage, nur mit Fehlermeldungen.

Die Lösung ist einfach, wenn auch nicht offensichtlich:

• VM-Disk-Storage muss dem Pool hinzugefügt werden
• ISO-Storage muss hinzugefügt werden
• Boot-/EFI-bezogener Storage muss hinzugefügt werden

Erst dann hält die Illusion. Danach können Projekt-Admins VMs von Anfang bis Ende erstellen, ohne je etwas Globales anzufassen.

SDN-Berechtigungen: das entscheidende Detail

Die Netzwerkauswahl bei der VM-Erstellung ist die scharfe Kante. Wer SDN-Berechtigungen überspringt, lässt die Nutzer beim Anschließen einer NIC gegen eine Wand laufen. Wer sie falsch setzt, gibt ihnen womöglich Zugriff auf die Netzwerke anderer Projekte.

Sauber lösen lässt sich das mit SDN-Zonen pro Projekt. Jedes Projekt bekommt seine eigene Zone, und die Admin-Gruppe des Projekts erhält Berechtigungen ausschließlich auf dieser Zone. Damit gilt:

• Sie können NICs an ihr eigenes VNet anschließen
• Sie können die VNets anderer Projekte weder sehen noch ändern
• Sie können keine neuen Zonen oder VNets global erstellen

Für Setups, die bereits eine gemeinsame Zone nutzen, gibt es einen Workaround, bei dem Berechtigungen direkt auf versteckte VNet-Pfade vergeben werden. Die Richtung ist trotzdem klar: Zonen pro Projekt skalieren besser, und wenn etwas schiefgeht, bleibt es sicherer.

Mit diesem Teil wird aus einer netten Demo echtes Multi-Tenancy.

VPN-Zugriff, ohne die Welt zu öffnen

Bleibt noch der Zugriff. VPN-Nutzer erreichen die Proxmox-GUI nur über die SDN-Gateway-IP ihres Projekts auf Port 8006. Firewall-Regeln verknüpfen das über IP-Sets, sodass Netzwerk und Identität den Zugriff gemeinsam einschränken.

Die GUI muss also nicht öffentlich erreichbar sein, und Sie brauchen weder Jump-Hosts noch brüchige SSH-Tunnel. Man loggt sich ins VPN ein, öffnet einen Browser, und Proxmox ist einfach... da, allerdings nur die eigene Scheibe davon.

Das fühlt sich auf eine Art modern an, für die Proxmox nicht immer die verdiente Anerkennung bekommt.

Was das noch nicht löst (und warum das okay ist)

Das Setup ist mächtig, gibt aber nicht vor, AWS zu sein. Es gibt keine harten Quotas für CPU, RAM oder VM-Anzahl, VMIDs sind global, und Namenskonventionen hängen weiter von menschlicher Disziplin ab. Zugriff auf die GUI pro Nutzer ist ohne statische VPN-IPs knifflig.

Für die Zielgruppe ist nichts davon ein Deal-Breaker, denn der eigentliche Gewinn liegt in der operativen Klarheit:

• Infra-Owner behalten Root und das Datacenter
• Projektteams bekommen Autonomie
• Isolation wird durch Design erzwungen, nicht durch Vertrauen
• Die Hardware-Auslastung bleibt hoch

Viele kleine Shops ahnen gar nicht, dass dieser Sweet Spot für sie erreichbar ist.

Das größere Bild

Bemerkenswert an diesem Muster ist, wie wenig eigene Maschinerie es braucht. Es gibt keine Patches, keine externen Control Planes und keine Hacks, die beim nächsten Upgrade zusammenbrechen. Man nutzt Proxmox einfach so, wie es entworfen wurde, mit Pools, RBAC und SDN, und das konsequent.

Außerdem zeigt es, dass Multi-Tenancy nicht Hyperscale bedeuten muss. Manchmal heißt es nur, Menschen ihre Arbeit machen zu lassen, ohne dass sie sich gegenseitig auf die Füße treten, auf einem einzigen Node und ohne jemandem Root zu geben. Wer das einmal hat funktionieren sehen, will kaum noch zurück.

Wenn Sie heute Proxmox betreiben und mehrere Teams jonglieren, stellt dieses Setup eine unbequeme Frage: Warum machen wir das eigentlich immer noch auf die harte Tour?