Elasticsearch

Das Elasticsearch-Plug-in schlägt Indizes, Data Streams, Felder und den Cluster nach und verwaltet Zugriffsrichtlinien in den eigenen Begriffen von Elasticsearch: Felder lesen, Dokumente indizieren und löschen, Indizes anlegen, löschen und verwalten sowie die eigenen Operationen des Clusters, mit Zeilenfiltern von Indizes. Plug-in-ID und Diensttyp sind beide elasticsearch. Das Service-Plug-in läuft im GrantForge-Server; der Elasticsearch-Agent, ein Dienst neben dem Cluster, setzt die Richtlinien mit den eigenen Rollen, der Field Level Security und der Document Level Security von Elasticsearch durch.

Die Testcontainers-Integrationstests des Repositorys decken Elasticsearch 8.19, 9.3, 9.4 und 9.5 mit aktivierter Sicherheit ab; das zertifiziert nicht jede andere Version.

Installation

Das Distributionspaket enthält das Plug-in in plugins/elasticsearch. Prüfen Sie unter Plattformverwaltung → Plug-ins, dass elasticsearch aktiviert ist; scannen Sie das Plug-in-Verzeichnis nach einer Aktualisierung erneut. Das Plug-in spricht über den Low-Level-REST-Client von Elasticsearch mit den Knoten, in einem eigenen Classloader.

Datendienst hinzufügen

1. Öffnen Sie Datenberechtigungen → Datendienste, fügen Sie einen Dienst hinzu und wählen Sie Elasticsearch (elasticsearch).
2. Geben Sie einen Knoten als URL ein, oder mehrere Knoten.
3. Wählen Sie, wie sich der Lookup-Benutzer anmeldet, geben Sie seine Zugangsdaten ein, testen Sie die Verbindung und speichern Sie den Dienst. Der Test meldet sich an und beschreibt den Cluster: Elasticsearch-Version und Name, die Lizenz und ob sie Document und Field Level Security hat, den angemeldeten Benutzer und wie viele Indizes und Data Streams er hat. Ein Cluster ohne Sicherheit besteht den Test nicht, da der Agent Richtlinien mit den Rollen von Elasticsearch durchsetzt.

Der Lookup-Benutzer lässt GrantForge Ressourcen finden; er ist von den Benutzern getrennt, die lesen und schreiben. Ein erfolgreicher Verbindungstest bedeutet nicht, dass der Zugriff bereits Richtlinien unterliegt.

Einstellungen einer Anmeldeart werden für die anderen abgelehnt, sodass der Dienst genau sagt, wie er sich anmeldet. Abgelehnte Anmeldungen, widerrufene API-Schlüssel, fehlende Berechtigungen, nicht erreichbare Knoten und nicht prüfbare Zertifikate werden als solche gemeldet.

Was der Lookup-Benutzer sieht

Der Lookup-Benutzer muss lesen können, was er auflistet: die Resolve-API von Elasticsearch für Indizes und Data Streams, Field Capabilities für Felder und die Beschreibung des Clusters für seinen Namen. Eine Rolle mit read und view_index_metadata auf den Indizes gibt die ersten beiden; ein Benutzer ohne die Cluster-Berechtigung monitor besteht den Verbindungstest trotzdem, der dann weder Version noch Lizenz nennt. Indizes und Data Streams, deren Namen mit einem Punkt beginnen, also versteckte und Systemindizes, werden nur aufgelistet, wenn die Eingabe mit einem Punkt beginnt; die Backing-Indizes von Data Streams erscheinen als ihr Data Stream. Felder sind die Felder der Dokumente: die eigenen Metadatenfelder von Elasticsearch, Objekte und Multi-Felder, die ein Feld erneut indizieren, wie name.keyword, werden ausgelassen, da der Agent sie mit ihrem Feld gewährt.

Ressourcen und Zugriffsarten

Jede Zugriffsart ist die gleichnamige Berechtigung von Elasticsearch, außer cluster_monitor, das die Cluster-Berechtigung monitor ist:

Lesen wird pro Feld entschieden, so wie Field Level Security die Felder der Dokumente zeigt: Eine read-Richtlinie nennt Felder, und * sind alle Felder. Eine Richtlinie kann so einen Index erlauben und ein Feld darin verweigern, und der Benutzer liest alle übrigen Felder. In Richtlinienwerten passt * auf beliebig viele Zeichen und ? auf ein Zeichen. Der Richtlinieneditor schlägt Indizes und Data Streams, die Felder der von der Richtlinie genannten Indizes und den Cluster vor.

Zeilenfilter

Eine Zeilenfilter-Richtlinie eines Index zeigt dem Benutzer nur die Dokumente, die eine Abfrage trifft. Die Abfrage ist die Query DSL von Elasticsearch, wie Document Level Security sie nimmt, etwa {"term": {"region": "EU"}}, und darf ein Template sein, etwa mit {{_user.username}}. Wie bei anderen Diensten erhält ein Benutzer den Filter der ersten Richtlinie, die auf ihn zutrifft. Ein Zeilenfilter kann nur Felder prüfen, die der Benutzer lesen darf: Field Level Security verbirgt die übrigen auch vor der Abfrage.

Elasticsearch maskiert keine Werte, daher bietet der Diensttyp keine Maskierung.

Die Lizenz

Elasticsearch hat Document und Field Level Security ab einer Platinum-Lizenz. Darunter lässt sich eine Richtlinie, die einen Benutzer nur einige Felder oder einige Dokumente eines Index lesen lässt, nicht durchsetzen; der Agent gewährt diesem Benutzer daher kein Lesen des Index, statt mehr als die Richtlinien erlauben, und sagt es. Richtlinien, die ganze Indizes, Schreiben und Verwalten erlauben, funktionieren mit jeder Lizenz.

Richtlinienbeispiel

Angenommen, der Cluster hat eine Platinum-Lizenz und die Indizes logs-2026.10.26 und hr. Legen Sie im selben Datendienst diese aktivierten Richtlinien an:

Sobald der Agent den neuen Snapshot anwendet, lesen Mitglieder von analysts jedes Log-Feld außer der Adresse des Clients; logstash schreibt das morgige logs-2026.10.27 sofort und legt es mit dem ersten Dokument an; Mitglieder von hr lesen die Mitarbeitenden; emea-hr sieht nur die Mitarbeitenden der Region; und Mitglieder von ops lesen Zustand und Statistiken des Clusters.

Richtlinien durchsetzen

Das Service-Plug-in verwaltet Richtlinien und schlägt Ressourcen nach; sie durchzusetzen braucht einen Elasticsearch-Agenten pro Cluster. Bereitstellung und Prüfungen stehen in Elasticsearch-Agent.

Weitere Anleitungen

• Datendienste, Richtlinien und Agenten
• Elasticsearch-Agent
• Plug-ins und Diensttypen