OpenSearch

OpenSearch ist eine der zentralen Systemkomponenten des BPC.

Die Dokumentation des Herstellers finden Sie unter https://opensearch.org/docs/latest/

Konfiguration

Arbeitsspeicher (RAM)

Die Höhe des zugewiesenen Arbeitsspeichers wird über die Umgebungsvariable OPENSEARCH_JAVA_OPTS gesetzt. Diese Umgebungsvariable wird auch bei Verwendung der zentralen Konfiguration über bpc.env.sh genutzt. Alternativ können auch die opensearch/config/jvm.options innerhalb der Installation verändert werden. Siehe auch https://opensearch.org/docs/latest/install-and-configure/install-opensearch/index/

Bitte auch die Arbeitsspeicher-Beispiele für die zur Verfügung stehende Hardware unter Systemanforderungen beachten.

Ressourcen Limits

Auf UNIX basierten Betriebssystemen gibt es diverse Ressourcen Limits für Prozesse. Damit OpenSearch richtig arbeiten kann, müssen diese in der Regel erweitert werden.

Dazu ist die Datei /etc/security/limits.conf zu bearbeiten und um folgende Zeile zu ergänzen. Dabei ist BPCUSER auf den Usernamen zu ändern, der den OpenSearch-Prozess startet.

BPCUSER  -  nofile  65535

Siehe auch https://opensearch.org/docs/latest/install-and-configure/install-opensearch/index/#important-settings

Swapping

Swapping sollte auf dem System möglichst vermieden werden, da dies die Leistung stark einschränkt.

Die Einstellung für das Swapping hängt von Ihrem Betriebssystem ab.

Siehe auch https://opensearch.org/docs/latest/install-and-configure/install-opensearch/index/#important-settings

Shards und Replicas von Indices

Dies sind die beiden Einstellungen eines Index, welche immer wieder für Probleme und Verwirrung sorgen. Dies ist ein komplexes Thema und es gibt keine 100 % Lösung wie die Einstellungen number_of_shards und number_of_replicas je Index eingestellt werden sollten.

Zur Auffrischung was Replica und Shard sind:

Replica

Sind die "Sicherheitskopien" von Shards, wenn ein Node im Cluster ausfallen sollte.
Die Anzahl der Replicas kann auf 0 gesetzt werden. Dies macht aber nur bei einem Single Node bzw. Entwicklungssystem Sinn.
In einem OpenSearch Cluster mit >= 2 Nodes sollte dieser Wert auf mind. 1 gesetzt werden. So dass auf einem weiteren Node im Cluster eine Sicherheitskopie vorliegt.

Shard

Ein Shard enthält die Dokumente eines Index.
Ein Index kann aus 1 oder mehreren Shards bestehen.
Ein Shard kann ca. 50GB an Daten und ca. 200 Millionen Dokumente aufnehmen.
Größere Shards können bei Suchanfragen langsamer sein und im Fehlerfall länger zur Wiederherstellung brauchen.
Jeder Shard benötigt Heap Speicher.
Jeder Shard verwendet einen Thread.

Oversharding

Da jeder Shard Heap Speicher benötigt, ist der maximale Speicher der OpenSearch zur Verfügung gestellt wurde ein wichtiger Punkt, so dass es nicht zu Performanceproblemen kommt. Das wird dann Oversharding genannt. Es gibt eine Faustformel (Quelle) zur Errechnung der Anzahl Shards, bis zu der die Performance noch gut ist: Summe(Max Heap der Nodes in GB) * 20

Maximal Anzahl Shards

Das Maximum an Shards die im Cluster erzeugt werden können, ist in der Voreinstellung auf 1000 festgelegt. Wird dieser Wert durch Anlegen weiterer Indices überschritten, dann kommt zu einem Fehler wie this action would add [5] total shards, but this cluster currently has [998]/[1000] maximum shards open;.

Lösungsmöglichkeiten:

Wenn auf den Nodes im Cluster genügend Heap Speicher zur Verfügung steht), dann kann das Limit wie folgt erhöht werden. Faustformel Beispiel: 3 Nodes je 32 GB Heap Speicher * 20 = 1920 Shards
```
curl -X PUT -H "Content-Type: application/json" 'http://localhost:9200/_cluster/settings' -d '
{
  "persistent": {
    "cluster.max_shards_per_node": 1920
  }
}'
```
Kann zwar auch bei weniger Speicher erhöht werden, dann aber zulasten der Performance und sollte nur temporär erhöht werden.
Leere, nicht benutzte und geschlossene Indices löschen
Die Shards der vorhandenen Indices überprüfen und ggfs. durch einen Reindex reduzieren

Authentifizierung und Autorisierung

Das BPC kommt im Auslieferungszustand bereits mit aktivierten Security Feature für OpenSearch und eingerichteter Authentifizierung und Autorisierung über mTLS (siehe auch Sichere Verbindung (TLS/HTTPS)). Dies bietet bereits einen umfangreichen Zugriffsschutz.

