Rollen & Permissions¶
Vesana nutzt rollenbasierte Zugriffssteuerung (RBAC). Jede Rolle ist eine Menge von Permissions — ein Permission ist ein einzelnes Recht-Bit wie hosts.create, alert_rules.edit, ai.query.
Deny-by-default: Eine neue Custom-Rolle startet mit einer leeren Permission-Liste — nichts ist automatisch erlaubt. Jedes Recht muss explizit vergeben werden. Nur der Super-Admin ist eine Ausnahme: er umgeht die Permission-Prüfung komplett (Code-Ebene, nicht über eine Permission-Liste).
Default-Rollen¶
Mitgeliefert, vier Stück:
| Rolle | Wer | Wofür |
|---|---|---|
| Super Admin | dein Setup-Team | Vollzugriff auf alle Tenants und alle Funktionen — auch die, die keine eigene Permission haben (Rollen- und Tenant-Verwaltung, trash.view_global, audit_log.view_global) |
| Admin | Tenant-Verantwortlicher | Alles innerhalb des eigenen Tenants außer harten Super-Admin-only-Rechten (Rollen zuweisen, endgültig löschen, globale Sicht auf Papierkorb/Audit) |
| Operator | NOC, Support-Team | Lesen + Alerts bearbeiten (ACK/close), Downtimes anlegen, „Jetzt prüfen", Updates verschieben, Dashboards/Wiki/Icons bearbeiten — keine Admin-Operationen |
| Viewer | Endkunde, Stakeholder | Reine Lesesicht, plus eigene Saved-Filters. Kein ACK, keine Downtimes, kein „Jetzt prüfen" — wer das braucht, bekommt Operator oder eine Custom-Rolle |
Änderungen an den Standardrollen
Seit v1.9.350 verlangen Quittieren (alerts.acknowledge) und Wartungsfenster (downtimes.create/.edit) ihre Berechtigung wirklich — Viewer konnten das vorher trotz fehlendem Recht. Ab v1.9.437 gilt dasselbe für „Jetzt prüfen" (check_results.reschedule), für Sammel-Löschen von Checks (services.delete) und für Anomalie-Einstellungen (hosts.edit); Geräte- und Check-Daten lesen setzt hosts.view bzw. services.view voraus (in allen Standardrollen enthalten). Die eingebaute Admin-Rolle bekommt neue Berechtigungs-Bereiche beim Start automatisch nachgereicht; bewusst entfernte Einzelrechte bleiben weg.
Du kannst diese editieren oder neue Rollen anlegen. Die vier Default-Rollen sollten nicht gelöscht werden — sie sind die Fallbacks für neue User.
Custom Roles¶
Admin → Zugriff → Rollen → Neu:
| Feld | Bedeutung |
|---|---|
| Name | beliebig |
| Beschreibung | optional |
| Permissions | Multi-Select aus der Liste, leer startend (deny-by-default) |
Beispiele für sinnvolle Custom-Rollen:
- Auditor — nur
audit_log.view_tenant, sonst nichts - Read-Only Manager — alle
*.view-Permissions plusreports.view,dashboards.view - Push-Tester — nur
notifications.view+notifications.create, sonst nichts
Permission-Kategorien (Auswahl)¶
Permissions folgen dem Muster ressource.aktion. Auswahl der wichtigsten Kategorien:
| Kategorie | Permissions | Bedeutung |
|---|---|---|
| Hosts | hosts.view / .create / .edit / .delete |
Hosts anlegen/bearbeiten |
| Services | services.view / .create / .edit / .delete |
Host-Services (Checks) |
| Dashboards | dashboards.view / .create / .edit / .delete |
Custom Dashboards + Status-Pages |
| Sites | sites.view / .manage |
Standorte (physische Karten) |
| Alert Rules | alert_rules.view / .create / .edit / .delete |
Alert-Regeln |
| Notifications | notifications.view / .create / .edit / .delete |
Notification-Channels |
| Downtimes | downtimes.view / .create / .edit / .delete |
Wartungsfenster |
| Alerts | alerts.view / .acknowledge / .close |
Laufende Probleme bearbeiten |
| Check-Ergebnisse | check_results.view / .reschedule |
Historie + „Jetzt prüfen" / „Agent jetzt erheben" |
| Updates | updates.defer / .decline / .install_now |
Automatische Updates verschieben (Operator), ablehnen bzw. sofort installieren (Admin) |
| Zugangsdaten | credentials.manage |
Zugangsdaten-Sets des Tenants anlegen/ändern (lesen reicht hosts.view) |
| Collectors / Agents | collectors.*, agents.view / .manage |
Erfassungs-Infrastruktur |
| Profile | profiles.view / .create / .edit / .delete |
Geräteprofile |
| Monitoring-Scripts | monitoring_scripts.view / .create / .edit / .delete |
Custom-Scripts |
| Reports | reports.view / .export / .delete |
Reporting |
| Audit-Log | audit_log.view (Alias) / .view_own / .view_tenant / .view_global |
Wer sieht wie viel vom Änderungsverlauf |
| System-Log | system_log.view (Alias) / .view_own / .view_tenant / .view_global |
Diagnose-Log-Sichtbarkeit |
| Users | users.view / .invite / .edit_role |
Benutzerverwaltung |
| Papierkorb | trash.view (Alias) / .view_own / .view_tenant / .view_global / .restore / .purge |
Papierkorb-Sichtbarkeit + Aktionen |
| Backup | backup.export |
Backup herunterladen (Restore bleibt hart Super-Admin-only) |
| Wiki | wiki.view / .create / .edit / .delete |
Knowledge-Base |
| AI | ai.query / .analyze |
KI-Features |
| Icons | icons.view / .upload / .assign / … |
Icon-Verwaltung |
| Discovery | discovery.manage_settings |
Auto-Discovery-Plattform-Defaults |
Die vollständige, aktuelle Liste zeigt dir der Rollen-Editor selbst beim Anlegen einer Custom-Rolle.
Fein-granulare Sichtbarkeits-Stufen (Audit-Log, System-Log, Papierkorb)¶
Diese drei Bereiche kennen jeweils drei Sichtbarkeits-Stufen statt nur Ja/Nein:
.view_own— nur eigene Aktionen/Einträge.view_tenant— alles im eigenen Tenant.view_global— tenant-übergreifend (Super-Admin-only)
Der alte, gröbere Alias (z. B. trash.view) funktioniert für bestehende Custom-Rollen weiterhin und verhält sich wie .view_own — neue Rollen legst du direkt mit der passenden Stufe an.
Feature-Sichtbarkeit¶
Permissions steuern nicht nur API-Zugriff, sondern auch UI-Sichtbarkeit. Beispiele:
- Ohne
ai.query: Chat-Widget unsichtbar - Ohne
alert_rules.view: Menüpunkt „Alert-Rules" weg - Ohne
reports.view: Reports-Sektion weg
Rollen-Zuweisung¶
Pro User eine Hauptrolle. Der Tenant-Zugriff (welche Tenants ein User überhaupt sieht) ist davon getrennt geregelt — siehe Users & Tenants.
Aktuelle Beschränkung: nur eine Rolle pro User — keine Stack-Rollen. Wenn du mehrere Verantwortungsbereiche brauchst, lege eine Custom-Rolle mit der Vereinigung der benötigten Permissions an.
Audit-Trail¶
Permission-Änderungen sind im Audit-Log mit Diff sichtbar. „Wer hat dem User X welche Permission gegeben?" — im Audit-Log nach dem betroffenen Ziel filtern.
Permission-Engineering — Tipps¶
- Wenig ist mehr — überlege pro Rolle, was wirklich gebraucht wird, und lass den Rest weg
*.viewvon*.create/*.edit/*.deletetrennen — viele User brauchen nur Lesen- AI-Permissions selektiv —
ai.queryfür wenige Pilot-User aktivieren, dann ausweiten audit_log.view_tenant/system_log.view_tenantnur für Audit-Funktion — viel Detail, nicht für jeden interessant.view_global-Stufen bleiben Super-Admin vorbehalten — sie sind cross-tenant und gehören bewusst nicht in Standard-Custom-Rollen
Anschluss¶
- Users & Tenants
- Papierkorb — Details zu den fein-granularen Papierkorb-Permissions