Aller au contenu principal

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​

ServiceLiaisonCe qui est écrit
otel-collectorelasticsearch (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
jaegerelasticsearch (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​

  1. 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.
  2. Tester : le Manager appelle GET / avec cet utilisateur et affiche la version du cluster ; un mauvais mot de passe est refusé (auth_failed).
  3. Dans l'assistant d'installation de otel-collector ou de jaeger, choisir cette connexion pour la liaison elasticsearch.

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.