Grafisches Interface: Bareos WebUI ACLs

Bareos hat ein grafisches Werkzeug zur Kommunikation mit dem Bareos Director. Das WebUI ist mehrsprachig und bietet detaillierte Informationen zu Backup-Jobs, Clients, FileSets, Pools, Volumes, Logs und mehr. Auch das Sichern und Wiederherstellen ist über das Webinterface möglich. In unserer mehrteiligen Serie stellen wir die grafische Schnittstelle ausführlich vor und verraten Tipps und Tricks. In dieser dritten Folge: ACLs (Access Control Lists).

Der erste Teil unserer Artikelserie über das Bareos-WebUI beschreibt die Installation und Konfiguration, der zweite Teil stellt die einzelnen Module genauer vor. In beiden Beiträgen haben wir die ACLs (Access Control Lists) kurz erwähnt: Sie regeln in sogenannten Profilen, was welcher Benutzer im WebUI sehen kann und ausführen darf.

Zur Erinnerung: Das WebUI hat keine eigene Benutzerverwaltung. Benutzeraccounts für den Zugriff auf das grafische Interface legen Sie im Bareos Director an, das heißt, Sie erzeugen eine Console-Resource. Dabei geben Sie auch immer eine Profile-Resource für den Account an.

Bareos WebUI: ACLs

Tipp: Bisher sind wir davon ausgegangen, dass Sie das Bareos WebUI und den Bareos Director auf demselben Rechner betreiben. Sie können das WebUI aber auch auf einem anderen Rechner installieren. Console– und Profile-Resource erzeugen Sie in diesem Fall auf dem Bareos Director; anschließend geben Sie in der bconsole das Kommando reload ein, um die veränderte Konfiguration neu einzulesen.

In diesem Artikel schauen wir genauer in die Konfigurationsdateien im Verzeichnis /etc/bareos/bareos-dir.d/profile und erklären, was es mit den dort verwendeten ACLs auf sich hat. Außerdem zeigen wir ein Beispiel aus der Praxis: Mit ACLs gibt ein Administrator zwei Benutzern im WebUI Zugriff auf unterschiedliche Kommandos und Backup-Jobs.

Aufbau und Syntax der Profildateien

Wenn Sie die mitgelieferten Profildateien webui-admin.conf (weitreichende Rechte), webui-readonly.conf (lesender Zugriff) und webui-limited.conf.example (Vorlage für eine Konfiguration mit eingeschränktem Zugriff ) betrachten, sehen Sie mehrere ACL-Direktiven, z. B. CommandACL (für Kommandos), JobACL (Zugriff auf Jobs), ScheduleACL (Zugriff auf Zeitpläne) usw.

Hinweis: Für den Parser, der die Konfigurationsdateien von oben nach unten und von links nach rechts einliest, spielt es keine Rolle, ob Sie ein Leerzeichen in den Namen der Direktiven verwenden oder nicht – Sie können also CommandACL oder Command ACL schreiben. Beim Einlesen entfernt der Parser die Leerzeichen.

Hinter dem Namen der Direktive steht ein Gleichheitszeichen, gefolgt von einer Liste von regulären Ausdrücken, die durch Kommata voneinander getrennt sind. Je nach ACL handelt es sich bei den regulären Ausdrücken um Ressource-Namen, Pfade oder Kommandos. Ein vorangestelltes Ausrufezeichen verbietet ein Kommando. Das Schlüsselwort *all* erlaubt uneingeschränkten Zugriff. Da die Reihenfolge eine Rolle spielt, gilt: erst negieren, dann erlauben. Das heißt, dass *all* beispielsweise am Ende der Liste steht.

Schauen wir uns die CommandACL-Direktive und die in dem Zusammenhang verwendeten Kommandos genauer an. Einige davon sind zwingend erforderlich, andere optional. Das Bareos-Handbuch listet alle Kommandos der einzelnen WebUI-Module in einer Tabelle auf und verrät, welche davon vorgeschrieben sind und welche nicht.

Einige Kommandos in den mitgelieferten Profildateien fangen mit einem Punkt an, z. B. .api, .clients und .help. Diese sogenannten Dot Commands sind interne API-Kommandos für Skripte oder Bareos-Interfaces, z. B. das WebUI oder die bconsole. Für diesen Artikel und die Definition der Zugriffsrechte im WebUI sind sie nicht relevant – achten Sie aber darauf, die Dot Commands nicht zu negieren oder auszuschließen. Andernfalls kann es sein, dass das WebUI nicht mehr korrekt arbeitet.

Beispiel aus der Praxis

Kommen wir zu einer praktischen Anwendung: Alice und Bob arbeiten beide in einem Unternehmen, in zwei verschiedenen Abteilungen A und B. Die beiden sollen die IT-Abteilung entlasten und Zugriff auf das Bareos WebUI erhalten. Dort erhalten Sie die Erlaubnis, die Backups ihrer jeweiligen Abteilung wiederherzustellen, nicht aber die Sicherungen der anderen Abteilungen. Außerdem sollen Alice und Bob Backup-Jobs über das Webinterface anstoßen (Kommando run) oder fehlgeschlagene Jobs von Hand neu starten können (rerun). Laufende Aufträge der jeweiligen Abteilung dürfen die beiden Mitarbeitenden abbrechen (cancel).

