Elasticsearch du client
Elasticsearch n'est jamais installé par Navin : ses licences (AGPL-3.0, SSPL-1.0 ou Elastic-2.0) sont hors de la
politique de la plateforme (ADR-0101) et OpenSearch le remplace. Une banque qui exploite déjà un Elasticsearch peut
pourtant y envoyer les journaux et les traces de la plateforme : le Manager s'y branche par une connexion, comme à un
service existant. Contrat : navin-manager/CONTRACT.md (section 10, Elasticsearch du client).
Ce qui s'y connecte
| Service | Liaison | Ce qui est écrit |
|---|---|---|
otel-collector | elasticsearch (optionnelle) | Journaux OTLP dans le flux de données logs-eai.otel-default (mappage OpenTelemetry), en plus d'OpenSearch quand les deux sont liés |
jaeger | elasticsearch (optionnelle) | Intervalles dans les index eai-jaeger-span-* et eai-jaeger-service-* ; Elasticsearch passe avant OpenSearch quand les deux sont liés |
Versions
Elasticsearch 8.12 ou une 8.x plus récente : le mappage OpenTelemetry du collecteur utilise le paramètre
require_data_stream de l'API bulk, apparu en 8.12, et le collecteur 0.130.0 annonce l'API d'Elasticsearch 7.17 et
8.x. Le Manager ne connaît pas la version d'une connexion avant l'installation : le contrôle préalable demande de la
confirmer (avertissement, jamais bloquant). Vérifié avec Elasticsearch 8.19.24.
Déclarer la connexion
- Administration, Connexions, nouvelle connexion de type Elasticsearch : une URL par nœud
(
https://es-1.banque.example:9200), l'utilisateur, son mot de passe, et le certificat de l'autorité du cluster (PEM) quand il n'est pas émis par une autorité publique. Laisser la vérification du certificat active. - Tester : le Manager appelle
GET /avec cet utilisateur et affiche la version du cluster ; un mauvais mot de passe est refusé (auth_failed). - Dans l'assistant d'installation de
otel-collectorou dejaeger, choisir cette connexion pour la liaisonelasticsearch.
Droits de l'utilisateur
Le rôle minimal, à créer par l'équipe Elasticsearch de la banque (API _security/role ou Kibana) :
{
"cluster": ["monitor", "manage_index_templates"],
"indices": [
{"names": ["logs-eai.otel-*"], "privileges": ["create_doc", "auto_configure"]},
{"names": ["eai-jaeger-*"], "privileges": ["create_index", "index", "read", "view_index_metadata"]}
]
}
manage_index_templates sert à Jaeger, qui crée ses modèles d'index au démarrage ; monitor permet aux deux
clients de lire l'état du cluster.
Ce que le Manager écrit
- La configuration du collecteur ou de Jaeger, un fichier sensible, contient l'utilisateur et le mot de passe ; le mot de passe n'est jamais sur la ligne de commande.
- Le certificat de l'autorité de la connexion est écrit à côté (
external-ca.pem, 0644) et la vérification du certificat suit l'option de la connexion.
Ce qui a été vérifié
navin-manager/server/tests/test_elasticsearch_connection_real.py lance Elasticsearch 8.19.24 avec la sécurité active
(HTTPS avec une autorité de test, utilisateurs du realm fichier), le collecteur 0.130.0 et Jaeger 2.22.0 du catalogue,
avec la configuration rendue depuis une connexion, puis :
- fait le test de connexion du Manager : version lue avec le bon mot de passe, refus avec un mauvais ;
- envoie un journal au collecteur et le retrouve dans le flux de données
logs-eai.otel-default; - envoie une trace au collecteur, qui la transmet à Jaeger : elle est stockée dans
eai-jaeger-span-*et relue par l'API de requête de Jaeger ; - écrit avec un utilisateur limité au rôle ci-dessus.
test_catalog_obs.py vérifie les rendus (plusieurs nœuds, certificat de la connexion, vérification désactivée,
cluster HTTP sans sécurité, méthodes binaire et Podman) et test_platform_no_agpl.py qu'aucun service, image ou
téléchargement d'Elasticsearch n'entre dans le catalogue.
Limites
- Authentification par utilisateur et mot de passe (realm natif, fichier, LDAP ou Active Directory d'Elasticsearch) : pas de clé d'API ni de certificat client pour cette connexion, pas d'Elastic Cloud par identifiant de cloud (donner l'URL du point d'accès).
- Elasticsearch 9 n'a pas été essayé.
- La rétention (cycle de vie du flux de données, ILM) et les index restent gérés par l'équipe Elasticsearch de la banque.
- OpenSearch Dashboards et OpenSearch Security Analytics ne lisent pas cet Elasticsearch : les journaux et traces qui y sont écrits se consultent avec les outils de la banque (Kibana) et l'interface de Jaeger.