Admin-Zugriff & Split-Container¶

Der Admin-Bereich (alles unter /admin) kann zusätzlich vom User-Portal getrennt werden, damit ein gestohlener Super-Admin-Account allein nicht reicht — der Angreifer muss zusätzlich Netzwerkzugang zur Admin-Topologie haben.

Drei Modi¶

Modus	Wer kommt rein	Aufwand	Wann sinnvoll
`unrestricted` (Default)	Jeder mit Login	keiner	Single-Person-Setup, kein erhöhter Threat
`ip_allowlist`	Nur IPs aus deiner CIDR-Liste	1 Setting	Office-IP / VPN-Subnet — ausreichend für die meisten Self-Hoster
`split_container`	Nur wer den Admin-Hostname / VPN / SSH-Tunnel erreicht	hoch	IT-Firmen mit vielen Endkunden

unrestricted und ip_allowlist werden direkt unter Admin → Zugriff → Zugriff (fortgeschrittener Tab neben Users/Rollen/Tenants/2FA) umgeschaltet. split_container richtet der Assistent auf derselben Seite ein (siehe unten).

Welche Adresse gehört in die Allowlist? Die, als die der Server dich sieht — der Reiter zeigt sie oben in der Liste („Der Server sieht dich als …") mit einem Knopf, der sie direkt einträgt. Bei einer Instanz im Internet ist das deine öffentliche Adresse, nicht die deines PCs im Heimnetz. Der nginx des Vesana-Stacks ist dabei immer vertrauenswürdig; läuft davor noch ein eigener Reverse-Proxy (zweiter nginx, Caddy, Traefik), trägst du dessen Netz unter Erweitert ein. Eine Liste, die dich selbst aussperren würde, wird nicht gespeichert, solange du das nicht ausdrücklich bestätigst.

Bis vor kurzem fragte der Erstinbetriebnahme-Wizard diesen Modus noch als eigenen Schritt ab. Er ist inzwischen aus dem Wizard entfernt — der sichere Default (unrestricted) greift beim ersten Start automatisch, und du stellst den gewünschten Modus jederzeit nachträglich unter Admin → Zugriff → Zugriff ein.

Split-Container — eigener Admin-Container¶

Wenn du „Eigener Container" wählst, läuft Vesana mit zwei API-Containern: einer bedient das User-Portal (ohne Admin-Funktionen), der andere den Admin-Bereich unter eigenem Hostnamen oder Port. Eingerichtet wird das über den Assistenten unter Admin → Zugriff → Eigener Container — es gibt nichts zu kopieren und keine Skripte, die du selbst pflegen müsstest.

So läuft der Assistent¶

Erkennen — der Assistent stellt fest, ob der nginx des Vesana-Stacks selbst TLS terminiert oder ob davor ein eigener Reverse-Proxy sitzt (er vergleicht dafür das Zertifikat auf Port 443 mit dem des Stacks). Außerdem prüft er, ob Compose-Datei und Images aktuell genug sind — sonst geht es hier gar nicht erst weiter.
Adresse — Subdomain (admin.<host>, empfohlen), eigener Port oder beides. DNS-Prüfung und Vorschlag für die Cookie-Domain inklusive.
Aufbauen — Vesana richtet den Admin-Container ein und prüft ihn intern. Am laufenden Betrieb ändert sich dabei nichts; der Admin-Bereich bleibt wie bisher erreichbar. Schlägt ein Schritt fehl, wird alles zurückgebaut und der Grund steht im Klartext da.
Prüfen — was Handarbeit bleibt (bei einem Reverse-Proxy davor: ein Vhost, den du als Skript bekommst; ein Zertifikat für den Admin-Namen) und die Erreichbarkeitsprobe aus deinem Browser und vom Server. Erst wenn eine davon den Admin-Container erreicht, geht es weiter.
Umstellen — jetzt erst wird der Modus gesetzt und der Haupt-Container ohne Admin-Funktionen neu gestartet (das User-Portal ist dabei rund eine halbe Minute weg). Danach ist der Admin-Bereich nur noch über die neue Adresse erreichbar.

Sicherung: Nach dem Umstellen läuft eine Frist von 30 Minuten. Meldest du dich in dieser Zeit nicht über den Admin-Host an (der Zugriffs-Reiter dort bestätigt automatisch), nimmt Vesana die Umstellung von selbst zurück — niemand bleibt ausgesperrt. Schlägt der Neustart fehl, ebenfalls.

Die drei Setup-Profile¶

Profil	Woran der Assistent es erkennt	Was automatisch geht	Was du machst
Stack-nginx terminiert TLS selbst (Standard)	Port 443 zeigt das Stack-Zertifikat	alles bis zur Umstellung	ein Zertifikat, das den Admin-Namen mit deckt (Schritt 4 zeigt den Weg mit certbot und den echten Pfaden) — ohne warnt der Browser nur
Reverse-Proxy davor (nginx, Caddy, Traefik …)	Port 443 zeigt ein anderes Zertifikat als der Stack	der Stack-Anteil komplett	den Proxy-Vhost für den Admin-Namen anlegen — Schritt 4 liefert das nginx-Skript mit dem richtigen Stack-Port; Caddy/Traefik sinngemäß
Kein Compose	kein Compose-Stack	nichts	zweiten API-Prozess mit `VESANA_API_MODE=admin` selbst betreiben

Liegt die Erkennung daneben, kannst du das Profil in Schritt 1 überschreiben.

Zurück¶

Vor der Umstellung: Karte „Eigener Admin-Container" im Zugriffs-Reiter → Aufbau abbrechen.
In der Frist: Umstellung zurücknehmen — geht auch vom User-Portal aus.
Danach: Deaktivieren — nur über den Admin-Host. Vom User-Portal aus lässt sich ein bestätigter Split nicht aufheben; genau das ist der Schutz.
Über die Modus-Karten: „Unbeschränkt" oder „IP-Allowlist" wählen und Speichern baut einen aktiven Split genauso komplett zurück; Zielmodus ist die gewählte Karte. Ein bloßer Aufbau wird dabei abgeräumt.
Notfall: docker compose exec api python -m api.app.cli.admin_recovery reset-mode unrestricted im Vesana-Verzeichnis stellt den Modus sofort zurück; danach im Zugriffs-Reiter Deaktivieren, damit auch die Container zurückgebaut werden.

Was auf welchem Host läuft¶

Nach der Umstellung bedienen beide Adressen dieselbe Instanz, aber nicht dieselben Funktionen:

	User-Portal	Admin-Host
Geräte, Checks, Alarmierung, Karten, Berichte	ja	ja
Mandanten anlegen, umbenennen, kopieren, löschen	ja (mit den nötigen Rechten)	ja
Benutzer, Rollen, Updates, alles unter `/admin`	nein — der Hinweis führt mit einem Link ins Admin-Portal	ja

Ruft das User-Portal eine reine Verwaltungs-Route auf, antwortet Vesana mit einer klaren Meldung samt Code statt mit „Method not allowed" (bis v1.9.447 war genau das der Fehler beim Anlegen eines Mandanten).

Der Weg zurück steht im Admin-Portal an zwei Stellen: die Admin-Anmeldeseite verlinkt die normale Benutzer-Anmeldung, und die Seitenleiste bietet neben „Abmelden" auch „Zurück zum User-Portal".

Agent- und Collector-Installationsbefehle im User-Portal tragen im getrennten Betrieb wieder Gateway-Adresse und Zertifikats-Fingerabdruck; Portal-Layout, Lizenz-Hinweise und Discovery-Vorgaben wirken dort ebenfalls.

Hinweise¶

Cookie-Domain: der Assistent schlägt die engste gemeinsame Domain vor (admin.app.example.com unter app.example.com ⇒ app.example.com), damit die Anmeldung auf beiden Adressen gilt und nicht mit anderen Diensten derselben Zone geteilt wird. Leer lassen heißt: auf dem Admin-Host neu anmelden.
Eigener Port statt Subdomain: Browser trennen Cookies nicht nach Port — der Admin-Bereich ist dann nur durch die Berechtigungsprüfung geschützt, nicht durch den Browser-Origin. Für Instanzen, die nur per IP erreichbar sind, ist das trotzdem der einzige Weg.

Weiterführend¶

Permissions: Rollen & Permissions — wie die fein-granularen audit_log.view_* / trash.view_*-Stufen mit den Zugriffsmodi zusammenwirken.
2FA: 2FA — zusätzliche Schutzschicht auf Ebene der einzelnen User statt des ganzen Admin-Bereichs.