Zum Inhalt

Rollen & Permissions

Vesana nutzt rollenbasierte Zugriffssteuerung (RBAC). Jede Rolle ist eine Menge von Permissions — ein Permission ist ein einzelnes Recht-Bit wie host.create, alert_rule.edit, ai.query.

Default-Rollen

Mitgeliefert:

Rolle Wer Wofür
super_admin dein Setup-Team sieht alle Tenants, kann alles
tenant_admin Kunden-Verantwortlicher sieht nur eigenen Tenant, kann alles im Tenant
operator NOC, Support-Team Read + Ack + Downtime, keine Admin-Operationen
viewer Endkunde, Stakeholder Read-Only

Bestehen kannst du diese editieren oder neue Rollen anlegen. Default-Rollen sollten nicht gelöscht werden — sie sind die Fallbacks für neue User.

Custom Roles (Pro+)

/admin/roles → Neu:

Feld Bedeutung
Name beliebig
Beschreibung optional
Permissions Multi-Select aus der Liste
Tenant-Scope nur eigener Tenant / cross-tenant

Beispiele für sinnvolle Custom-Rollen:

  • Auditor — audit.view, audit.export, sonst nichts
  • Read-Only Manager — alle *.view-Permissions plus report.view, dashboard.view
  • Push-Tester — notification_channel.test, sonst nichts

Permission-Matrix (Auswahl)

Permission Bedeutung
host.view / .create / .edit / .delete Hosts
host_service.view / .create / .edit / .delete / .ack Host-Services
profile.view / .create / .edit / .delete Profile
tenant.view / .create / .edit / .delete / .cross_view Tenants
user.view / .create / .edit / .delete / .invite User
role.view / .create / .edit / .delete Rollen
alert_rule.view / .create / .edit / .delete / .test Alert-Rules
notification_channel.view / .create / .edit / .delete / .test Channels
dashboard.view / .create / .edit / .delete / .publish Dashboards
wiki.view / .create / .edit / .delete / .purge Wiki
script.view / .create / .edit / .delete Monitoring-Scripts
discovery.view / .scan / .import Discovery
audit.view / .export / .purge Audit-Log
trash.view / .restore / .purge Papierkorb
report.view / .create / .schedule / .template_upload Reports
sla.view / .export SLA
downtime.view / .create / .edit / .delete Downtimes
ai.query / .analyze / .config AI-Features
status_page.view / .edit / .publish Status-Pages
system.health / .tune / .update System-Verwaltung (Super-Admin)
license.view / .activate Lizenz-Management
mobile_push.send_test / .manage_devices Push-Verwaltung

Vollständige Liste: /admin/roles/permissions — wird code-generiert aus shared/permissions/registry.py.

Feature-Sichtbarkeit

Permissions steuern nicht nur API-Zugriff, sondern auch UI-Sichtbarkeit. Beispiele:

  • Ohne ai.query: Chat-Widget unsichtbar
  • Ohne alert_rule.view: Menüpunkt „Alert-Rules" weg
  • Ohne report.view: Reports-Sektion weg

Implementierung: frontend/src/lib/permissions.ts mit useHasPermission()-Hook. Kombiniert mit useAiVisible() etc. für komplexere Fälle.

Rollen-Zuweisung

Pro User eine Hauptrolle. Plus optional:

  • Tenant-spezifische Rollen für Cross-Tenant-Setups (Super-Admin als Operator in Tenant A, Viewer in Tenant B)

Aktuelle Beschränkung: nur eine Rolle pro User — keine Stack-Rollen. Wenn du mehrere Verantwortungsbereiche brauchst, lege eine Custom-Rolle mit der Vereinigung an.

Audit-Trail

Permission-Änderungen sind im Audit-Log mit Diff sichtbar. „Wer hat dem User X die host.delete-Permission gegeben?" — Filter target_kind = role.

Permission-Engineering — Tipps

  • Wenig ist mehr — überlege pro Rolle, was wirklich gebraucht wird, und lass den Rest weg
  • *.view von *.create trennen — viele User brauchen nur Lesen
  • AI-Permissions selektiv — ai.query für wenige Pilot-User aktivieren, dann ausweiten
  • audit.view nur für Audit-Funktion — der Audit-Log enthält viel Detail, nicht für jeden interessant

Anschluss