Rollenkonzept im Elastic Stack
Was ist ein Rollenkonzept?
Ein Rollenkonzept kann verschiedene Formen und Tiefen annehmen – je nach Anwendungsfall. Grob abstrahiert ist das Rollenkonzept eine Sammlung theoretischer Rollen, die beispielsweise für eine Datenbankanwendung umgesetzt werden sollen. Diese Rollen weisen Aufgaben, Berechtigungen und Komponenten zu, je nach dem, was der Nutzer in der Anwendung sehen oder verändern darf. Nutzer sollen dabei nur so viele Berechtigungen erhalten, dass sie ihre Arbeit erledigen können, ohne dabei die Arbeit anderer Bereiche zu beeinflussen (z.B. kundenspezifische Trennung).
Was sind Rollen im Elastic Stack und arbeiten diese zusammen?
Rollen im Elastic Stack wirken sich, wie auch in anderen Produkten, auf die Sichtbarkeit von Daten und User Interface Komponenten für User aus. Sie können verwendet werden, um Mandantenfähigkeit und Separierung der Daten zu gewährleisten bzw. Zugriffe zu beschränken.
Dabei arbeiten Rollen mit Privilegien, die Indizes, UI-Komponenten und Einzeldaten beschränken sowie Anfragen gegen das Cluster erlauben.
Wenn nun ein Rollenkonzept erstellt werden soll, so muss geachtet werden auf:
- „Wer“ soll die Daten sehen?
- „Welche“ Daten darf der Nutzer sehen?
- Welche „Aktionen“ darf der Nutzer ausführen?
- Welche „Oberflächenkomponenten" darf er sehen?
Daraus sind zum Beispiel theoretische Rollen abzuleiten:
- ein „Admin“, der im Cluster alle Berechtigungen auf Alles hat
- ein „Viewer“, welcher die Möglichkeit hat, Daten einzusehen und sich Dashboards anzeigen lassen kann
- ein „Editor“, der Änderungen an Dashboards und ggf. Daten vornehmen kann
Sind diese theoretischen Rollen konzipiert, so können die Bestandteile dieser Rollen abstrahiert werden. Man kann dabei durchaus einem User mehrere Rollen zuweisen, die sich addierend aufeinander auswirken. Einzelne Abschnitte/Indizes/Objekte in unterschiedliche Rollen zu kapseln ist in dem Zuge möglich und auch empfohlen. Wichtig zu beachten ist dabei, dass einmal durch eine Rolle zugewiesene Rechte, nicht durch eine zweite überschrieben werden können. Gibt dementsprechend eine Rolle alle Zugriffsrechte auf einen Index, können diese nicht durch eine zweite, welche den Zugriff einschränken soll, wieder entfernt werden. So ist es sinnvoll Basisrollen, welche wenig Zugriff auf Indizes haben, als default zu vergeben und dann zu erweitern:
So bedeutet diese Default Einstellung, dass der Benutzer nur interne Daten aus dem Logs Index lesen darf. Dabei kann er nur die Felder „@timestamp“, „message“ und „host.name“ einsehen. Diese Rolle kann nun ergänzt werden:
Wird dem Benutzer nun diese zweite dargestellte Rolle mit den Index Privilegien hinzugefügt, sieht er zusätzlich zu den internen Logdaten noch Metrikdaten von Kunden. So können Berechtigungen für den Benutzer graduell erweitert werden und bleiben modular.
Folgende Rolle kommt hinzu (siehe Screenshot)
...ändert aber an den Berechtigungen für den Nutzer nichts, da die "bestehenden" Privilegien entfernt werden. Eine andere Rolle fügte diese jedoch hinzu und somit sind die Privilegien vom Entfernen/Überschreiben durch weitere Rollen gesperrt.
Über die „Mustache“ Schreibweise kann man bei der Erstellung von Rollen auf Metadaten des Users zugreifen. Diese Metadaten sind zwingend bei der Erstellung des Nutzers zu vergeben, da man sie nicht durch die UI anlegen kann. Es gibt die Möglichkeit, Zugriffsbeschränkungen durch die Referenzierung von Metadaten in Rollen dynamisch in den „Granted Docuement Query“ einzubauen. So können beispielsweise Differenzierungen zwischen Mandanten vorgenommen werden:
Hier wird ein Filter über das „mandant“ Feld gelegt. Der Nutzer darf nun nur Daten mit entsprechend hinterlegtem Mandanten sehen.
Diese Metadaten werden bei eigens angelegten Nutzern über die Dev Tools gesetzt. Die Erstellung eines Nutzers über das User Interface bietet im Moment noch nicht die Möglichkeit, Metadaten hinzuzufügen:
Über den PUT oder POST Befehl können Nutzer angelegt und mit Metadaten versehen werden. Der User wird über den gleichen Befehl geupdated, allerdings ohne Änderungen hinzuzufügen, da ein Überschreiben des Users stattfindet. Bei einem Update wird in der Response bei Created „false“ angezeigt, da der User schon existierte.
Zusammenfassung
In diesem Artikel wurde die Erstellung eines Rollenkonzepts mit Schwerpunkt auf die Restriktion von Daten und Zugriffen betrachtet. Neben der Erklärung, wie man Rollen konzipiert, stand das Einbinden verschiedener Zugriffsrechte im Mittelpunkt. Im nächsten Artikel betrachten wir Cluster Privilegien. Dabei beleuchten unsere Autoren ihre Verwendung, um Zugriffe auf Funktionalitäten im Cluster zu steuern sowie die Fähigkeit, diese zu managen und zu verändern.
Kommentare
Keine Kommentare