Ich möchte heute auf die verschiedenen Möglichkeiten eingehen, in Icinga Web 2 zu steuern wer was sieht und machen darf. Gerade in Unternehmen mit vielen Mitarbeitern oder einem großen Kundenkreis ist dies von essentieller Bedeutung für die Antwort auf die Frage, ob man Icinga Web 2 produktiv einsetzen kann, oder nicht. Da wir uns nun langsam auf den ersten Release Candidate hinzu bewegen, soll dieser Eintrag auch dazu dienen, zu präsentieren was in dieser Hinsicht noch zu erwarten ist.
Das Gruppen-/Rollen-Konzept
Erst einmal etwas zur Grundlage. Wer bereits weiß was der Titel verheißt, darf gerne direkt zum nächsten Abschnitt springen. In Icinga Web 2 gibt es Benutzer (Nicht zu verwechseln mit Icinga’s Kontakten. Von Icinga Web 2’s Benutzern weiß nur Icinga Web 2 etwas!) die sich auf verschiedenen Wegen anmelden können. (Basic-Auth, Datenbank, LDAP, …) Wurde konfiguriert wie Gruppen bestimmten Benutzern zugeordnet werden (Datenbank, LDAP, …), wird Icinga Web 2 versuchen nach erfolgreicher Anmeldung eines Benutzers seine Gruppen-Zugehörigkeiten zu registrieren. Nun existieren alle notwendigen Informationen, die verfügbaren Rollen einem Benutzer zuzuordnen. Eine Rolle definiert die Berechtigungen und Einschränkungen die für bestimmte Bereiche in Icinga Web 2 anzuwenden sind.
Berechtigungen
Eine Berechtigung definiert thematisch wer was sieht und machen darf, nach dem Motto „alles oder nichts“. In Bezug auf Icinga Web 2 selbst (also die Applikation an sich), trifft das auf die Konfiguration zu. Ob ein Benutzer alles, nur die Rollen oder die Benutzer und auch die Gruppen konfigurieren darf, wird mittels bestimmter Berechtigungen kontrolliert. Auch das Monitoring Modul (das eigentliche Herz, welches mit Icinga kommuniziert) bietet die Möglichkeit Berechtigungen zu definieren. In diesem Fall allerdings trifft dies auf die Kommandos zu, ob ein Benutzer alles, nur Kommentare hinzufügen oder Acknowledgements senden und auch Downtimes definieren darf. (Diese Berechtigungen stehen nicht mit bestimmten Hosts oder Services in Verbindung, sondern gelten für alle gleichermaßen.)
Einschränkungen
Eine Einschränkung wird zusätzlich zu einer möglicherweise notwendigen Berechtigung angewendet und, wie der Name schon sagt, schränkt den eigentlichen Zugriff noch weiter ein.
Dies geschieht aktuell im Monitoring Modul für Hosts und Services und schränkt die Anzeige der eigentlichen Objekte und, mit dem Release Candidate, auch ihrer entsprechend verknüpften Daten (Events, Kommentare, …) ein. (Sobald der Release Candidate verfügbar ist, wird dies auf Host- und Service-Gruppen sowie alle möglichen Aliase und Customvariablen ausgedehnt. Ob auch eine automatische Verknüpfung eines Benutzers mit einem Kontakt erfolgen kann, ist noch nicht endgültig entschieden.)
In Bezug auf Customvariablen gibt es im Monitoring Modul eine Besonderheit: Es ist möglich den Zugriff auf bestimmte Customvariablen vollständig zu sperren, unabhängig einer Rolle. Dies ist meist sinnvoll, wenn dort sensitive Informationen wie Passwörter o.ä. existieren.
Die URL Filter-Syntax
Da die Definition einer Einschränkung für Hosts und Services aktuell mittels eines URL Filters (wie sie überall in Icinga Web 2 verwendet werden) geschieht und es in der entsprechenden Konfigurations-Ansicht keinerlei Hilfestellung hierfür gibt, zeige ich zum Abschluss wie so ein Filter aussehen kann. Findige Nutzer werden evtl. bereits auf die Idee gekommen sein, den Editor in den entsprechenden Listen-Ansichten zu verwenden. Denn dort ist es aktuell möglich, sich die gewünschten Filter einfach „zusammen zu klicken“. Hat man all seine gewünschten Filter angewendet, erscheint deren Repräsentation in der Address-Zeile des Browsers und kann von dort direkt übernommen werden:
/icingaweb2/monitoring/list/hosts?(hostgroup_name=customer1|hostgroup_name=customer2)&host_name=office-*
Hier kann man bereits den grundlegenden Aufbau erkennen. Es sind Verknüpfungen (OR = |, AND = &, NOT = !) und Vergleiche (EQUAL =, NOT EQUAL = !=, GREATER = >, LESS = <, GREATER OR EQUAL = >=, LESS OR EQUAL = <=) möglich. Möchte man mehrere Bedingungen zusammenfassen, setzt man sie in runde Klammern. Sollen nun nur noch Hosts der Hostgruppe "customer2" zutreffen, welche eine bestimmte Customvariable besitzen, (Eine Funktion die aktuell leider nur mit Icinga 1.x funktioniert, mit dem Release Candidate allerdings auch mit Icinga 2.x.) muss der Filter folgendermaßen angepasst werden:
(hostgroup_name=customer1|(hostgroup_name=customer2&_host_support_level>=2))&host_name=office-*
Handelt es sich um einen Service, sieht die Notation für Customvariablen folgendermaßen aus: _service_variable_name
—
In diesem Sinne, wünsche ich euch ein fröhliches berechtigen und einschränken. Bis demnächst, wenn’s mal wieder etwas von Icinga Web 2’s pure awesomeness zu berichten gibt. 😀
