Elastic Stack (ELK)

Elastic Stack (ELK)

Intégration maintenue par Orkyvo (non certifiée par Elastic N.V.) pour Elasticsearch, Logstash et Kibana 8.x (Elastic Cloud ou autohébergé). Chaque opération porte le nom de son composant : rien n'est supposé d'un composant à l'autre.

Connexion

Les secrets sont chiffrés et masqués dans l'interface, les journaux, les erreurs et les exports. Une adresse privée (cluster sur site) doit être autorisée par un administrateur de la plateforme pour cette connexion ; l'entrée HTTP Logstash sans TLS n'est acceptée que si la règle l'autorise explicitement.

Clé d'API aux privilèges limités (exemple, à créer par POST /_security/api_key) :

{
  "name": "orkyvo",
  "expiration": "365d",
  "role_descriptors": {
    "orkyvo": {
      "cluster": ["monitor"],
      "indices": [
        { "names": ["logs-*"], "privileges": ["read", "view_index_metadata"] },
        { "names": ["incidents"], "privileges": ["read", "create_doc", "index", "write"] }
      ]
    }
  }
}

« Tester la connexion » lit GET / et GET /_security/_authenticate ; l'entrée Logstash n'est pas contactée (un envoi est une écriture).

Elasticsearch

Le sélecteur d'index propose les index ouverts et des motifs (logs-api*) ; la saisie manuelle et les données des étapes précédentes restent possibles.

Logstash : entrée HTTP

Orkyvo envoie des événements à Logstash ; Logstash ne propose pas de recherche de journaux (la recherche se fait dans Elasticsearch). L'entrée HTTP doit exister côté Logstash avant tout envoi : sans elle, l'étape échoue (connexion refusée ou 404).

Exemple de pipeline (/etc/logstash/conf.d/orkyvo.conf) :

input {
  http {
    port => 8080
    ssl_enabled => true
    ssl_certificate => "/etc/logstash/certs/logstash.crt"
    ssl_key => "/etc/logstash/certs/logstash.key"
    user => "orkyvo"
    password => "${ORKYVO_HTTP_PASSWORD}"
    additional_codecs => { "application/json" => "json" }
  }
}
filter {
  # Dédoublonnage : un même orkyvo.event_id produit le même document.
  fingerprint { source => ["[orkyvo][event_id]"] target => "[@metadata][fingerprint]" method => "SHA256" }
  mutate { remove_field => ["[http][request][headers][authorization]"] }
}
output {
  elasticsearch {
    hosts => ["https://es.example.com:9200"]
    api_key => "${ES_API_KEY}"
    index => "orkyvo-events"
    document_id => "%{[@metadata][fingerprint]}"
  }
}

Logstash répond 200 ok dès réception. Chaque événement reçoit orkyvo.event_id (saisi, ou dérivé de l'étape et stable en cas de nouvelle tentative). Un envoi n'est jamais relancé automatiquement après une réponse réseau perdue (« Résultat incertain ») ; avec document_id ci-dessus, un renvoi manuel ne crée pas de doublon.

Kibana : alertes reçues par webhook

Prérequis :

• Licence : le connecteur *Webhook* est disponible sur Elastic Cloud et, en autohébergé, à partir de la licence Gold (ou en période d'essai).
• Kibana doit pouvoir joindre l'URL publique d'Orkyvo en HTTPS. En autohébergé, l'hôte peut devoir figurer dans xpack.actions.allowedHosts.

Mise en place :

1. Ajoutez le déclencheur « Kibana · Alerte reçue » et publiez le workflow : l'URL du webhook et le secret s'affichent dans l'éditeur (« Afficher le secret »).
2. Dans Kibana : *Stack Management → Connectors → Webhook*. Méthode POST, URL du workflow, en-tête X-Orkyvo-Token: <secret>, en-tête Content-Type: application/json.
3. Dans la règle d'alerte, ajoutez une action avec ce connecteur et le corps suivant (variables disponibles selon le type de règle) :

{
  "rule": { "id": "{{rule.id}}", "name": "{{rule.name}}", "url": "{{rule.url}}", "tags": "{{rule.tags}}" },
  "alert": { "id": "{{alert.id}}", "uuid": "{{alert.uuid}}", "actionGroup": "{{alert.actionGroup}}", "actionGroupName": "{{alert.actionGroupName}}", "flapping": "{{alert.flapping}}" },
  "context": { "reason": "{{context.reason}}", "value": "{{context.value}}", "conditions": "{{context.conditions}}", "link": "{{context.link}}" },
  "date": "{{date}}",
  "kibanaBaseUrl": "{{kibanaBaseUrl}}"
}

Chaque appel est vérifié (en-tête secret, comparaison à temps constant, jamais enregistré). Les nouvelles tentatives de Kibana pour une même notification sont dédoublonnées (règle, alerte, groupe d'action et date). Le workflow reçoit rule, alert, recovered (groupe recovered), context, date et kibanaBaseUrl.

Erreurs

401 clé d'API invalide ou expirée · 403 privilège manquant sur l'index · 404 index ou document introuvable · 409 document déjà existant (création) ou conflit de version · 429 / 5xx temporaires (lectures relancées selon Retry-After). Certificat refusé : ajoutez l'autorité interne.

Limites

• Tests automatisés sur API simulées ; test réel sur un déploiement d'essai Elastic Cloud ou docker compose local : docs/INTEGRATIONS.md.