Benutzer und Rollen

Envoryx ist nicht auf ein Konto beschränkt. Die Einrichtungsseite legt den ersten Admin an, alle anderen kommen über eine Einladung dazu: Einstellungen → Benutzer → Benutzer einladen, ein Name und eine Rolle. Envoryx zeigt dir dann einen Link, der einmal innerhalb von 48 Stunden funktioniert. Es verschickt keine Mail, du gibst den Link also selbst weiter, und kopier ihn gleich, denn er wird nur dieses eine Mal angezeigt. Wer ihn öffnet, setzt ein Passwort (mindestens 10 Zeichen) und ist angemeldet. Hat jemand sein Passwort vergessen, gibt Passwort zurücksetzen an seinem Benutzer einen neuen Link aus.

Die Rollen

Rolle	Darf
Betrachter	ansehen: Projekte, Status, Logs, Statistiken, Backups
Entwickler	mit Projekten arbeiten: starten, stoppen, neu starten, Terminal, Aktionen, Git, Backups, Datenbanken, Domains, Addons, SSH/SFTP
Admin	alles: Projekte anlegen und löschen, Einstellungen, TLS, Instanz-Backups, Benutzer
Kein Zugriff	nichts, außer in den Projekten, in denen der Benutzer eine eigene Rolle hat

Sie entsprechen den Token-Scopes read, operate und admin. Mit Projekte an einem Benutzer gibst du ihm in bestimmten Projekten eine andere Rolle, und die ersetzt dort die globale: Wer überall Betrachter ist, kann in einem Shop Entwickler sein, und ein Entwickler kann auf die Produktionskopie gar keinen Zugriff haben. Ein Admin bleibt in jedem Projekt Admin. Ein Projekt, auf das jemand keinen Zugriff hat, gibt es für ihn schlicht nicht. Es fehlt in den Listen und auf dem Dashboard, und API, MCP und SSH lehnen es ab. Wer nur einige Projekte hat, sieht auf dem Dashboard auch nur deren Probleme und Ressourcenverbrauch, und die Zahl der verwaisten Ressourcen bekommen nur Admins der Instanz zu sehen. Projekte, Kopien und Branch-Umgebungen anlegen darf nur ein Admin der ganzen Instanz.

In der Einladung ist die Rolle Kein Zugriff - nur die unten freigegebenen Projekte die richtige für eine Kundin oder einen Freelancer, die ein, zwei Projekte sehen sollen und sonst nichts. Der Dialog fragt allerdings nur nach Name und Rolle; die Projekte kommen danach. Sobald der Benutzer in der Liste steht, öffnest du an ihm Projekte und wählst je Projekt eine Rolle. Bis dahin meldet er sich bei einer leeren Projektliste an.

Branch-Umgebungen tauchen in dieser Liste nicht auf. Sie haben keine eigenen Rollen: Wer am Eltern-Projekt eine Rolle hat, hat dieselbe an all seinen Umgebungen, und Envoryx schaut das bei jeder Prüfung nach. Eine Rolle, die du später am Eltern-Projekt vergibst oder änderst, oder ein neues Teammitglied erreicht also auch die Umgebungen, die es schon gibt.

Was jede Rolle sieht

Die Oberfläche lässt weg, was deine Rolle nicht darf. Betrachter sehen keine Knöpfe zum Starten, Wiederherstellen oder Löschen, und Formulare, die sie nur lesen dürfen, erscheinen schreibgeschützt. Wer kein Admin ist, hat unter Einstellungen nur Mein Konto, und die Seite Docker und Neues Projekt fehlen; wer /docker oder /projects/new direkt aufruft, landet in der Projektliste. Das Ausblenden ist aber nur Höflichkeit, nicht der Schutz. Der Server prüft jede Anfrage selbst.

Die kleinen Einblendungen für laufende Vorgänge (Anlegen, Kopieren, Backups und so weiter) melden nur, was du selbst gestartet hast, in jedem deiner Browser. Admins sehen außerdem, was Envoryx von selbst tut, etwa geplante Backups. Was jemand anderes an einem Projekt macht, siehst du weiterhin in der Zeile und auf der Seite des Projekts, du merkst also, wenn eine Kollegin gerade den Shop wiederherstellt, den du öffnen willst.

Geheime Variablen bleiben unterhalb von Entwickler geheim: Betrachter und read-Tokens bekommen ihre Werte nie, weder in der Projektliste noch in der Projektansicht oder auf dem Dashboard. Dasselbe gilt für die Zugangsdaten der Dienste, etwa die Schlüssel des Objektspeichers, das RabbitMQ-Passwort und die Keys der Suchmaschinen. Wie Datenbank-Passwörter bekommt sie nur, wer das Projekt bedienen darf. Der Datenbank-Browser hält es genauso: Er öffnet nur die Datenbanken der Projekte, die du bedienen darfst.

Deaktivieren und Single Sign-on

Deaktivieren an einem Benutzer beendet seine Sitzungen und legt seine API-Tokens und SSH-Schlüssel still, bis du ihn wieder aktivierst. Niemand kann sich selbst deaktivieren oder löschen, und den letzten Admin, der sich noch anmelden kann, kannst du weder herabstufen noch deaktivieren oder löschen. So sperrst du nicht aus Versehen alle aus.

Betreibst du schon Authentik, Keycloak, Authelia oder einen anderen OpenID-Connect-Anbieter, lässt Einstellungen → Benutzer → Single Sign-on (OpenID Connect) die Leute darüber anmelden, und die Gruppen des Anbieters können ihre Rollen setzen. Rollen in einzelnen Projekten setzt du immer in Envoryx.

Ein bestehendes Envoryx-Konto wird nur über seinen Einladungslink mit dem Anbieter verbunden: Schick der Person eine Einladung (oder einen Link zum Zurücksetzen des Passworts), und sie wählt auf dieser Seite Stattdessen mit … anmelden. Envoryx verknüpft dann das Anbieter-Konto, mit dem sie sich anmeldet, mit diesem Envoryx-Konto. Eine Anmeldung auf der Login-Seite verknüpft nie ein Konto über seinen Namen, denn Namen beim Anbieter kann sich jeder aussuchen.

Das Client-Secret wird gespeichert und nie wieder angezeigt. Bleibt das Feld leer, bleibt es erhalten, auch wenn du Single Sign-on abschaltest. Um es loszuwerden, setz den Haken bei Gespeichertes Client-Secret beim Speichern entfernen.