Solr absichern: Tipps und Tricks, die Sie wirklich wissen müssen
Seit der Version 5.2 verfügt Solr standardmäßig über Authentifizierungs- und Autorisierungs-APIs, die es Ihnen ermöglichen, Benutzer, Rollen und Berechtigungen mit…
Seit der Version 5.2 verfügt Solr standardmäßig über Authentifizierungs- und Autorisierungs-APIs, die es Ihnen ermöglichen, Benutzer, Rollen und Berechtigungen mit dem RuleBasedAuthorizationPlugin und dem BasicAuthPlugin zu definieren. Das ist die gute Nachricht. Die weniger gute Nachricht ist, dass diese Plugins zwar leistungsfähig, aber bei der Konfiguration etwas kontra-intuitiv sind. Daher habe ich mir die Mühe gemacht, mich mit der Sicherheitsarchitektur von Solr zu beschäftigen und a) zu verstehen, wie dieses Framework funktioniert, und b) seine verschiedenen Eigenheiten zu erkennen. Zu diesem Zweck habe ich eine praktische Liste von Dingen zusammengestellt, die Sie bei der Einrichtung und/oder Verwaltung Ihrer Solr-Sicherheit beachten sollten.
(Schamlose Werbung): Die Sicherheitsfunktionen von Lucidworks Fusion sind viel einfacher zu verwenden und bieten eine granularere Implementierung und eine verbesserte Zugriffskontrolle. Nach diesen Vorbemerkungen fahren wir mit der Sicherung Ihrer Solr-Instanz fort.
Der erste Schritt zur Nutzung der Solr-Autorisierung/Authentifizierung ist die Aktivierung der Solr-Sicherheit. Sie können zwar die APIs verwenden, um Ihre Sicherheit zu aktualisieren, sobald sie aktiviert ist, aber Sie müssen das ZooKeeper-Skript verwenden, um Ihre security.json-Datei hochzuladen. Öffnen Sie dazu ein Befehlszeilenfenster und wechseln Sie mit ‚cd‘ in Ihr Solr-Installationsverzeichnis.
Dort angekommen, müssen Sie Solr starten:
bin/solr start -cloud
Stellen Sie sicher, dass sich Ihre security.json-Datei im Stammverzeichnis befindet, und führen Sie dann diesen Befehl aus. Dadurch wird Ihre security.json in ZooKeeper und allen Ihren laufenden Knoten installiert. Außerdem wird dadurch das Solr-Sicherheitsframework aktiviert.
server/scripts/cloud-scripts/zkcli.sh-zkhost localhost:9983 -cmd putfile /security.json security.json
Beispiel security.json
{
"authentication":{
"class":"solr.BasicAuthPlugin",
Anatomie einer security.json Datei
Im obigen Beispiel sehen wir zwei Top-Level-Attribut-Deklarationen: ‚Authentifizierung‘ und ‚Autorisierung‘. Diese stehen für die kombinierten Daten, die an beide APIs gesendet werden. Das Attribut ‚class‘ definiert die Handler-Klasse für diese APIs. Das BasicAuthPlugin und das RuleBasedAuthorizationPlugin werden beide mit Solr ausgeliefert. Sie können Ihre eigenen benutzerdefinierten Handler hinzufügen.
Im Falle der Authentifizierung wollen Sie das:
extend AuthenticationPlugin implements ConfigEditorPlugin, SpecProvider
Im Falle einer Autorisierung sollten Sie das tun:
implements AuthorizationPlugin,ConfigEditablePlugin,SpecProvider
Im Authentifizierungsobjekt ist ein Attribut ‚credentials‘ angegeben. Dieses enthält die Liste der autorisierten Benutzer und ihre SHA-256 gehashten Passwörter. Die Benutzerverwaltung wird später in diesem Artikel behandelt.
Im Berechtigungsobjekt sehen Sie ein Objekt ‚Berechtigungen‘ und eine Liste von Benutzerrollen, definiert durch Benutzername:Rolle. Hier verknüpfen (und erstellen) Sie die Rollen, die in Ihrer Umgebung verwendet werden, mit den Benutzern, die Sie unter ‚Authentifizierung‘ angegeben haben. Sie können so viele Benutzer:Rollen-Beziehungen angeben, wie Sie möchten, aber bedenken Sie, dass:
a) Alle Benutzer müssen im System registriert sein.
b) Je mehr Benutzer und Rollen Sie deklarieren, desto komplexer wird Ihre Berechtigungsmatrix.
Das Berechtigungsfeld ist eigentlich der Endpunkt einer Sicherheitsdefinition. Es verwendet die zuvor beschriebenen Definitionen von Benutzern und Rollen, um an eine einzelne Berechtigung zu binden. Dies ist wichtig und der Punkt, an dem die Solr-Sicherheit ein wenig haarig werden kann. Es besteht eine eins-zu-eins (1:1) Beziehung zwischen einer Berechtigung und einer Rolle. Die einzigen Ausnahmen von dieser Regel sind der Platzhalter (*), der in jeder Berechtigungsrollendefinition verwendet werden kann und bedeutet, dass alle authentifizierten Benutzer über diese Berechtigung verfügen, und das Schlüsselwort ‚before‘, das dafür sorgt, dass eine Berechtigung vor einer anderen benannten Berechtigung ausgewertet wird. Andernfalls ist eine Berechtigung auf eine einzige Rolle beschränkt. Das bedeutet letztlich, dass Sie sehr genau überlegen müssen, wie Sie Ihre Berechtigungsmatrix aufbauen. Ein Beispiel: Wenn Sie allen Benutzern in Ihrem System echten Lesezugriff gewähren möchten, müssen Sie mehr als nur {„Name“: „Lesen“, „Rolle“: „*“}. Auf den ersten Blick, oder besser gesagt, intuitiv würden Sie denken, dass dies alle Dinge abdeckt, die gelesen werden müssen. Dies ist jedoch nicht der Fall. Um Leseberechtigungen für alle Benutzer zu vergeben, müssen Sie deklarieren:
{"name":"read","role":"*"},{"name":"schema-read","role":"*"},{"name":"config-read","role":"*"},{"name":"collection-admin-read","role":"*"},{"name":"metrics-read","role":"*"},{"name":"core-admin-read","role":"*"}
Dadurch erhalten alle Ihre Benutzer uneingeschränkten Lesezugriff auf alle Aspekte Ihrer Solr-Verwaltungskonsole.
Ein praktisches Beispiel aus der Praxis
Kürzlich fragte uns ein Kunde nach der Implementierung von Sicherheit auf Dokumentenebene in Solr. Das Berechtigungsframework von Solr ermöglicht es Ihnen, granulare Sicherheit von der Konsole bis zur Sammlungsebene zu implementieren. Für die Sicherheit auf Dokumentebene müssen Sie jedoch einen eigenen Dienst schreiben, um eine ACP (Access Control Policy) auf jedes Dokument anzuwenden. Abgesehen davon ist Solr, wie bereits erwähnt, in der Lage, Sicherheit von der Konsole bis zur Sammlungsebene zu gewährleisten. Was wäre also, wenn wir eine solche Berechtigungsmatrix erstellen wollten?
{"authentication":{
"class":"solr.BasicAuthPlugin",
"credentials":{"solr":"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0= Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c=","devuser":"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0= Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="}
},
"authorization":{
"class":"solr.RuleBasedAuthorizationPlugin",
"user-role":{"solr":"admin","devuser":"dev"},
"permissions":[{"name":"read","role":"*"},{"name":"schema-read","role":"*"},{"name":"config-read","role":"*"},{"name":"collection-admin-read","role":"*"},{"name":"metrics-read","role":"*"},{"name":"core-admin-read","role":"*"},{ "name":"secure-collection1-permission",
"collection":"securecollection",
"path":"/select",
"before": "collection-admin-read",
"role": "admin"
}]
}}
Wie Sie im obigen Beispiel sehen können, habe ich zwei Benutzer (solr/devuser) und zwei Rollen (admin/dev) definiert. Dann habe ich allen Benutzern vollen ‚Lese‘-Zugriff zugewiesen, mit Ausnahme einer Sammlung, auf die nur ein Benutzer mit der Rolle ‚admin‘ zugreifen darf. Gemäß dieser Definition wird diese Berechtigung angewendet vor vor der Rolle collection-admin-read. Das bedeutet, dass nur ein Administrator die Sammlung mit dem Namen ’securecollection‘ sehen kann. Ich habe den autorisierten Pfad als ‚/select‘ definiert, was bedeutet, dass der Benutzer in der Lage ist, die Sammlung abzufragen. Der Name dieser Berechtigung ist völlig frei wählbar. Die einzige Einschränkung ist, dass sie nicht den Namen einer eingebauten Berechtigung tragen darf (z.B. ‚Lesen‘, ‚Aktualisieren‘ usw.). In diesem Fall habe ich sie ’secure-collection1-permission‘ genannt.
Die vordefinierten ‚bekannten‘ Berechtigungsnamen, aus der Klasse PermissionNameProvider:
COLL_EDIT_PERM("collection-admin-edit", null),
COLL_READ_PERM("collection-admin-read", null),
CORE_READ_PERM("core-admin-read", null),
CORE_EDIT_PERM("core-admin-edit", null),
READ_PERM("read", "*"), UPDATE_PERM("update", "*"),
CONFIG_EDIT_PERM("config-edit", "*"),
CONFIG_READ_PERM("config-read", "*"),
SCHEMA_READ_PERM("schema-read", "*"),
SCHEMA_EDIT_PERM("schema-edit", "*"),
SECURITY_EDIT_PERM("security-edit", null),
SECURITY_READ_PERM("security-read", null),
METRICS_READ_PERM("metrics-read", null),
ALL("all", unmodifiableSet(new HashSet<>(asList("*", null))))
- collection-admin-edit: Erlaubt Benutzern mit dieser Rolle, Sammlungen zu aktualisieren.
- collection-admin-read: Erlaubt Benutzern mit dieser Rolle Lesezugriff auf Sammlungen.
- core-admin-read: Erlaubt Benutzern mit dieser Rolle, bestimmte Elemente in der Verwaltungskonsole zu lesen.
- core-admin-edit: Erlaubt Benutzern mit dieser Rolle die Bearbeitung bestimmter Aspekte der Administrationsoberfläche (NICHT der Sicherheit).
- core-admin-read: Erlaubt Benutzern mit dieser Rolle, bestimmte Aspekte der Verwaltungskonsole zu lesen.
- lesen: Ermöglicht Benutzern mit dieser Rolle einen rudimentären ‚Lese‘-Zugriff. HINWEIS: Durch die Zuweisung der Berechtigung ‚Lesen‘ erhält die Rolle nicht wirklich vollen Lesezugriff.
- config-read: Ermöglicht authentifizierten Benutzern einen ‚Lese‘-Zugriff auf Konfigurationsinformationen.
- config-edit: Ermöglicht Benutzern mit dieser Rolle den Zugriff auf die Bearbeitung der Solr-Konfiguration.
- config-read: Gibt Benutzern mit dieser Rolle die Berechtigung, Konfigurationseinstellungen zu lesen.
- schema-read: Erlaubt Benutzern mit dieser Rolle das Lesen von Sammlungsschema-Informationen.
- schema-edit: Ermöglicht Benutzern mit dieser Rolle die Bearbeitung von Sammlungsschemainformationen.
- metics-read: Erlaubt Benutzern mit dieser Berechtigung das Lesen von Solr-Metrikdaten.
- alle: Versieht die zugehörige Rolle mit ‚allen‘ Berechtigungen.
… und die zulässigen Attributwerte für eine Berechtigung:
"collection", "role", "params", "path", "method", "name","index","before"
- ‚collection‚ ist der angegebene Name einer Sammlung in Ihrer Umgebung.
- ‚role‚ ist der Name einer vordefinierten Rolle (definiert in ‚user-roles‘).
- params‚ gibt die Abfrageparameter an (z.B. &wt=json), die gefiltert werden sollen.
- Pfad‚ gibt einen Url-Pfad zum Filtern an (z.B. ‚/select). Die verfügbaren Pfade in Solr sind:Registrierte Pfade:
/admin/mbeans,/browse, /update/json/docs, /admin/luke, /export,/get, /admin/properties, /elevate,/update/json, /admin/threads, /query, /analysis/field, /analysis/document, /spell,/update/csv, /sql, /graph,/tvrh,/select, /admin/segments, /admin/system, /replication,/config, /stream,/schema, /admin/plugins, /admin/logging, /admin/ping, /update,/admin/file, /terms,/debug/dump, /update/extract - Methode‚ bezieht sich auf das verwendete HTTP-Protokoll, eines der unterstützten Protokolle: GET,
PUT, POST, DELETE,HEAD. Beachten Sie, dass ‚OPTIONS‘ kein unterstütztes Protokoll ist, ebenso wenig wie ‚TRACE‘, ‚CONNECT‘ oder ‚PATCH‘. - Name‚ ist der Vorname der Berechtigung, entweder ein bekannter Name oder ein benutzerdefinierter Name.
- index‚ ist der Index der Berechtigung, nachdem sie im System registriert wurde. HINWEIS: In einigen älteren Dokumentationen wird die Verwendung des Berechtigungsnamens für die Aktion ‚delete-permission‘ angegeben. Sie müssen jedoch den Berechtigungsindex (eine ganze Zahl) und nicht den Namen (eine Zeichenkette) verwenden. Sie können den Index einer gespeicherten Berechtigung ermitteln, indem Sie die Berechtigungs-API aufrufen
- ‚before‘ gibt an, dass diese Berechtigung vor der genannten Berechtigung angewendet wird.
Sie können die vollständige Spezifikation der Regel-Api hier herunterladen.
Benutzer verwalten
Die Benutzerverwaltungs-API von Solr ist spartanisch und lässt wohl einige notwendige Aktionen vermissen. Sie können zwar Benutzer und Kennwörter hinzufügen, bearbeiten und löschen, aber sobald Sie Ihre security.json-Datei hochgeladen haben und die API verwenden, ist Ihre ursprüngliche security.json-Datei veraltet, und wenn Sie sie erneut hochladen würden, würde sie alle zuvor vorgenommenen Änderungen an der Benutzerverwaltung überschreiben. Aus diesem Grund ist es eine gute Idee, eine aktuelle security.json-Datei zu führen. Wenn Sie Ihre Node-Cluster migrieren müssen, brauchen Sie sich nicht darum zu kümmern, die Benutzerbasis von Grund auf neu einzurichten. Sie laden einfach Ihre security.json Datei hoch und los geht’s!
Lassen Sie uns zu diesem Zweck einen Best-Practice-Workflow für die Benutzerverwaltung durchgehen.
- Laden Sie Ihre security.json hoch
- Fügen Sie einen Benutzer hinzu:
curl --user solr:SolrRocks http://localhost:8983/solr/admin/authentication -H 'Content-type:application/json' -d '{ "set-user": {"tom" : "TomIsCool"}}' - Lassen Sie uns nun Toms SHA-256-Passwort-Hash abrufen:
curl --user solr:SolrRocks http://localhost:8983/solr/admin/authentication
und die Antwort wird ungefähr so aussehen:
{ "responseHeader":{ "status":0, "QTime":3}, "authentication.enabled":true, "authentication":{ "class":"solr.BasicAuthPlugin", "credentials":{ "solr":"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0= Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c=", "tom":"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0= Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="}}} - Kopieren Sie nun den Eintrag ‚tom‘ und fügen Sie ihn zu Ihrer security.json Datei hinzu. Auf diese Weise erhalten Sie eine aktuelle Liste der autorisierten Benutzer und müssen diese nicht neu erstellen, wenn Sie eine Berechtigung ändern, Ihre security.json-Datei ändern oder Ihre Umgebung migrieren müssen. Zugegeben, diese Methode ist etwas umständlich, aber sie spart Ihnen Zeit und in vielen Fällen auch Mühe.
Fehlerbehebung bei der Implementierung Ihrer Berechtigungen
Sicherheitsimplementierungen sind in den meisten Fällen sehr schwer zu beheben. Oft liefern diese Implementierungen keine aussagekräftigen Fehlermeldungen oder, noch schlimmer, überhaupt keine Meldung. Das ist bei Solr nicht der Fall. Solr gibt in der Regel einen 403 ‚Unauthorized‘ Fehler zurück. Wenn Sie jedoch eine security.json hochladen, die sich nicht so verhält, wie Sie es erwarten würden, sollten Sie in Ihrer solr.log-Datei nach Fehlermeldungen suchen. Sie werden Ihre besten Freunde bei der Fehlersuche in einer Solr-Berechtigungsmatrix sein. Hier sind einige häufige Fehler:
- No Authorized User:
2017-03-08 15:47:55.876 INFO (qtp1348949648-16) [ ] o.a.s.s.HttpSolrCall USER_REQUIRED auth header null context : [FAILED toString()] - Invalid Role:
„role“: „admin“}, The principal [principal: devuser] does not have the right role
Dies wird die häufigste Ausnahme sein, wenn es um Benutzerrechte geht!
Kurz und bündig: Wichtige Tipps und Tricks bei der Verwendung von Solr Security
- Ihre Solr-Installation sollte hinter einer Firewall gesichert sein.
- Der Benutzer, unter dem Solr gestartet wird, sollte nur Schreibzugriff auf das Solr-Homeverzeichnis haben ( standardmäßig $SOLR_INSTALL/server/solr )
- Berechtigungen sind FIFO (First In, First Out). Das heißt, sie werden in der Reihenfolge ausgewertet, in der sie deklariert werden.
- Es besteht eine 1:1-Beziehung zwischen Rollen und Berechtigungen. Jede gegebene Berechtigung (z.B. ‚Lesen‘) wird nur einmal ausgewertet, nämlich beim ersten Auftreten in der Liste. Wenn Sie in der Folge eine zweite Leseberechtigung definieren, wird diese nicht berücksichtigt.
- Sie können ein Sternchen (*) verwenden, um allen Benutzern alle Berechtigungen zuzuweisen. { „name“: „lesen“, „Rolle“: „*“}
- Das Attribut ‚role‘ akzeptiert entweder einen Platzhalter ‚*‘ oder eine einzelne Zeichenkette mit einem Rollennamen als Argument. Sie können keine Arrays oder durch Kommata getrennte Zeichenketten übergeben.
- Sie können die Berechtigung ‚all‘ verwenden, um einer bestimmten Rolle alle Berechtigungen zuzuweisen. { „name“: „alle“, „Rolle“: „admin“}
- Sie sollten sich für weniger Berechtigungen entscheiden. Verwenden Sie nur das, was Sie brauchen. „Weniger ist mehr.“ Das heißt, es gibt ein feines Gleichgewicht zwischen dem, was erforderlich ist, und dem, was überflüssig ist.
- Beim Löschen von Berechtigungen MÜSSEN Sie die Ganzzahl ‚index‘ und nicht den Namen der Berechtigung verwenden.
- Die Wildcard-Erlaubnis ist Ihr Freund.
- Wenn Sie der Konsole die allgemeine Rolle ‚read‘ zuweisen, müssen Sie auch collection-admin-read und core-admin-read der gleichen Rolle zuweisen. Ebenso müssen Sie für ‚update‘ die Rollen core-admin-edit und collection-admin-edit der gleichen Rolle zuweisen.
- Wenn Sie eine Berechtigung definieren, ist nur der Parameter ‚Rolle‘ erforderlich.
- Verwenden Sie eine Bibliothek wie SolrJ, um mit ZooKeeper zu kommunizieren.
- Wenn Sie eine vordefinierte (oder ‚benannte‘) Berechtigung verwenden, sind die einzigen erlaubten Attribute: Name, Rolle, Sammlung, Index.
Viel Spaß beim (sicheren) Suchen!