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

Es gibt einen sehr bestimmten Moment, den jedes kleine Infra-Setup irgendwann erreicht.

Der Moment, in dem sich ein Proxmox-Node still und leise in den Proxmox-Node verwandelt.

Es beginnt harmlos. Eine starke Kiste. Reichlich Cores. Viel zu viel RAM. Ein paar VMs für interne Dienste. Vielleicht eine Testumgebung. Dann fragt ein anderes Team nach „nur einer VM". Dann startet noch ein Projekt. Plötzlich hostet dieser eine Node die halbe Entwicklungswelt eines Unternehmens – und jeder will Zugriff.

Genau dort wird es normalerweise unangenehm.

Denn Proxmox ist von Haus aus brutal ehrlich darüber, wer das Sagen hat. Entweder man ist Root, oder man ist im Grunde nur Zuschauer. Und sobald jemand echten Zugriff auf die GUI bekommt, sieht er alles. Die VMs anderer Teams. Storage. Netzwerkobjekte. Den gesamten Datacenter-Baum. Der Blast Radius ist offensichtlich.

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.

Ein aktueller Deep Dive aus der Proxmox-Community zeigt, dass es eine bessere Option gibt – eine, die im Nachhinein naheliegend wirkt, aber überraschend selten genutzt wird.

Das Ergebnis sieht so aus:

Ein physischer Proxmox-Node, aufgeteilt in vollständig isolierte Labs pro Projekt, in denen Teams ihre eigenen VMs über die Proxmox-GUI selbst verwalten – ohne jemals Root zu bekommen und ohne irgendetwas zu sehen, das ihnen nicht gehört.

Keine Magie. Keine Forks. Nur SDN, RBAC und etwas Disziplin.

Die Grundidee: Projekte wie Tenants behandeln (aber nicht so tun, als wäre man eine Cloud)

Das Setup beginnt mit einer einfachen gedanklichen Verschiebung.

Die „Tenants" hier sind keine beliebigen Hosting-Kunden. Es sind interne Projektteams, PoCs, Schulungsgruppen oder kurzlebige Umgebungen. 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 ist es Verschwendung, jedem Team einen eigenen Root-Server zu geben. Aber allen Root auf einer gemeinsamen Kiste zu geben ist leichtsinnig.

Stattdessen baut dieser Ansatz Isolation pro Projekt entlang zweier Achsen auf:

• Netzwerkisolation – jedes Projekt lebt in seiner eigenen SDN-Zone und seinem eigenen VNet
• GUI-Isolation – RBAC stellt sicher, dass Nutzer nur ihre eigenen Ressourcen sehen und steuern

Und entscheidend ist: Beides wird direkt in Proxmox selbst durchgesetzt.

Die Illusion aufbauen: Ein Node, viele unsichtbare Welten

Im Zentrum dieses Setups 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 Projektgrenzen schlicht nicht überschreiten kann. VPN-Nutzer landen direkt im VNet ihres Projekts, und das war's. Keine Routing-Tricks. Keine nachträgliche Firewall-Akrobatik.

Genau hier glänzt Proxmox SDN still und leise. Mit Zones und VNets hört Isolation auf, ein Best-Effort-Versprechen zu sein, und wird zur strukturellen Tatsache.

Aber Netzwerkisolation allein löst nicht das menschliche Problem.

Denn Nutzer wollen nicht nur Konnektivität. Sie wollen Knöpfe.

Die Proxmox-GUI zum Self-Service-Portal machen

Hier ist die mutige Frage, die dieses Setup beantwortet:

Kann man VPN-Nutzer in die Proxmox-GUI einloggen lassen – und es nicht bereuen?

Die Antwort lautet: ja. Sehr sogar. Aber nur, wenn man sich voll auf Proxmox-RBAC einlässt, so wie es gedacht war.

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

Diese Rolle? PVEAdmin.

Das klingt gefährlich, bis man erkennt, dass der Scope wichtiger ist 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

Aber nur für Ressourcen, die innerhalb dieses Pools liegen.

Außerhalb des Pools könnten diese Objekte genauso gut nicht existieren.

Wenn sich ein Projekt-Admin einloggt, schrumpft der Proxmox-Baum zu etwas fast verdächtig Übersichtlichem:

• 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 dedizierte Proxmox-Instanz – ohne tatsächlich eine zu sein.

Storage und die subtilen Wege, wie RBAC brechen kann

Genau hier scheitern die meisten „RBAC-Experimente" still und leise.

Wenn Sie dem Pool nicht ausdrücklich Storage hinzufügen, schlägt die VM-Erstellung auf verwirrende Weise fehl. Keine Disks. Keine ISOs. Kein EFI-Storage. Nur Fehler.

Der Fix ist einfach, aber 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.

Ist das erledigt, 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.

Überspringen Sie SDN-Berechtigungen, laufen Nutzer beim Versuch, eine NIC anzuschließen, gegen eine Wand. Machen Sie es falsch, bekommen sie womöglich Zugriff auf die Netzwerke anderer Projekte.

Die saubere Lösung sind SDN-Zonen pro Projekt.

Jedes Projekt bekommt seine eigene Zone, und die Admin-Gruppe des Projekts bekommt Berechtigungen ausschließlich auf dieser Zone. So 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

Es gibt einen Workaround für Setups, die bereits eine gemeinsame Zone nutzen – indem Berechtigungen direkt auf versteckte VNet-Pfade vergeben werden –, aber die Richtung ist klar: Zonen pro Projekt skalieren besser und scheitern sicherer.

Das ist der Teil, der aus „netter Demo" ein „echtes Multi-Tenancy" macht.

VPN-Zugriff, ohne die Welt zu öffnen

Zuletzt: der Zugriff.

VPN-Nutzer dürfen die Proxmox-GUI nur über die SDN-Gateway-IP ihres Projekts erreichen, auf Port 8006. Firewall-Regeln verknüpfen das mithilfe von IP-Sets, sodass der Zugriff sowohl durch das Netzwerk als auch durch die Identität eingeschränkt ist.

Sie müssen die GUI nicht öffentlich exponieren. Sie brauchen keine Jump-Hosts. Sie brauchen keine brüchigen SSH-Tunnel.

Sie loggen sich ins VPN ein, öffnen einen Browser, und Proxmox ist einfach... da. Aber nur Ihre Scheibe davon.

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

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

Dieses Setup ist mächtig, aber es gibt nicht vor, AWS zu sein.

Es gibt keine harten Quotas für CPU, RAM oder VM-Anzahl. VMIDs sind global. Namenskonventionen hängen weiterhin von menschlicher Disziplin ab. Zugriff pro Nutzer auf die GUI ist ohne statische VPN-IPs knifflig.

Und trotzdem ist für die Zielgruppe nichts davon ein Deal-Breaker.

Denn der eigentliche Gewinn ist operative Klarheit:

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

Es ist ein Sweet Spot, den viele kleine Shops nie als verfügbar erkennen.

Das größere Bild

Bemerkenswert an diesem Muster ist, wie wenig kundenspezifische Maschinerie es braucht.

Keine Patches. Keine externen Control Planes. Keine Hacks, die bei Upgrades zusammenbrechen. Nur Proxmox so nutzen, wie es entworfen wurde – Pools, RBAC, SDN – konsequent angewendet.

Es ist auch eine Erinnerung daran, dass Multi-Tenancy nicht Hyperscale bedeuten muss. Manchmal heißt es einfach nur, Menschen ihre Arbeit machen zu lassen, ohne sich gegenseitig auf die Füße zu treten.

Auf einem einzigen Node.

Ohne jemandem Root zu geben.

Und hat man es einmal funktionieren sehen, ist es sehr schwer, zurückzugehen.

Wenn Sie heute Proxmox betreiben und mehrere Teams jonglieren, ist das eines dieser Setups, das leise eine unbequeme Frage stellt:

Warum machen wir das eigentlich immer noch auf die harte Tour?