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.
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.