Weitere Informationen dazu finden Sie auch in der offiziellen Dokumentation.

Direkter OpenSearch Zugriff

Durch die Zugriffsbeschränkungen (siehe Authentifizierung und Autorisierung) muss für einen direkten Zugriff auf OpenSearch, zum Beispiel via curl, einiges beachtet werden.

Es gibt im Wesentlichen drei Möglichkeiten auf OpenSearch zuzugreifen. Empfohlen wird der Zugriff mittels Zertifikat, da in diesem Fall keine weiteren Konfigurationsänderungen vorgenommen werden müssen.

Alle folgenden Beispiele gehen davon aus, das TLS (siehe Sichere Verbindung (TLS/HTTPS)) aktiviert ist. Wenn dies nicht der Fal ist, müssen Sie https:// durch http:// ersetzen.

Beachten Sie, dass OpenSearch im Auslieferungszustand nur über das lokale Netzwerkinterface erreichbar ist. Wollen Sie OpenSearch von außen erreichen, müssen Sie die entsprechende Konfiguration anpassen.

Zugriff mit Client-Zertifikat (mTLS)

Dies ist die Standard-Authentifizierung gegenüber OpenSearch. Wie Sie diese konfigurieren ist unter Sichere Verbindung (TLS/HTTPS) beschrieben.

Für die Authentifizierung benötigen Sie das korrekte Client-Zertifikat. Dieses ist im BPC in einem Java Keystore (JKS) hinterlegt. Je nach Zugriffsart benötigen Sie das Client-Zertifikat in einem anderen Format.

Client-Zertifikat aus dem Java Keystore extrahieren

Für die Verwendung mit Tools wie CURL können Sie dieses extrahieren und z.B. im PEM Format speichern.

In den folgenden Beispielen wird davon ausgegangen, dass Sie den virtimo_keystore.jks verwenden. Falls Sie einen anderen Keystore, abweichende Passwörter oder Aliase verwenden, müssen Sie die Beispiele entsprechend anpassen. Die Beispiele beziehen sich auf den im Sichere Verbindung (TLS/HTTPS) beschriebenen Auslieferungszustand.

Extraktion des Client-Zertifikats mit der Shell

Im folgenden Beispiel wird mit den Programmen keytool (Bestandteil von Java) und OpenSSL das Zertifikat zuerst im Format PKCS12 extrahiert und anschließend in das PEM Format überführt.

Extraktion des Client-Zertifikats und Speicherung als opensearch_bpc.pem

keytool -importkeystore \
  -srckeystore virtimo_keystore.jks \
  -srcstoretype JKS \
  -srcalias opensearch_bpc \
  -destkeystore opensearch_bpc.p12 \
  -deststoretype PKCS12 \
  -srcstorepass virtimo \
  -deststorepass virtimo

openssl pkcs12 \
  -in opensearch_bpc.p12 \
  -nocerts \
  -nodes \
  -out opensearch_bpc-key.pem \
  -password pass:virtimo

openssl pkcs12 \
  -in opensearch_bpc.p12 \
  -nokeys \
  -out opensearch_bpc-cert.pem \
  -password pass:virtimo

cat opensearch_bpc-key.pem opensearch_bpc-cert.pem > opensearch_bpc.pem

rm opensearch_bpc.p12
rm opensearch_bpc-key.pem
rm opensearch_bpc-cert.pem

Extraktion des Client-Zertifikats mit dem KeyStore Explorer

Mit dem KeyStore Explorer ist es einfach möglich Zertifikate aus Java Keystores zu extrahieren.

Den Keystore virtimo_keystore.jks öffnen
Kontextmenü auf dem Eintrag 'opensearch_bpc'
Exportieren → Schlüsselpaar exportieren
Im Export Dialog: Format = PEM, Passwort = KEINES → Export

CURL Beispiel mit Zertifikat im PEM Format

Das folgende Beispiel erwartet das Client-Zertifikat in der Datei opensearch_bpc.pem.

Exemplarischer Aufruf per CURL

curl --insecure --cert opensearch_bpc.pem 'https://localhost:9200'

Zugriff mit Basic Auth und internen Benutzer

Es wird empfohlen diese Zugriffsmethode nicht zu nutzen. Damit wird das Sicherheitsniveau signifikant gesenkt. Sollten Sie dies dennoch nutzen wollen, wird empfohlen die Passwörter der internen Benutzer zu ändern (siehe Passwort der internen OpenSearch Benutzer ändern) oder die Benutzer zu ersetzen.

Für diesen Zugriff müssen Sie sicherstellen, dass die Authentifizierung per Zertifikat nur optional ist. Dafür muss in OpenSearch (opensearch.yml) der Parameter plugins.security.ssl.http.clientauth_mode auf OPTIONAL stehen (siehe auch OpenSearch Dokumentation TLS Client authentication).

