Wer Proxmox VE einsetzt, kennt die Weboberfläche wahrscheinlich sehr gut. Für Administratoren bietet sie praktisch alles, was man für den täglichen Betrieb einer Virtualisierungsumgebung benötigt.

Aber was ist, wenn nicht nur Administratoren auf die Umgebung zugreifen sollen?

Ich wollte Benutzern die Möglichkeit geben, ihre eigenen virtuellen Maschinen selbst zu verwalten, ohne ihnen dafür Zugriff auf die eigentliche Proxmox-Oberfläche geben zu müssen.

Aus dieser Idee ist PVE Panel entstanden – ein Open-Source Self-Service Portal für Proxmox VE.

GitHub:

https://github.com/sebastianflint/pve-panel

Die Ausgangssituation

Die Idee entstand ursprünglich aus meinem eigenen Homelab.

Ich wollte Benutzern virtuelle Maschinen zur Verfügung stellen, dabei aber möglichst wenig administrativen Aufwand haben. Gleichzeitig sollten die Benutzer keinen direkten Zugriff auf meine Proxmox-Infrastruktur erhalten.

Dazu kommt der weitere Gedanke: Ich finde es wahnsinnig interessant wie Self-Service Prozesse funktionieren und umgesetzt werden.

Ein typischer Benutzer sollte beispielsweise selbstständig:

seine virtuellen Maschinen sehen
Systeme starten und herunterfahren
einen Neustart durchführen
auf die Konsole zugreifen
Ressourcen und Auslastung ansehen
Snapshots erstellen und wiederherstellen
und sogar eigene VMs bereitstellen können

Also im Prinzip genau das, was man auch von einem klassischen VPS- oder Cloud-Provider kennt.

Nur eben self-hosted auf der eigenen Proxmox-Infrastruktur.

Warum nicht einfach die Proxmox-Oberfläche verwenden?

Natürlich besitzt Proxmox bereits ein sehr umfangreiches Rollen- und Berechtigungssystem.

Mein Ziel war allerdings eine andere User Experience.

Ein Benutzer soll sich nicht mit Nodes, Storages, Datacentern, Pools oder den zahlreichen technischen Optionen von Proxmox beschäftigen müssen.

Er soll im Idealfall lediglich sehen:

Das sind meine Server.

Und anschließend genau die Funktionen bekommen, die er für deren Betrieb benötigt.

PVE Panel setzt deshalb eine zusätzliche Abstraktionsschicht zwischen Benutzer und Proxmox.

Customer
   │
   ▼
PVE Panel
   │
   ▼
Proxmox API
   │
   ▼
VM / LXC

Der Browser des Benutzers kommuniziert dabei nicht direkt mit Proxmox. Sämtliche Aktionen laufen über das Backend des Panels.

Auch der verwendete Proxmox API Token wird niemals an den Browser weitergegeben.

Zwei getrennte Welten: Customer und Administration

Ein Punkt, der mir bei der Architektur wichtig war, ist die Trennung zwischen Benutzer- und Administrationsoberfläche.

PVE Panel stellt deshalb zwei getrennte Webserver bereit.

Customer Portal
Port 3000

Admin Portal
Port 3001

Das Customer Portal enthält keine Admin-Routen.

Zusätzlich verwenden beide Interfaces getrennte Session-Cookies und Signing Keys.

Damit soll verhindert werden, dass eine gültige Sitzung des Customer Portals automatisch auch für administrative Funktionen verwendet werden kann.

Das Admin Portal lauscht standardmäßig sogar ausschließlich auf localhost und kann beispielsweise nur über einen separaten Reverse Proxy, VPN oder administrativen Zugang erreichbar gemacht werden.

Benutzer sehen nur ihre eigenen Systeme

Eine der wichtigsten Anforderungen war für mich das Thema Mandantentrennung.

PVE Panel führt intern eine Zuordnung zwischen Benutzern und deren virtuellen Maschinen beziehungsweise LXC-Containern.

Bei jeder serverbezogenen Anfrage wird zunächst geprüft, ob der aktuell angemeldete Benutzer dieses System überhaupt besitzt.

Erst danach erfolgt die Anfrage in Richtung Proxmox.

Versucht ein Benutzer auf ein System zuzugreifen, das ihm nicht zugewiesen wurde, behandelt PVE Panel dieses System so, als würde es für diesen Benutzer gar nicht existieren.

Zusätzlich lässt sich auf Proxmox-Seite mit einem dedizierten Pool arbeiten.

Damit entstehen zwei Ebenen:

PVE Panel
└── Ownership / Benutzerzuordnung

Proxmox
└── Pool- und API-Berechtigungen

Selbst wenn auf Anwendungsebene eine falsche Zuordnung vorgenommen wird, kann der verwendete Proxmox Service Account dadurch weiterhin auf einen definierten Bereich beschränkt bleiben.

Das Customer Dashboard

Nach der Anmeldung landet der Benutzer in seinem eigenen Dashboard.

Hier bekommt er einen schnellen Überblick über seine Umgebung und kann seine zugeordneten virtuellen Systeme verwalten.

Zu den aktuell verfügbaren Funktionen gehören unter anderem:

QEMU VMs und LXC Container
Starten und Herunterfahren
Neustart und Force Stop
Live-Status
CPU-, RAM-, Disk- und Netzwerkmetriken
Informationen aus dem QEMU Guest Agent
Snapshots
Browser-Konsole
Netzwerkübersicht
VPN-Verwaltung
Zwei-Faktor-Authentifizierung

Mein Ziel war dabei bewusst, die Oberfläche deutlich einfacher zu halten als eine vollständige Virtualisierungsverwaltung.

Gerade für Testumgebungen, Schulungen, Entwickler oder Homelab-Benutzer reicht dieser Funktionsumfang meiner Meinung nach in vielen Fällen vollkommen aus.

Integrierte Browser-Konsole

Eine wichtige Funktion eines VPS-Portals ist natürlich die Möglichkeit, auf ein System zugreifen zu können, wenn beispielsweise Netzwerk oder Remote Desktop nicht funktionieren.

Deshalb kann direkt aus PVE Panel eine Browser-Konsole geöffnet werden.

Der Benutzer muss dafür weder die Proxmox-Oberfläche kennen noch dort angemeldet sein.

Gerade beim Troubleshooting oder während der Installation eines Systems ist das sehr praktisch.

Self-Service Provisioning

Der nächste Schritt war für mich der eigentliche Self-Service.

Benutzer sollen nicht nur bereits vorhandene Systeme verwalten können, sondern – wenn der Administrator es erlaubt – auch selbst neue Systeme erstellen können.

Dafür veröffentlicht der Administrator ausgewählte Templates.

Der Benutzer bekommt anschließend nur diese freigegebenen Templates angezeigt.

Zusätzlich können Limits definiert werden, sodass Benutzer nicht beliebig viele Ressourcen konsumieren können.

Damit entwickelt sich das Ganze von einer einfachen Verwaltungsoberfläche zu einem kleinen Private-Cloud-Portal.

Linux-Provisioning mit Cloud-Init

Für Linux-Systeme setzt PVE Panel auf Cloud-Init.

Beim Erstellen einer neuen VM können beispielsweise folgende Informationen übernommen werden:

Hostname
Benutzer
Passwort
SSH Public Key
CPU
RAM
Disk-Größe
Netzwerkkonfiguration

Nach dem Clone-Vorgang übernimmt Cloud-Init die Konfiguration innerhalb des Gastbetriebssystems.

In Verbindung mit dem QEMU Guest Agent kann das Panel anschließend weitere Informationen wie beispielsweise IP-Adressen des Systems anzeigen.

Damit lässt sich ein neues Linux-System weitgehend automatisiert bereitstellen.

Windows war etwas interessanter

Bei Windows wollte ich ebenfalls eine möglichst weitgehende automatische Bereitstellung erreichen.

Hier kommt allerdings nicht Cloud-Init zum Einsatz.

Stattdessen basiert der Prozess unter anderem auf:

vorbereiteten Sysprep-Templates
QEMU Guest Agent
automatischer Verarbeitung der Windows-OOBE
Austausch des Administrator-Passworts
Umbenennung des Computers
Erkennung des Windows-Setup-Status
automatischen Neustarts
verschiedenen Readiness Checks

Der Provisioning-Job wartet dabei auf unterschiedliche Zustände innerhalb der VM und versucht sicherzustellen, dass das System tatsächlich fertig eingerichtet wurde.

Das war tatsächlich einer der Bereiche, bei denen während der Entwicklung sehr viele Sonderfälle aufgetaucht sind.

Windows ist eben Windows. 😉

Provisioning Jobs statt „Button drücken und hoffen“

Das Erstellen einer VM besteht aus mehreren einzelnen Schritten.

Beispielsweise:

Template klonen
      ↓
VM konfigurieren
      ↓
Festplatte erweitern
      ↓
Netzwerk konfigurieren
      ↓
VM starten
      ↓
Guest Agent abwarten
      ↓
Gastbetriebssystem konfigurieren
      ↓
Readiness überprüfen
      ↓
Fertig

Deshalb behandelt PVE Panel Provisionierungen als Jobs.

Benutzer können den Fortschritt verfolgen und bekommen bei Fehlern entsprechende Informationen angezeigt.

Administratoren können die Jobs ebenfalls über das Admin Portal einsehen.

Das erleichtert vor allem die Fehlersuche erheblich.

Netzwerkisolierung mit Proxmox SDN

Eine weitere Frage, die bei mehreren Benutzern schnell auftaucht:

Wie trennt man eigentlich deren Netzwerke voneinander?

PVE Panel kann dafür optional mit Proxmox SDN arbeiten.

Dadurch lassen sich beispielsweise private Netzwerke für einzelne Benutzer bereitstellen.

Vereinfacht könnte eine Umgebung dann so aussehen:

                     Internet
                         │
                         │
                    ┌────┴────┐
                    │ Firewall│
                    └────┬────┘
                         │
             ┌───────────┴───────────┐
             │                       │
        Customer A              Customer B
        Network                 Network
             │                       │
       ┌─────┴─────┐           ┌─────┴─────┐
       │           │           │           │
      VM01        VM02        VM03        VM04

Der Benutzer sieht dabei innerhalb des Panels auch eine grafische Übersicht seiner eigenen Netzwerkumgebung.

VPN inklusive

Bei einer isolierten Umgebung stellt sich anschließend natürlich die nächste Frage:

Wie kommt der Benutzer überhaupt an seine Systeme?

Dafür bietet PVE Panel inzwischen auch Funktionen zur Verwaltung persönlicher VPN-Geräte.

Zusätzlich kann eine Integration mit Tailscale verwendet werden.

Dadurch kann der Benutzer seine Systeme erreichen, ohne dass beispielsweise RDP oder SSH direkt aus dem Internet veröffentlicht werden müssen.

Damit wird aus dem VM-Portal langsam eine vollständige kleine Self-Service-Umgebung.

Das Admin Portal

Während das Customer Portal bewusst möglichst reduziert gehalten wird, befinden sich die administrativen Funktionen in einer separaten Oberfläche.

Hier können unter anderem:

Benutzer erstellt und verwaltet werden
bestehende VMs Benutzern zugewiesen werden
Templates veröffentlicht werden
Provisioning-Limits konfiguriert werden
Server verwaltet werden
Provisioning Jobs analysiert werden
2FA zurückgesetzt oder vorgeschrieben werden
Single Sign-on Verknüpfungen verwaltet werden
Audit Logs eingesehen werden
VPN-Funktionen verwaltet werden
SMTP-Einstellungen konfiguriert werden
Benutzer per E-Mail eingeladen werden

Besonders wichtig war mir dabei, dass für alltägliche Aufgaben möglichst kein direkter Zugriff auf die Proxmox-Oberfläche notwendig ist.

Authentifizierung und 2FA

Neben lokalen Benutzerkonten unterstützt PVE Panel auch Funktionen rund um Single Sign-on und Zwei-Faktor-Authentifizierung.

Benutzer können ihre eigene Zwei-Faktor-Authentifizierung verwalten, während Administratoren sie bei Bedarf für einzelne Benutzer verpflichtend machen können.

Damit eignet sich das Portal nicht nur für ein kleines Homelab mit zwei Benutzern, sondern kann auch für etwas größere Test- oder Schulungsumgebungen interessant sein.

Installation per Docker

Die Anwendung kann klassisch mit Node.js betrieben werden.

Für meinen eigenen Einsatz ist allerdings insbesondere die Container-Variante interessant.

Ein fertiges Container Image wird über die GitHub Container Registry bereitgestellt:

ghcr.io/sebastianflint/pve-panel

Damit lässt sich PVE Panel beispielsweise über Docker Compose betreiben.

Auch ein Deployment über Portainer oder auf einem NAS ist möglich.

Ein vollständiges Beispiel sowie alle notwendigen Environment-Variablen befinden sich im Repository.

Reverse Proxy und HTTPS

Für produktive Umgebungen sollte das Customer Portal natürlich ausschließlich über HTTPS veröffentlicht werden.

Im Repository befindet sich dafür unter anderem eine Beispielkonfiguration für Caddy.

Natürlich kann davor genauso ein anderer Reverse Proxy verwendet werden.

Beispielsweise:

Internet
   │
   ▼
Reverse Proxy
   │ HTTPS
   ▼
PVE Panel :3000
   │
   ▼
Proxmox API

Wichtig ist insbesondere die WebSocket-Unterstützung, da diese unter anderem für die integrierte Konsole benötigt wird.

Das Admin Portal würde ich persönlich dagegen nicht öffentlich veröffentlichen, sondern beispielsweise nur über ein internes Management-Netz oder VPN erreichbar machen.

Security war von Anfang an ein Thema

Sobald eine Anwendung Aktionen auf einer Virtualisierungsplattform durchführen darf, sollte man sich natürlich Gedanken über die Berechtigungen machen.

Deshalb verfolgt PVE Panel mehrere Ansätze.

Der Proxmox API-Benutzer erhält eine eigene Rolle mit möglichst eingeschränkten Berechtigungen.

Customer-Systeme befinden sich optional in einem eigenen Proxmox Pool.

Zusätzlich findet innerhalb von PVE Panel eine Ownership-Prüfung statt.

Und schließlich sind Customer- und Admin-Oberfläche voneinander getrennt.

Das ergibt vereinfacht mehrere Schutzschichten:

┌─────────────────────────────┐
│ Customer Authentication     │
├─────────────────────────────┤
│ PVE Panel Ownership Checks  │
├─────────────────────────────┤
│ Proxmox API Permissions     │
├─────────────────────────────┤
│ Proxmox Pool Permissions    │
├─────────────────────────────┤
│ VM / LXC                    │
└─────────────────────────────┘

Trotzdem gilt natürlich:

Das Projekt befindet sich in aktiver Entwicklung und sollte vor dem Einsatz in produktiven oder nicht vertrauenswürdigen Umgebungen entsprechend getestet und geprüft werden.

Insbesondere die Isolation zwischen verschiedenen Benutzern sollte man in seiner eigenen Umgebung ausführlich validieren.

Ein Projekt mit AI-Unterstützung

Ich möchte bei dem Projekt auch transparent mit einem anderen Punkt umgehen.

Ein erheblicher Teil der Entwicklung wurde mit Unterstützung von AI durchgeführt.

Claude von Anthropic hat mich unter anderem bei:

Backend-Code
Frontend-Code
Docker und Compose
GitHub Actions
Dokumentation
automatisierten Tests

unterstützt.

Die Anforderungen, Architekturentscheidungen, Features sowie das Testen in meiner echten Proxmox-Umgebung kamen dabei von mir.

Mein Workflow sah häufig ungefähr so aus:

Idee / Anforderung
        ↓
Konzept
        ↓
Implementierung mit AI
        ↓
Deployment im Homelab
        ↓
Real-World-Test
        ↓
Fehler / Verbesserung
        ↓
nächste Anpassung

Gerade bei diesem Projekt fand ich sehr interessant zu sehen, wie weit man inzwischen auch als Einzelperson mit AI-Unterstützung bei der Entwicklung eines größeren Projekts kommen kann.

Gleichzeitig bedeutet AI-generierter Code selbstverständlich nicht automatisch fehlerfreien oder sicheren Code.

Deshalb dokumentiere ich diese Tatsache auch bewusst im Repository.

Was aus einer kleinen Idee geworden ist

Eigentlich wollte ich zunächst nur eine einfache Oberfläche, über die Benutzer ihre eigenen Proxmox VMs starten und stoppen können.

Mittlerweile unterstützt PVE Panel unter anderem:

✓ QEMU VMs
✓ LXC Container
✓ Power Management
✓ Browser Console
✓ Performance Monitoring
✓ Snapshots
✓ Self-Service Provisioning
✓ Linux Cloud-Init
✓ Windows Provisioning
✓ Quotas
✓ Template Management
✓ Benutzerverwaltung
✓ 2FA
✓ Single Sign-on
✓ Audit Logging
✓ Proxmox SDN
✓ WireGuard
✓ Tailscale
✓ Docker Deployment

Aus einem kleinen Homelab-Projekt ist damit nach und nach ein ziemlich umfangreiches Self-Service Control Panel für Proxmox VE geworden.

Für wen könnte PVE Panel interessant sein?

Ich sehe einige mögliche Einsatzbereiche:

Homelabs

Familie, Freunde oder andere Benutzer können eigene Systeme betreiben, ohne Zugriff auf die komplette Proxmox-Administration zu erhalten.

Trainings- und Schulungsumgebungen

Teilnehmer könnten jeweils eigene virtuelle Maschinen erhalten und diese selbstständig verwalten.

Development / Test

Entwickler können temporäre Testsysteme aus vorgegebenen Templates bereitstellen.

Kleine Hosting-Umgebungen

Auch als einfaches internes VPS-Panel kann die Lösung interessant sein.

Unternehmens-Labs

Teams können eigene Lab-Systeme betreiben, während die eigentliche Virtualisierungsplattform zentral verwaltet bleibt.

Open Source

PVE Panel ist Open Source und auf GitHub verfügbar:

GitHub:
https://github.com/sebastianflint/pve-panel

Dort findet ihr neben dem Quellcode auch:

Installationsanleitung
Docker-Konfiguration
Architekturinformationen
Security-Hinweise
Administrationsdokumentation

Das Projekt befindet sich weiterhin in Entwicklung.

Issues, Feedback, Ideen und natürlich auch Pull Requests sind willkommen.

Fazit

Mein ursprüngliches Ziel war relativ einfach:

Benutzern Zugriff auf ihre eigenen Proxmox VMs geben, ohne ihnen Proxmox selbst geben zu müssen.

Genau daraus ist PVE Panel entstanden.

Dabei wollte ich keine zweite vollständige Proxmox-Administration bauen. Das Panel soll vielmehr die Komplexität der darunterliegenden Virtualisierungsplattform verstecken und genau die Funktionen anbieten, die ein Benutzer für seine eigenen Systeme benötigt.

Für mich ist das Projekt gleichzeitig ein interessantes Experiment, wie weit sich Self-Service, Automatisierung, Proxmox und moderne AI-gestützte Softwareentwicklung miteinander kombinieren lassen.

Und natürlich gibt es noch genug Ideen für die nächsten Versionen. 🙂

PVE Panel – Ein eigenes Self-Service Portal für Proxmox VE