Vor einigen Monaten stand ich vor einer Frage, die wahrscheinlich viele Proxmox-Nutzer irgendwann beschäftigt:
Warum gibt es eigentlich kein modernes Kundenpanel, das einfach nur die Proxmox API nutzt?
Je mehr ich mir bestehende Lösungen angeschaut habe, desto häufiger bin ich über dieselben Konzepte gestolpert.
Fast jedes Panel wollte entweder Software direkt auf den Proxmox-Nodes installieren, eigene Agenten betreiben oder für jeden einzelnen Kunden Resource Pools anlegen. Technisch funktioniert das – aber irgendwie fühlte es sich nie nach der Lösung an, die ich gesucht habe.
Also habe ich angefangen, selbst eine zu entwickeln.
Die Grundidee
Von Anfang an stand für mich eine Sache fest:
Das Panel sollte Proxmox möglichst gar nicht verändern.
Keine Agenten.
Keine zusätzlichen Dienste auf den Hypervisoren.
Keine künstlichen Resource Pools.
Keine Proxmox-Zugangsdaten für Kunden.
Stattdessen sollte alles über die offizielle Proxmox API laufen.
Nimbus Direct verwaltet Kunden, Benutzer und Berechtigungen vollständig selbst und nutzt Proxmox ausschließlich als Virtualisierungsplattform.
Für mich war genau diese Trennung der entscheidende Punkt.
Weniger Komplexität
In vielen Panels muss zuerst die komplette Struktur in Proxmox aufgebaut werden.
Resource Pools.
Benutzer.
ACLs.
Gruppen.
Und anschließend muss alles dauerhaft synchron gehalten werden.
Ich wollte genau das Gegenteil.
VM synchronisieren.
Kunde auswählen.
Berechtigungen festlegen.
Fertig.
Die eigentliche Infrastruktur bleibt dabei komplett unangetastet.
Sicherheit war keine nachträgliche Idee
Während der Entwicklung habe ich schnell gemerkt, dass ein Kundenpanel deutlich mehr ist als nur Start- und Stop-Buttons.
Jede Anfrage muss geprüft werden.
Jede Berechtigung muss serverseitig validiert werden.
Jede Ressource muss eindeutig einem Kunden gehören.
Deshalb verlässt sich Nimbus niemals auf Daten aus dem Browser.
Der Server entscheidet bei jeder einzelnen Aktion erneut, ob ein Benutzer tatsächlich berechtigt ist, genau diese VM oder diesen Container zu verwalten.
Erst danach wird überhaupt eine Anfrage an die Proxmox API gesendet.
Das klingt selbstverständlich – ist aber genau die Grundlage, auf der das gesamte Projekt aufgebaut wurde.
Aus einem kleinen Projekt wurde immer mehr
Eigentlich wollte ich ursprünglich nur ein schönes Dashboard bauen.
Mittlerweile ist daraus deutlich mehr geworden.
Heute gehören unter anderem dazu:
- Snapshot Center
- ISO-Verwaltung mit One-Time-Boot
- Rollen- und Berechtigungssystem
- Zwei-Faktor-Authentifizierung
- Session Management
- Operations Center zur Infrastrukturüberwachung
- Wartungs- und Incident-System
- Support Ticket Center
- Ressourcen-Alerts
- Benachrichtigungssystem
- Passwortlose Einladungen und Passwort-Reset
- Öffentliche Read-Only-Demo
Viele dieser Funktionen sind erst während der Entwicklung entstanden, weil ich immer wieder neue Ideen hatte oder mir im Alltag Dinge gefehlt haben.
API statt Agent
Das wahrscheinlich größte Alleinstellungsmerkmal von Nimbus Direct ist die Architektur.
Auf den Proxmox-Nodes wird nichts installiert.
Es gibt keinen Agenten.
Keine Shell-Skripte.
Keine Hintergrunddienste.
Nimbus spricht ausschließlich mit der offiziellen Proxmox API und verwendet dabei bewusst einen separaten Service-Account mit minimal notwendigen Berechtigungen.
Dadurch bleibt die eigentliche Virtualisierungsplattform sauber von der Kundenverwaltung getrennt.
Noch lange nicht fertig
Obwohl bereits viele Funktionen umgesetzt sind, sehe ich Nimbus Direct noch lange nicht als abgeschlossen.
Es gibt weiterhin zahlreiche Ideen auf meiner Roadmap.
Dazu gehören unter anderem Übersetzungen, weitere Verwaltungsfunktionen, zusätzliche Sicherheitsmechanismen und langfristig auch mobile Anwendungen.
Gerade das macht für mich den Reiz eines Open-Source-Projekts aus.
Es entwickelt sich ständig weiter.
Nicht, weil es muss.
Sondern weil immer wieder neue Ideen entstehen.
Fazit
Nimbus Direct entstand nicht, weil ich unbedingt noch ein weiteres Proxmox-Panel bauen wollte.
Es entstand, weil ich keine Lösung gefunden habe, die genau so arbeitet, wie ich es mir vorgestellt hatte.
Ein modernes Kundenpanel.
API-first.
Ohne Agenten.
Ohne Resource Pools.
Mit einer klaren Trennung zwischen Infrastruktur und Kundenverwaltung.
Vielleicht wird Nimbus Direct nie das größte Proxmox-Projekt sein.
Aber wenn andere Administratoren dadurch eine einfachere und sicherere Möglichkeit bekommen, ihren Kunden Proxmox bereitzustellen, dann hat sich jede Stunde Entwicklung bereits gelohnt.
Schreibe einen Kommentar