Sie sollten plugins.security.ssl.http.clientauth_mode nicht auf NONE stellen. Dadurch kann Karaf keine Verbindung mehr zu OpenSearch herstellen.

OpenSearch ist initial bereits mit mehreren Demo-Benutzern konfiguriert (siehe auch OpenSearch Dokumentation), wie z.B. admin mit dem Passwort admin. Solange plugins.security.ssl.http.clientauth_mode auf REQUIRED gesetzt ist, können diese nicht verwendet werden.

Es ist auch möglich den Karaf Zugriff auf diese Authentifizierungsmethode umzustellen. Davon wird jedoch abgeraten.

Siehe auch BPC Konfigurationsdatei.

Beispielkonfiguration karaf/etc/de.virtimo.bpc.core.cfg

de.virtimo.bpc.core.opensearch.username = admin
de.virtimo.bpc.core.opensearch.password = admin

Wurden die Einstellungen angepasst und OpenSearch neu gestartet, so kann der Zugriff mittels basic auth und einem internen Benutzer ausgeführt werden.

Exemplarischer Aufruf per CURL mit Demo User admin

curl --insecure -u admin:admin 'https://localhost:9200'

Passwort der internen OpenSearch Benutzer ändern

Es wird dringend empfohlen die Passwörter der internen Benutzer zu ändern und nicht benutzte Benutzer zu entfernen.

Hier ein Beispiel, wie Sie das Password vom Benutzer admin ändern.

Wir befinden uns im OpenSearch Verzeichnis
```
cd opensearch
```

Benötigte OpenSearch Security Plugin Tools ausführbar machen

chmod +x ./plugins/opensearch-security/tools/hash.sh
chmod +x ./plugins/opensearch-security/tools/securityadmin.sh

Hash des neuen Passwortes generieren

./plugins/opensearch-security/tools/hash.sh -p sehr_starkes_admin_pw

**************************************************************************
** This tool will be deprecated in the next major release of OpenSearch **
** https://github.com/opensearch-project/security/issues/1755           **
**************************************************************************
$2y$12$5VMnjOnHEoZucsTzxFmdZu3qbddy0tJIGmHPcPep8phE965Dq1ZBK

Den Hash des admin Benutzers in der config/opensearch-security/internal_users.yml ersetzen

admin:
  hash: "$2y$12$5VMnjOnHEoZucsTzxFmdZu3qbddy0tJIGmHPcPep8phE965Dq1ZBK"
  reserved: true
  backend_roles:
    - "admin"
  description: "Demo admin user"

In der config/opensearch.yml den bpc Benutzer temporär als admin-Benutzer hinzufügen (letzte Zeile mit CN=bpc, …).

plugins.security.authcz.admin_dn:
  - "CN=opensearch_admin,OU=Dev,O=Virtimo AG,L=Berlin,C=DE"
  - "CN=bpc,OU=client,O=Virtimo AG,L=Berlin,C=DE" # diese Zeile hinzufügen

OpenSearch neu starten

In OpenSearch die internen Benutzer aktualisieren

./plugins/opensearch-security/tools/securityadmin.sh \
  --ignore-clustername \
  --type internalusers \
  --file config/opensearch-security/internal_users.yml \
  --keystore config/virtimo/ssl/virtimo_keystore.jks \
  --keystore-alias opensearch_bpc \
  --keystore-password virtimo \
  --truststore config/virtimo/ssl/virtimo_truststore.jks

Test, ob das neue admin Passwort korrekt gesetzt wurde

curl --insecure -u admin:sehr_starkes_admin_pw 'https://localhost:9200'

Dem Benutzer bpc die Admin-Rechte wieder entziehen. Dafür in der config/opensearch.yml die vorher hinzugefügte Zeile wieder entfernen.
```
plugins.security.authcz.admin_dn:
  - "CN=opensearch_admin,OU=Dev,O=Virtimo AG,L=Berlin,C=DE"
```
OpenSearch neu starten

Zugriff mit abgeschaltetem Security-Feature

Es wird davon abgeraten den Zugriffsschutz für OpenSearch zu deaktivieren.

Sie können das Security-Feature über die Konfiguration (opensearch.yml) mit folgender Zeile abschalten:

Ausschnitt der opensearch.yml mit abgschaltetem Security Feature

plugins.security.disabled: true

Nachdem OpenSearch neu gestartet wurde, können Sie ohne Authentifizierung auf OpenSearch zugreifen.

Beispiel eine CURL Aufrufs ohne Authentifizierung

curl --insecure 'https://localhost:9200'

Es ist auch möglich den Karaf Zugriff auf diese Authentifizierungsmethode umzustellen. Davon wird jedoch abgeraten.

Siehe auch BPC Konfigurationsdatei.

karaf/etc/de.virtimo.bpc.core.cfg

de.virtimo.bpc.core.opensearch.scheme = http

Keywords: