Backend, Weboberfläche, APIs, Netzwerkkommunikation und Sicherheit
Wer mehrere Proxmox-Server oder voneinander unabhängige Proxmox-Cluster betreibt, steht früher oder später vor der Frage, wie sich diese Systeme möglichst effizient und sicher zentral verwalten lassen.
Im ersten Teil unserer PegaProx-Serie haben wir die Grundlagen der Open-Source-Managementplattform kennengelernt. Dabei wurde deutlich, dass PegaProx nicht als Ersatz für Proxmox VE gedacht ist, sondern eine zusätzliche Verwaltungsebene bereitstellt.
Doch wie funktioniert diese zentrale Verwaltung technisch? Wie kommuniziert PegaProx mit den angebundenen Proxmox-Systemen? Wo werden Konfigurationsdaten gespeichert, welche Netzwerkverbindungen werden benötigt und wie lässt sich die Plattform sicher betreiben?
In diesem zweiten Teil betrachten wir die Architektur von PegaProx genauer. Dabei geht es nicht nur um die einzelnen Komponenten, sondern auch um deren Zusammenspiel, mögliche Sicherheitsrisiken und die Anforderungen an einen zuverlässigen Betrieb.
Das grundlegende Architekturkonzept von PegaProx
PegaProx arbeitet als eigenständige Managementplattform oberhalb der eigentlichen Virtualisierungsinfrastruktur.
Die virtuellen Maschinen und Linux-Container laufen weiterhin auf den angebundenen Proxmox-Hosts. PegaProx übernimmt weder die Rolle des Hypervisors noch die Aufgaben der Proxmox-Cluster-Dienste.
Stattdessen stellt die Anwendung eine zentrale Schnittstelle zwischen Administratoren und mehreren Virtualisierungsumgebungen bereit.
Vereinfacht besteht die Architektur aus drei Ebenen:
- Virtualisierungsebene: Proxmox-Hosts, Cluster, virtuelle Maschinen, Container, Storage und Netzwerke.
- Managementebene: PegaProx mit seinen Backend-Diensten, Verbindungsinformationen und Verwaltungsfunktionen.
- Präsentationsebene: Die browserbasierte Benutzeroberfläche, über die Administratoren mit der Plattform arbeiten.
Dieses Konzept ermöglicht es, verschiedene Proxmox-Umgebungen organisatorisch zusammenzuführen, ohne deren eigentliche Clusterarchitektur verändern zu müssen.
Ein entscheidender Vorteil liegt in der Trennung zwischen Verwaltung und Virtualisierung.
Fällt die PegaProx-Instanz aus, laufen bestehende virtuelle Maschinen und Container auf den Proxmox-Hosts grundsätzlich weiter.
Allerdings stehen die über PegaProx bereitgestellten Verwaltungsfunktionen während des Ausfalls nicht zur Verfügung. Bereits laufende oder geplante Managementaktionen können ebenfalls betroffen sein.
Das PegaProx-Backend
Das Backend bildet die zentrale Verarbeitungsebene von PegaProx.
Hier laufen die Funktionen zusammen, die für die Kommunikation mit den angebundenen Virtualisierungssystemen und die Verarbeitung administrativer Aktionen benötigt werden.
Während die Weboberfläche Informationen darstellt und Benutzereingaben entgegennimmt, verarbeitet das Backend die entsprechenden Anfragen.
Zu den grundlegenden Aufgaben gehören:
- Verwaltung der angebundenen Virtualisierungsumgebungen
- Verarbeitung von API-Anfragen
- Authentifizierung und Autorisierung von Benutzern
- Kommunikation mit Proxmox VE
- Abfrage von Host-, Cluster- und VM-Informationen
- Verarbeitung administrativer Aktionen
- Bereitstellung von Zustands- und Monitoringinformationen
- Verwaltung anwendungsspezifischer Konfigurationsdaten
Warum ist das Backend so wichtig?
Das Backend ist nicht einfach nur eine technische Verbindung zwischen Webbrowser und Proxmox.
Es stellt eine zentrale administrative Vertrauenskomponente dar.
Wenn ein Administrator beispielsweise eine virtuelle Maschine über PegaProx starten möchte, muss die Plattform die Anfrage verarbeiten, die Berechtigung prüfen und den entsprechenden Vorgang auf dem Proxmox-System auslösen.
Dabei müssen sowohl die Berechtigungen innerhalb von PegaProx als auch die Rechte des verwendeten Proxmox-Zugangs berücksichtigt werden.
Die effektiven Möglichkeiten hängen letztlich auch davon ab, welche Berechtigungen die angebundenen Proxmox-Konten beziehungsweise API-Tokens besitzen.
Gerade in produktiven Umgebungen ist deshalb wichtig, das Backend als sicherheitskritischen Bestandteil der Infrastruktur zu betrachten.
Ein kompromittiertes Managementsystem könnte andernfalls zum Ausgangspunkt für Angriffe auf mehrere Virtualisierungscluster werden.
Die Weboberfläche von PegaProx
Die Weboberfläche ist der sichtbare Bestandteil der Plattform.
Sie stellt Administratoren eine zentrale Benutzeroberfläche zur Verfügung, über die unterschiedliche Virtualisierungsumgebungen verwaltet werden können.
Der Zugriff erfolgt über einen modernen Webbrowser.
Dadurch muss auf den administrativen Arbeitsplätzen grundsätzlich keine zusätzliche Desktop-Anwendung installiert werden.
Zentrale Übersicht
Ein wesentliches Ziel der Weboberfläche ist die gemeinsame Darstellung verschiedener Proxmox-Umgebungen.
Administratoren können dadurch Informationen zu mehreren Hosts oder Clustern an einer zentralen Stelle betrachten.
Je nach unterstützter Funktion gehören dazu Informationen über:
- Proxmox-Hosts und Cluster
- Virtuelle Maschinen
- Linux-Container
- CPU- und Arbeitsspeicherauslastung
- Storage-Ressourcen
- Betriebszustände
- Administrative Aufgaben und Ereignisse
Die Oberfläche dient damit sowohl der täglichen Administration als auch der allgemeinen Betriebsüberwachung.
Browser und Backend
Technisch kommuniziert der Browser mit den Web- und API-Endpunkten der PegaProx-Instanz.
Das Backend übernimmt anschließend die Kommunikation mit den angebundenen Proxmox-Systemen.
Für Administratoren entsteht dadurch eine gemeinsame Bedienoberfläche, obwohl die eigentlichen Virtualisierungsressourcen auf unterschiedlichen Systemen liegen.
Besonders interessant ist dieser Ansatz bei mehreren Standorten oder getrennten Sicherheitsbereichen.
Allerdings müssen die Netzwerkverbindungen zwischen PegaProx und den jeweiligen Proxmox-Systemen entsprechend geplant und abgesichert werden.
Kommunikation zwischen PegaProx und Proxmox VE
Die Kommunikation mit Proxmox erfolgt hauptsächlich über die Proxmox-REST-API.
Proxmox stellt diese Schnittstelle standardmäßig über HTTPS auf Port 8006 bereit.
Über die API lassen sich zahlreiche Informationen und Verwaltungsfunktionen abrufen.
Dazu gehören beispielsweise der Zustand eines Hosts, die Konfiguration virtueller Maschinen, verfügbare Storage-Ressourcen und laufende Aufgaben.
PegaProx nutzt diese Schnittstelle, um die angebundenen Systeme zentral zu verwalten.
Beispiel: Eine virtuelle Maschine starten
Ein typischer Verwaltungsablauf lässt sich folgendermaßen beschreiben:
- Ein Administrator meldet sich an der PegaProx-Weboberfläche an.
- Er wählt einen Proxmox-Cluster und anschließend eine virtuelle Maschine aus.
- Er löst die Aktion zum Starten der virtuellen Maschine aus.
- Das PegaProx-Backend prüft die Anfrage und die anwendungsseitigen Berechtigungen.
- PegaProx übermittelt den entsprechenden API-Aufruf an den zuständigen Proxmox-Host.
- Proxmox prüft die dort hinterlegten Berechtigungen und verarbeitet den Auftrag.
- PegaProx ruft den aktualisierten Status ab und stellt das Ergebnis in der Weboberfläche dar.
Die eigentliche Aktion wird somit weiterhin von Proxmox ausgeführt.
PegaProx dient als zentrale Steuerungs- und Verwaltungsebene.
SSH als ergänzender Kommunikationsweg
Nicht sämtliche Verwaltungsfunktionen lassen sich ausschließlich über die Proxmox-API abbilden.
Für bestimmte Funktionen kann deshalb zusätzlich eine SSH-Verbindung erforderlich sein.
Dazu gehören beispielsweise Shell-Zugriffe oder spezielle administrative Operationen.
PegaProx unterstützt entsprechende SSH-Funktionen.
Dabei sollte allerdings berücksichtigt werden, dass SSH-Zugänge auf Hypervisoren besonders schutzbedürftig sind.
Wo möglich, sollten API-basierte Funktionen bevorzugt und SSH-Berechtigungen auf das notwendige Maß beschränkt werden.
APIs und Automatisierung
Programmierschnittstellen sind ein wesentlicher Bestandteil moderner Managementplattformen.
PegaProx besitzt nicht nur Schnittstellen zur Kommunikation mit den Virtualisierungssystemen, sondern stellt auch eigene API-Endpunkte für seine Verwaltungsfunktionen bereit.
Damit lassen sich bestimmte Aufgaben in automatisierte Abläufe integrieren.
Denkbare Einsatzgebiete sind beispielsweise die regelmäßige Abfrage von Ressourceninformationen, die Einbindung in Monitoring-Systeme oder die automatisierte Verarbeitung administrativer Vorgänge.
Auch die Kombination mit externen Automatisierungswerkzeugen ist grundsätzlich interessant.
Dabei sollte jedoch nicht vorausgesetzt werden, dass jede Funktion der Weboberfläche automatisch über eine dokumentierte öffentliche API zur Verfügung steht.
Für produktive Automatisierungen müssen die unterstützten Endpunkte, Authentifizierungsverfahren und Berechtigungen der eingesetzten Version geprüft werden.
Beispiel einer direkten Proxmox-API-Abfrage
Um das technische Prinzip besser zu verstehen, betrachten wir zunächst einen API-Aufruf an Proxmox selbst.
Mit folgendem Befehl lassen sich Informationen über die vorhandenen Nodes abrufen:
curl --fail-with-body \ --cacert /pfad/zur/proxmox-ca.pem \ -H "Authorization: PVEAPIToken=monitor@pve!api=TOKEN_SECRET" \ https://proxmox.example.local:8006/api2/json/nodes
Dabei handelt es sich um einen direkten Proxmox-API-Aufruf und nicht um einen PegaProx-API-Endpunkt.
Der Befehl zeigt jedoch das grundlegende Kommunikationsprinzip.
Ein Client authentifiziert sich gegenüber der Proxmox-API und ruft die gewünschten Informationen ab.
In der Praxis sollte das Token nicht dauerhaft im Shell-Verlauf oder in Skripten im Klartext gespeichert werden. Auch TLS-Zertifikate sollten zuverlässig überprüft werden.
Datenhaltung und Konfiguration
PegaProx benötigt eine eigene Datenhaltung, um seine Konfiguration und bestimmte Verwaltungsinformationen dauerhaft zu speichern.
Dazu gehören insbesondere Informationen über angebundene Cluster, Benutzer, Berechtigungen und Anwendungseinstellungen.
Nach der dokumentierten Projektstruktur verwendet PegaProx eine SQLite-Datenbank.
Diese befindet sich standardmäßig unter:
config/pegaprox.db
Die Anwendung besitzt außerdem Verzeichnisse für Konfigurationsdateien und Protokolle.
Bei einer Docker-Installation werden dafür persistente Volumes verwendet.
Das offizielle Docker-Compose-Beispiel sieht insbesondere folgende Verzeichnisse vor:
/app/config /app/logs
Die persistente Speicherung ist wichtig, damit Konfigurationsinformationen bei einem Neustart oder einer Aktualisierung des Containers erhalten bleiben.
Schutz der Datenbank
Die Datenbank enthält potenziell sicherheitskritische Informationen.
Daher ist es besonders wichtig, sie gegen unberechtigten Zugriff zu schützen.
Nach Angaben des Projekts unterstützt PegaProx auf Linux-x86-64-Systemen die vollständige Datenbankverschlüsselung mit SQLCipher. Auf anderen unterstützten Plattformen kommt eine SQLite-Datenbank mit zusätzlicher Verschlüsselung sensibler Felder zum Einsatz.
Zu diesen sensiblen Informationen können beispielsweise Zugangsdaten zu Clustern, SSH-Schlüssel und Authentifizierungsgeheimnisse gehören.
Die Verschlüsselung ist allerdings nur so sicher wie die Verwaltung der dazugehörigen Schlüssel.
Deshalb sollten sowohl die Datenbank als auch die verwendeten Schlüssel in das Backup- und Wiederherstellungskonzept aufgenommen werden.
Ein Backup ohne die zur Entschlüsselung erforderlichen Informationen kann im Ernstfall unbrauchbar sein.
Netzwerkverbindungen und benötigte Ports
Für einen zuverlässigen Betrieb müssen die Netzwerkverbindungen zwischen Administratoren, PegaProx und den angebundenen Proxmox-Systemen geplant werden.
PegaProx verwendet in der Standardkonfiguration mehrere Netzwerkports.
Port 5000 – Weboberfläche und API
Über Port 5000 werden standardmäßig die Weboberfläche und die zentralen API-Funktionen bereitgestellt.
Dieser Port bildet den primären administrativen Zugang zur Anwendung.
Port 5001 – VNC-WebSocket
Port 5001 dient standardmäßig der WebSocket-Kommunikation für VNC-Konsolen.
Damit können Administratoren virtuelle Maschinen über den Browser bedienen.
Port 5002 – SSH-WebSocket
Über Port 5002 stellt PegaProx standardmäßig die WebSocket-Verbindung für browserbasierte SSH-Konsolen bereit.
Port 8006 – Proxmox-API
Für die Kommunikation mit den angebundenen Proxmox-Hosts wird standardmäßig Port 8006 verwendet.
Die Verbindung erfolgt über HTTPS.
Port 22 – SSH
Für bestimmte Verwaltungsfunktionen kann zusätzlich SSH über Port 22 benötigt werden.
Weitere Netzwerkverbindungen
Abhängig von den aktivierten Funktionen können weitere Ports erforderlich sein.
Dazu gehören beispielsweise Port 8007 für Proxmox Backup Server, Port 3128 für optionale SPICE-Funktionen sowie Port 1514 für den integrierten Syslog-Empfang.
Die Standardports für die PegaProx-Weboberfläche und ihre Konsolendienste lassen sich konfigurieren. Die offiziellen Angaben sollten deshalb immer mit der tatsächlich eingesetzten Version abgeglichen werden.
Empfehlungen für die Firewall
In einer produktiven Umgebung sollten ausschließlich die tatsächlich benötigten Verbindungen freigegeben werden.
Ein mögliches Sicherheitskonzept sieht vor, dass Administratoren ausschließlich über ein separates Management-Netz oder eine gesicherte VPN-Verbindung auf PegaProx zugreifen.
PegaProx wiederum erhält gezielte Verbindungen zu den benötigten Proxmox-Hosts.
Eine pauschale Freigabe sämtlicher Netzwerkverbindungen zwischen allen beteiligten Systemen sollte vermieden werden.
Besonders kritisch wäre es, die Managementoberfläche ohne zusätzliche Schutzmaßnahmen direkt aus dem Internet erreichbar zu machen.
Credentials und Authentifizierung
Damit PegaProx auf die angebundenen Proxmox-Systeme zugreifen kann, benötigt die Plattform geeignete Zugangsdaten.
Hierfür kommen je nach Funktion Proxmox-Benutzerkonten, API-Tokens und gegebenenfalls SSH-Zugänge infrage.
Dedizierte technische Konten
Für die Anbindung sollte möglichst kein persönliches Administratorkonto verwendet werden.
Stattdessen empfiehlt sich ein dediziertes technisches Konto.
Das erleichtert die Trennung zwischen persönlichen administrativen Tätigkeiten und systemseitigen Verbindungen.
Außerdem können Berechtigungen gezielter vergeben und Zugriffe besser nachvollzogen werden.
API-Tokens
Proxmox unterstützt API-Tokens für die programmatische Authentifizierung.
Diese können mit spezifischen Berechtigungen ausgestattet werden.
Für PegaProx sollten nach Möglichkeit nur diejenigen Rechte vergeben werden, die für die tatsächlich eingesetzten Funktionen benötigt werden.
Ein reiner Monitoring-Zugang benötigt beispielsweise weniger Berechtigungen als ein Konto, mit dem virtuelle Maschinen verändert oder gelöscht werden können.
Zugangsdaten sicher speichern
Zugangsdaten dürfen nicht ungeschützt in öffentlich zugänglichen Konfigurationsdateien, Git-Repositories oder Skripten abgelegt werden.
Zusätzlich sollte sichergestellt werden, dass nur autorisierte Administratoren Zugriff auf die PegaProx-Konfiguration und die verwendeten Schlüssel erhalten.
Die Rotation von Zugangsdaten und der Umgang mit kompromittierten API-Tokens gehören ebenfalls in das Betriebskonzept.
Das Sicherheitsmodell von PegaProx
PegaProx verbindet mehrere administrative Sicherheitsbereiche miteinander.
Dadurch entsteht eine zentrale Vertrauensposition innerhalb der Virtualisierungsinfrastruktur.
Das Sicherheitsmodell sollte deshalb mehrere Schutzebenen umfassen.
Authentifizierung
Administratoren müssen sich gegenüber PegaProx authentifizieren.
Die Plattform unterstützt unterschiedliche Authentifizierungs- und Integrationsmöglichkeiten, darunter lokale Benutzerkonten sowie LDAP- und OIDC-basierte Anmeldungen.
Für produktive Umgebungen sollte eine starke Authentifizierung vorgesehen werden.
Rollenbasierte Berechtigungen
Mit rollenbasierten Berechtigungen lassen sich administrative Aufgaben unterschiedlichen Benutzergruppen zuordnen.
Beispielsweise können Administratoren umfassende Verwaltungsrechte erhalten, während andere Benutzer lediglich bestimmte Systeme betrachten dürfen.
Das Ziel besteht darin, unnötig weitreichende Berechtigungen zu vermeiden.
Verschlüsselte Kommunikation
Administrative Verbindungen sollten grundsätzlich verschlüsselt erfolgen.
Das betrifft sowohl den Browserzugriff auf PegaProx als auch die Kommunikation mit den Proxmox-Systemen.
Bei der Verwendung eines Reverse Proxys muss außerdem darauf geachtet werden, dass WebSocket-Verbindungen korrekt und sicher weitergeleitet werden.
Protokollierung
Administrative Tätigkeiten sollten nachvollziehbar dokumentiert werden.
Hierzu gehören insbesondere Anmeldungen, Änderungen an Konfigurationen und sicherheitsrelevante Verwaltungsaktionen.
Für größere Umgebungen kann die Weiterleitung entsprechender Ereignisse an eine zentrale Protokollierungs- oder SIEM-Plattform sinnvoll sein.
Absicherung des Betriebssystems
Auch das Betriebssystem, auf dem PegaProx ausgeführt wird, muss abgesichert werden.
Dazu gehören regelmäßige Sicherheitsupdates, restriktive Firewall-Regeln, minimale Benutzerrechte und die Überwachung der Systemintegrität.
Die Verschlüsselungs- und Authentifizierungsmechanismen von PegaProx ersetzen diese grundlegenden Maßnahmen nicht.
Hochverfügbarkeit von PegaProx
Bei einer zentralen Verwaltungsplattform stellt sich zwangsläufig die Frage nach der Hochverfügbarkeit.
Was passiert, wenn der PegaProx-Server ausfällt?
Zunächst muss zwischen zwei unterschiedlichen Arten von Hochverfügbarkeit unterschieden werden.
Hochverfügbarkeit der virtuellen Maschinen
Die eigentlichen virtuellen Maschinen und Container werden weiterhin von Proxmox betrieben.
Ihre Verfügbarkeit hängt deshalb in erster Linie von der Proxmox-Infrastruktur ab.
Dazu gehören beispielsweise Cluster-Quorum, Storage-Verfügbarkeit, Netzwerkverbindungen und die Proxmox-HA-Konfiguration.
Ein Ausfall von PegaProx führt nicht automatisch zu einem Ausfall dieser Systeme.
Hochverfügbarkeit der Managementplattform
Anders verhält es sich mit der zentralen Verwaltungsoberfläche.
Fällt eine einzelne PegaProx-Instanz aus, können Administratoren nicht mehr über diese Instanz auf die zentrale Verwaltung zugreifen.
Seit PegaProx 1.3.0 gibt es hierfür eine eigene Hochverfügbarkeitsarchitektur.
Nach der Release-Dokumentation können bis zu vier PegaProx-Instanzen zu einer Gruppe zusammengefasst werden.
Dabei übernimmt eine Instanz die Rolle des Leaders, während weitere Instanzen als Mitglieder oder Standbys betrieben werden können.
Die Konfigurationsinformationen werden zwischen den Instanzen synchronisiert.
Wichtig ist allerdings, dass in Version 1.3.0 die automatische Übernahme der Leader-Rolle noch nicht aktiviert war. Ein Administrator musste den Wechsel veranlassen.
Eine solche Architektur verbessert die Verfügbarkeit der Managementebene, ersetzt aber keine sorgfältige Planung der darunterliegenden Infrastruktur.
Empfehlungen für produktive Umgebungen
Für einen zuverlässigen Betrieb sollten mehrere Punkte berücksichtigt werden.
Die PegaProx-Instanz sollte möglichst unabhängig von denjenigen Systemen betrieben werden, die sie verwaltet.
Besonders kritisch wäre eine Situation, in der die einzige Verwaltungsplattform auf einem ausgefallenen Cluster läuft und deshalb nicht mehr zur Fehlerbehebung erreichbar ist.
Zusätzlich sollten ein Wiederherstellungskonzept, aktuelle Konfigurationssicherungen und alternative administrative Zugriffswege vorhanden sein.
Auch bei einem Ausfall von PegaProx muss es möglich bleiben, die Proxmox-Hosts direkt zu administrieren.
Skalierung bei größeren Virtualisierungsumgebungen
Neben der Hochverfügbarkeit spielt die Skalierung eine wichtige Rolle.
In kleinen Umgebungen mit wenigen Hosts und virtuellen Maschinen ist der Ressourcenbedarf einer zentralen Managementplattform meist überschaubar.
Mit zunehmender Anzahl angebundener Cluster steigen allerdings die Anforderungen.
PegaProx muss dann mehr Zustandsinformationen verarbeiten, zusätzliche API-Verbindungen verwalten und gegebenenfalls mehr gleichzeitige Benutzer bedienen.
Einflussfaktoren auf die Performance
Der tatsächliche Ressourcenbedarf hängt von verschiedenen Faktoren ab.
Dazu gehören die Anzahl der angebundenen Hosts, die Menge der virtuellen Maschinen und Container, die Häufigkeit der Statusabfragen sowie die Anzahl gleichzeitiger administrativer Sitzungen.
Auch aktivierte Hintergrundaufgaben, Monitoringfunktionen und Protokollierung können den Ressourcenverbrauch beeinflussen.
Vertikale Skalierung
Eine Möglichkeit besteht darin, der PegaProx-Instanz zusätzliche CPU- und Arbeitsspeicherressourcen bereitzustellen.
Dadurch können größere Arbeitslasten verarbeitet werden, sofern die Anwendung und ihre internen Komponenten davon profitieren.
Horizontale Skalierung
Bei der horizontalen Skalierung werden mehrere Instanzen eingesetzt.
Die Hochverfügbarkeitsfunktionen von PegaProx bieten hierfür eine Grundlage.
Allerdings sollte nicht davon ausgegangen werden, dass beliebig viele Instanzen hinter einem Load Balancer betrieben werden können.
Insbesondere Datenhaltung, Zustandsverwaltung, Hintergrundaufgaben und administrative Schreibzugriffe müssen koordiniert werden.
Die dokumentierte HA-Architektur verwendet deshalb ein Leader-Modell und keine uneingeschränkt aktive Multi-Master-Datenhaltung.
Monitoring der Managementplattform
Auch PegaProx selbst sollte überwacht werden.
Wichtige Messgrößen sind beispielsweise:
- CPU- und Arbeitsspeicherauslastung
- Verfügbarkeit der Weboberfläche
- Antwortzeiten der API
- Fehler bei der Kommunikation mit Proxmox
- Auslastung des Datenträgers
- Zustand der Datenbank
- Fehlgeschlagene Hintergrundaufgaben
- Fehlerhafte Authentifizierungsversuche
- Zustand der HA-Mitglieder
Die Überwachung sollte möglichst durch ein unabhängiges Monitoring-System erfolgen.
Dadurch lassen sich Störungen auch dann erkennen, wenn PegaProx selbst nicht mehr erreichbar ist.
Praxisbeispiel: PegaProx für mehrere Proxmox-Cluster
Betrachten wir eine typische mittelgroße IT-Infrastruktur.
Ein Unternehmen betreibt drei unabhängige Proxmox-Cluster.
Der erste Cluster enthält die produktiven Server, der zweite dient als Test- und Entwicklungsumgebung und der dritte befindet sich an einem zweiten Standort.
Die zentrale IT-Abteilung möchte alle drei Umgebungen über PegaProx verwalten.
Dafür wird eine eigenständige PegaProx-Instanz im Management-Netz eingerichtet.
Diese erhält über die Firewall Zugriff auf die Proxmox-API der jeweiligen Hosts.
Für die Anbindung werden dedizierte technische Zugänge verwendet.
Die Administratoren greifen ausschließlich über eine verschlüsselte Verbindung auf die PegaProx-Weboberfläche zu.
Zusätzlich werden administrative Aktivitäten protokolliert und die Konfigurationsdaten regelmäßig gesichert.
Die drei Proxmox-Cluster bleiben dabei technisch unabhängig.
Ein Problem im Testcluster führt somit nicht automatisch zu einer Störung des Produktivclusters.
Gleichzeitig erhält die zentrale IT-Abteilung eine gemeinsame Verwaltungsoberfläche.
Besonderheiten für Behörden
In Behörden oder kommunalen Rechenzentren kann ein vergleichbarer Aufbau sinnvoll sein.
Allerdings müssen dabei zusätzliche Anforderungen berücksichtigt werden.
Insbesondere bei unterschiedlichen Schutzbedarfen darf die zentrale Managementplattform nicht dazu führen, dass bisher getrennte Sicherheitsbereiche unkontrolliert miteinander verbunden werden.
Eine mögliche Lösung besteht darin, PegaProx ausschließlich in einem besonders geschützten administrativen Netzwerksegment zu betreiben.
Zugriffe auf die Proxmox-Hosts erfolgen dann über gezielt freigegebene Verbindungen.
Darüber hinaus sollten administrative Berechtigungen, Protokollierung, Notfallzugriffe und Wiederherstellungsverfahren verbindlich dokumentiert werden.
Gerade im Zusammenhang mit NIS-2, BSI IT-Grundschutz und ISO 27001 ist entscheidend, dass die Architektur nicht nur technisch funktioniert, sondern auch nachvollziehbar abgesichert und organisatorisch beherrschbar ist.
Die Architektur entscheidet über den sicheren Betrieb
PegaProx ist weit mehr als eine zusätzliche Weboberfläche für Proxmox.
Die Plattform stellt eine eigenständige Managementebene bereit, die mehrere Virtualisierungsumgebungen über APIs und ergänzende Kommunikationswege miteinander verbindet.
Das Backend verarbeitet administrative Aktionen, die Weboberfläche stellt eine zentrale Bedienoberfläche bereit und die eigene Datenhaltung speichert wichtige Konfigurationsinformationen.
Dadurch entstehen neue Möglichkeiten für die übergreifende Verwaltung mehrerer Proxmox-Cluster.
Gleichzeitig erhöht sich jedoch die Bedeutung der Managementplattform für die gesamte IT-Infrastruktur.
Besonders wichtig sind deshalb eine sichere Netzwerkarchitektur, restriktive Berechtigungen, verschlüsselte Kommunikation, regelmäßige Backups und eine zuverlässige Überwachung.
Auch die Hochverfügbarkeit von PegaProx selbst sollte bei größeren Umgebungen berücksichtigt werden.
Die wichtigste Erkenntnis lautet: Je mehr Virtualisierungscluster zentral verwaltet werden, desto wichtiger wird die Absicherung der zentralen Managementebene.
Im nächsten Teil unserer Serie werden wir PegaProx praktisch installieren. Dabei richten wir die Plattform mit Docker und Docker Compose ein, konfigurieren persistente Daten und überprüfen anschließend den ersten Zugriff auf die Weboberfläche.