Dazu richtet der Administrator zuerst die beiden Console-Ressourcen für die Mitarbeitenden ein:

Console {
  Name = "alice"
  Password = "secret"
  Profile = "webui-user-department-a"
  TlsEnable = false
}
Console {
  Name = "bob"
  Password = "secret"
  Profile = "webui-user-department-b"
  TlsEnable = false
}

Beim Anlegen der Profil-Konfigurationsdateien achtet der Admin darauf, dass jede Abteilung ihren eigenen Speicherort für die Sicherungen (file-department-a und file-department-b) hat. Damit sind jeweils Pools verknüpft für Vollsicherungen, differenzielle und inkrementelle Backups. Außerdem stehen in Abteilung A und B jeweils 3 Clients, die gesichert werden. Für jeden File Daemon gibt es einen Backup Job und ein dazugehöriges Fileset.

Die Profildatei für Abteilung A sieht so aus:

Profile {
  Name = "webui-user-department-a"
  CommandACL = .api, .help, use, version, status, show
  CommandACL = list, llist
  CommandACL = run, rerun, cancel, restore
  CommandACL = .clients, .jobs, .filesets, .pools, .storages, .defaults, .schedule
  CommandACL = .bvfs_update, .bvfs_get_jobids, .bvfs_lsdirs, .bvfs_lsfiles
  CommandACL = .bvfs_versions, .bvfs_restore, .bvfs_cleanup
  JobACL = backup-department-a-host-1, backup-department-a-host-2, backup-department-a-host-3, RestoreFiles
  ScheduleACL = WeeklyCycle
  CatalogACL = MyCatalog
  PoolACL = department-a-full, department-a-diff, department-a-inc
  StorageACL = file-department-a
  ClientACL = department-a-host-1, department-a-host-2, department-a-host-3
  FilesetACL = fileset-department-a-host-1, fileset-department-a-host-2, fileset-department-a-host-3
  WhereACL = *all*
}

Das Profil für Abteilung B ist so eingerichtet:

Profile {
   Name = "webui-user-department-b"
   CommandACL = .api, .help, use, version, status, show
   CommandACL = list, llist
   CommandACL = run, rerun, cancel, restore
   CommandACL = .clients, .jobs, .filesets, .pools, .storages, .defaults, .schedule
   CommandACL = .bvfs_update, .bvfs_get_jobids, .bvfs_lsdirs, .bvfs_lsfiles
   CommandACL = .bvfs_versions, .bvfs_restore, .bvfs_cleanup
   JobACL = backup-department-b-host-1, backup-department-b-host-2, backup-department-b-host-3, RestoreFiles
   ScheduleACL = WeeklyCycle
   CatalogACL = MyCatalog
   PoolACL = department-b-full, department-b-diff, department-b-inc
   StorageACL = file-department-b
   ClientACL = department-b-host-1, department-b-host-2, department-b-host-3
   FilesetACL = fileset-department-b-host-1, fileset-department-b-host-2, fileset-department-b-host-3
   WhereACL = *all*
}

Bareos und PAM-Integration

Dank ACLs kann der Bareos-Administrator ganz genau regeln, wer was im Bareos WebUI sehen und ausführen darf. Gerade für größere Unternehmen ist das praktisch, mehrere administrative Benutzerkonten mit unterschiedlichen Berechtigungen einzurichten. Auf diese Weise erhalten Mitarbeiter aus verschiedenen Abteilungen über die grafische Schnittstelle Zugriff auf ihre eigenen Backups und Jobs.

Bareos kann aber noch mehr: Es kann nicht nur die eigene Authentisierung nutzen, sondern auch auf PAM (Pluggable Authentication Modules) zurückgreifen. So kann der Administrator eine größere Anzahl von WebUI-Accounts einrichten, ohne eigene Passwörter für Bareos pflegen zu müssen. Unser Handbuch erklärt die grundlegende Einrichtung. Ein GitHub-Artikel beschreibt außerdem, wie Sie Bareos so konfigurieren, dass Benutzer bei ihrer ersten WebUI-Anmeldung automatisch im Bareos Director angelegt werden – einmal eingerichtet sind keine manuellen Anpassungen mehr für neue Benutzer im Bareos-System erforderlich.

Hinweis: Beim Einsatz von PAM wird nur eine einzige Console-Resource verwendet. Die Pflege der Accounts findet über User-Resourcen statt. Das sind „abgespeckte“ Console-Resourcen, die ACL-Einstellungen enthalten, aber keine Einträge für das Password oder TLS.

Kommentar verfassen

Wir erfassen keine E-Mailadresse. Pflichtfelder sind mit * markiert.

Scroll to Top