Referenzarchitektur für die Lösung: Generative KI-Funktionen von Elastic Stack in GDC mit Air Gap bereitstellen

Übersicht

Diese Referenzarchitektur definiert das konzeptionelle Design für die Bereitstellung des Elastic Stack (Elasticsearch und Kibana) in Google Distributed Cloud (GDC) mit Air Gap und die Integration in einen LLM-Dienst (Large Language Model), um die generativen KI-Funktionen von Elastic zu aktivieren.

Der Elastic Stack ist eine weit verbreitete Plattform für Suche, Beobachtbarkeit und Sicherheitsanalysen. In den letzten Elastic-Releases wurden Kibana generative KI-Funktionen hinzugefügt, darunter der Elastic AI Agent, benutzerdefinierte Agenten, die mit Agent Builder erstellt wurden, und Attack Discovery. Diese Funktionen basieren auf einem LLM, um Anfragen in natürlicher Sprache in Elasticsearch-Abfragen zu übersetzen, mehrstufige Toolaufrufe zu orchestrieren und Sicherheitswarnungen zu korrelieren.

In dieser Architektur wird der Elastic Stack mithilfe des offiziellen Elastic Cloud on Kubernetes (ECK)-Operators bereitgestellt, der im GDC-Marktplatz mit Air Gap verfügbar ist. Kibana wird mit einem LLM-Inferenzendpunkt verbunden, der innerhalb der GDC-Grenze gehostet wird, entweder dem verwalteten Gemini-Dienst in GDC oder einem selbstverwalteten OpenAI-kompatiblen Inferenzserver wie Ollama oder vLLM.

Funktionen

Die Lösung bietet mehrere wichtige Funktionskomponenten für die KI-gestützte Suche, Beobachtbarkeit und Sicherheitsanalyse:

• Marketplace-basiertes Lebenszyklusmanagement: Installieren Sie den ECK-Operator aus dem GDC mit Air Gap-Marketplace in einem Projekt-Namespace auf einem freigegebenen Cluster und lassen Sie ihn die Bereitstellung, Konfiguration und Abstimmung von benutzerdefinierten Elasticsearch- und Kibana-Ressourcen automatisieren.
• Datenuntersuchung in natürlicher Sprache: Verwenden Sie den Elastic KI-Agent, um Elasticsearch-Daten in natürlicher Sprache zu untersuchen. Der Agent erkennt Indexe und Zuordnungen, generiert und führt ES|QL-Abfragen aus und fasst die Ergebnisse zusammen, ohne dass Vorkenntnisse des zugrunde liegenden Schemas erforderlich sind.
• Benutzerdefinierte KI-Agenten und automatisierte Workflows: Mit Agent Builder können Sie zweckbestimmte KI-Agenten erstellen, die benutzerdefinierte Anweisungen mit integrierten Tools, benutzerdefinierten ES|QL-Tools und Kibana-Workflows kombinieren (z. B. automatisches Öffnen von Kibana-Sicherheitsfällen mit Untersuchungsergebnissen).
• KI-gestützte Korrelation von Sicherheitswarnungen: Mit Attack Discovery können Sie offene Elastic Security-Warnungen analysieren, sie dem MITRE ATT&CK-Framework zuordnen und zugehörige Warnungen, IP-Adressen und Nutzerkonten in Angriffsketten korrelieren.
• Kompatibilität mit Air Gap: Die Container-Images für den ECK-Operator, Elasticsearch und Kibana werden aus der lokalen GDC-Harbor-Registry abgerufen und der gesamte LLM-Inferenz-Traffic bleibt im internen GDC-Netzwerk.
• Pluggable LLM Backends: Verbinden Sie Kibana mit verwaltetem Gemini auf GDC oder mit einem selbstverwalteten Inferenzserver, der eine OpenAI-kompatible /v1/chat/completions-API über den OpenAI-Connector von Kibana bereitstellt.

Architekturprinzipien

• Modell der gemeinsamen Verantwortung: GDC stellt den freigegebenen Cluster, das Marketplace-Paket, die Harbor-Registry und das Netzwerk bereit. Der Kunde betreibt die Elastic Stack-Bereitstellung, verwaltet die Elastic-Lizenzierung und ist für die Auswahl und den Betrieb des selbstverwalteten LLM-Dienstes (falls verwendet) verantwortlich.
• Datenhoheit: Alle Betriebs- und Sicherheitsdaten, Prompts und Modellantworten verbleiben innerhalb der GDC mit Air Gap-Grenze. Es wird kein Traffic an von Elastic gehostete oder öffentliche LLM-Dienste gesendet.
• Cloudnative Vorgänge: Verwendet das Kubernetes-Operator-Muster, um zustandsorientierte Elastic-Arbeitslasten deklarativ zu verwalten und so konsistente und wiederholbare Bereitstellungen zu ermöglichen.
• Protokollstandardisierung: Basiert auf der weitgehend unterstützten OpenAI-kompatiblen Chat-Vervollständigungs-API mit nativen Funktionsaufrufen, wodurch Kibana von einer bestimmten Inferenz-Engine oder einem bestimmten Modellanbieter entkoppelt wird.

Architektur

Die Architektur besteht aus einer Elastic Stack-Bereitstellung, die vom ECK-Operator in einem Projekt-Namespace auf einem freigegebenen GDC-Nutzercluster verwaltet wird. Kibana kommuniziert über das interne GDC-Netzwerk mit einem LLM-Inferenzendpunkt.

Zu den wichtigsten Komponenten dieser Architektur gehören:

• Gemeinsam genutzter GDC-Cluster: Ein auf Organisationsebene gemeinsam genutzter Kubernetes-Cluster, der mit mehreren Projekten verbunden ist und GDC Marketplace-Softwarepakete und Anwendungsworkloads hostet.
• GDC-Projekt: Der Projekt-Namespace im freigegebenen Cluster, der den ECK-Operator, den Elasticsearch-Cluster, die Kibana-Instanz und die zugehörigen Kubernetes-Secrets und NetworkPolicies isoliert.
• Elastic Cloud on Kubernetes (ECK)-Operator: Der Operator wird vom GDC Marketplace im Projekt-Namespace installiert und verwaltet die benutzerdefinierten Ressourcen Elasticsearch und Kibana. Außerdem gleicht er die Elastic-Lizenz ab, die für generative KI-Funktionen und externe LLM-Connectors erforderlich ist.
• Elasticsearch: Speichert und indexiert Betriebs- und Sicherheitsdaten und führt Such- und ES|QL-Abfragen aus, die von den KI-Funktionen und -Agents von Kibana generiert werden.
• Kibana: Hostet die generativen KI-Funktionen von Elastic (Elastic AI Agent, Agent Builder und Attack Discovery) und verwaltet die LLM-Aktions-Connectors, die mehrstufige Toolaufrufe zwischen dem Nutzer, Elasticsearch und dem LLM-Dienst orchestrieren.
• LLM-Dienst: Ein verwalteter LLM-Dienst (z. B. Gemini on GDC) oder ein selbstverwalteter Inferenzserver (z. B. Ollama oder vLLM), der Kibana über das interne GDC-Netzwerk Chatvervollständigungs- und Toolaufruffunktionen bereitstellt.

Konzepte und Technologien

In diesem Abschnitt werden die funktionalen Komponenten, ihre Aufgaben und die Kommunikation innerhalb des Systems beschrieben.

Infrastruktur und Plattform

• Gemeinsam genutzter GDC-Cluster: Die primäre Compute-Umgebung, in der sich der ECK-Operator, Elasticsearch und Kibana-Pods in einem Projekt-Namespace befinden.
• GDC Marketplace: Der Katalog, der zum Installieren und Aktualisieren des Elastic Marketplace-Pakets verwendet wird, das die Elastic CustomResourceDefinitions registriert und das StatefulSet elastic-operator bereitstellt.
• Harbor Registry: Die sichere, lokale Quelle der Wahrheit für die Container-Images des ECK-Operators, von Elasticsearch und Kibana in der Air-Gap-Umgebung.
• Nichtflüchtiger Speicher: PersistentVolumeClaims, die über die Elasticsearch-volumeClaimTemplates bereitgestellt werden, bieten langlebigen Blockspeicher für Elasticsearch-Daten.
• GDC-Netzwerk: LoadBalancer-Dienste stellen Elasticsearch (Port 9200) und Kibana (Port 5601) bereit, während Kubernetes-NetworkPolicy- und globale ProjectNetworkPolicy-Ressourcen den eingehenden und projektübergreifenden Traffic steuern, einschließlich der Verbindung zum LLM-Dienst.

Dienste und Logik

• ECK-Operator: Der Controller, der die benutzerdefinierten Ressourcen Elasticsearch und Kibana überwacht und sie in StatefulSets, Deployments, Services und Secrets abgleicht. Der license-controller gleicht die Clusterlizenz kontinuierlich mit Lizenz-Secrets im Operator-Namespace ab.
• Elastic AI Agent: Der Standard-Konversations-Agent in Kibana. Es verwendet integrierte Agent Builder-Tools (platform.core.list_indices, platform.core.get_index_mapping, platform.core.search und platform.core.execute_esql), um Daten zu finden, ES|QL zu generieren und Ergebnisse zusammenzufassen.
• Agent Builder: Das Framework zum Erstellen benutzerdefinierter KI-Agenten, die benutzerdefinierte Systemanweisungen mit integrierten und benutzerdefinierten Tools (esql, index_search, workflow und mcp) kombinieren.
• Kibana-Workflows: Deklarative, YAML-definierte Automatisierungen (z. B. cases.createCase), die als Agent Builder-Tools registriert werden können, damit Agenten Aktionen wie das Öffnen von Kibana-Sicherheitsfällen ausführen können.
• Attack Discovery: Eine Elastic Security-Sicherheitsfunktion, die anonymisierten Warnungskontext an das LLM sendet, um Warnungen aus dem .alerts-security.alerts-default-Index mit Angriffsketten zu korrelieren, die MITRE ATT&CK-Taktiken zugeordnet sind.
• LLM-Dienst: Bietet anweisungsorientierte Chatvervollständigungen mit nativer Unterstützung für Toolaufrufe. Das Modell muss zuverlässig gültige Toolaufrufe, strukturiertes JSON und ES|QL-Abfragen generieren.

Datenfluss und Schnittstellen

• OpenAI-kompatible Chat-Vervollständigungs-API (/v1/chat/completions): Die Schnittstelle zwischen dem OpenAI-Connector (.gen-ai) von Kibana und dem LLM-Dienst, konfiguriert mit dem Anbieter Other (OpenAI Compatible Service), nativer Funktionsaufruf aktiviert und Server-Sent Events-Streaming.
• Elasticsearch REST und ES|QL APIs: Werden von Kibana und seinen Agents verwendet, um Zuordnungen zu prüfen, Suchanfragen auszuführen und ES|QL-Aggregationen auszuführen.
• Kibana REST APIs: Werden für die programmatische Verwaltung von Connectors (/api/actions), Agents und Tools (/api/agent_builder), Workflows (/api/workflows), Erkennungsregeln (/api/detection_engine) und Attack Discovery (/api/attack_discovery) verwendet.
• HTTPS mit integrierter Authentifizierung: Elasticsearch- und Kibana-Endpunkte werden über TLS mit von ECK generierten Zertifikaten bereitgestellt. Die Anmeldedaten werden in von ECK verwalteten Kubernetes-Secrets gespeichert.

Hinweise

• Skalierbarkeit und Leistung:
  • Ressourcenanfragen, Limits, Knotenzahlen und Speichergrößen für Elasticsearch und Kibana müssen von den Standardwerten für die Evaluierung an die Produktionsdatenmengen und die Nebenläufigkeit von Abfragen angepasst werden.
  • Der OpenAI-Connector von Kibana erzwingt ein Standardzeitlimit von 60 Sekunden pro Streaming-Turn. Der LLM-Dienst muss mit GPU-Beschleunigung und Optimierungen wie Flash Attention ausgeführt werden, damit jede Runde innerhalb dieses Limits bleibt.
  • Ein einzelner Agenten-Turn kann verschachtelte LLM-Unteraufrufe auslösen. Der Inferenzserver sollte mehrere parallele KV-Cache-Slots (z. B. OLLAMA_NUM_PARALLEL=2) verwalten, um zu verhindern, dass Unteraufrufe den im Cache gespeicherten Kontext der Hauptunterhaltung entfernen.
• Anforderungen an LLM-Modelle:
  • Das Modell muss mit nativer Unterstützung für Funktionsaufrufe abgestimmt sein. Native Funktionsaufrufe sollten für den Kibana-Connector aktiviert sein, da promptbasierte simulierte Funktionsaufrufe für verschachtelte Toolaufrufe weniger zuverlässig sind.
  • Ein Kontextfenster von mindestens 128.000 Tokens wird dringend empfohlen, da mehrstufige Untersuchungen, die Tooldefinitionen, Indexschemas, ES|QL-Dokumentation und Suchergebnisse kombinieren, 70.000 Tokens überschreiten können.
  • Für Modelle mit Reasoning-Fähigkeiten werden ein Ausgabetokenlimit von mindestens 8.192 Tokens und eine milde Wiederholungsstrafe empfohlen, da Kibana den Beendigungsgrund length als schwerwiegenden Fehler behandelt und Greedy Decoding verwendet.
  • Für Attack Discovery ist ein Modell der 30B-Klasse oder größer (z. B. gemma4:31b) erforderlich, um strukturierte Ausgaben mit mehreren Warnungen zuverlässig zu synthetisieren.
• Sicherheit und Compliance:
  • Alle Prompts, abgerufenen Daten und Modellantworten verbleiben im internen GDC-Netzwerk.
  • Netzwerkrichtlinien sollten von den standardmäßigen, weniger restriktiven Einstellungen verschärft werden, um den eingehenden Zugriff auf Elasticsearch und Kibana auf autorisierte Clients zu beschränken und den ausgehenden Traffic auf den LLM-Dienstendpunkt zu begrenzen.
  • Der Zugriff auf Kibana und Elasticsearch sollte über die rollenbasierte Zugriffssteuerung von Elastic und nicht über den Superuser elastic geregelt werden.
• Ressourcenverwaltung und Lizenzierung:
  • Für die generativen KI-Funktionen und externen LLM-Connectors von Elastic ist eine Enterprise-Lizenz (oder ein aktiver 30-tägiger Enterprise-Testzeitraum) erforderlich. Diese muss über ein ECK-Lizenz-Secret bereitgestellt werden, damit sie über die Abgleichszyklen des Operators hinweg erhalten bleibt.
• Verfügbarkeit und Zuverlässigkeit:
  • In Produktionsbereitstellungen sollten mehrere Elasticsearch-Knoten mit Replikat-Shards und mehrere Kibana-Instanzen verwendet werden, um Single Points of Failure zu vermeiden.
  • Die Verfügbarkeit von KI-Funktionen hängt von der Verfügbarkeit und Latenz des LLM-Dienstes ab.
• Betriebsmanagement:
  • Der Kunde ist für das Upgrade des Elastic Marketplace-Pakets und der Elastic Stack-Versionen, die Verwaltung von Lizenzen und die Sicherung von Elasticsearch-Daten verantwortlich.
  • Wenn ein selbstverwalteter LLM-Dienst verwendet wird, ist der Kunde für die Bereitstellung, die Planung der GPU-Kapazität, die Modellaktualisierungen und die Feinabstimmung verantwortlich.

Designentscheidung

Die primären Architekturentscheidungen für diese Lösung konzentrieren sich darauf, die generativen KI-Funktionen von Elastic innerhalb der Einschränkungen der Air-Gap-Umgebung zu aktivieren.

ECK-Operator aus dem GDC Marketplace

Der ECK-Operator wird über den GDC mit Air Gap-Marketplace installiert und nicht manuell bereitgestellt. Das Marketplace-Paket ist so vorkonfiguriert, dass Container-Images aus der lokalen Harbor-Registry abgerufen werden. Es registriert die erforderlichen CustomResourceDefinitions und lässt sich in GDC-IAM-Rollen auf Projektebene einbinden. Dadurch wird der Aufwand für die Bildspiegelung reduziert und die Bereitstellung bleibt auf den GDC-Softwarelebenszyklus abgestimmt.

Bereitstellung von freigegebenen Clustern

Die Lösung stellt den Elastic Stack in einem Projekt-Namespace in einem freigegebenen GDC-Cluster bereit. So können Kunden Marketplace-Software zusammen mit anderen Projektarbeitslasten nutzen, ohne einen dedizierten Cluster bereitstellen und betreiben zu müssen. Der Projekt-Namespace sorgt für die Isolation von Ressourcen, Secrets und Netzwerkrichtlinien.

LLM-Dienstoptionen

Verwaltetes Gemini auf GDC ist die bevorzugte Option, sofern verfügbar, da es den Betriebsaufwand für das Hosten der Inferenzinfrastruktur beseitigt. Wenn dieser nicht verfügbar ist oder Kunden ein bestimmtes offenes Modell benötigen, kann Kibana eine Verbindung zu jedem selbstverwalteten Inferenzserver herstellen, der einen OpenAI-kompatiblen /v1/chat/completions-Endpunkt bereitstellt. Durch die Standardisierung auf diese API bleibt die Elastic-Konfiguration unabhängig von der Inferenz-Engine (z. B. Ollama oder vLLM).

Native Funktionsaufrufe

Native Funktionsaufrufe sind für den Kibana-Connector aktiviert, sodass die Formatierung von Toolaufrufen an das OpenAI-tools-Protokoll des Inferenzservers delegiert wird. Die standardmäßige promptbasierte simulierte Funktionsaufrufe von Kibana sind bei verschachtelten Toolaufrufen weniger zuverlässig und können mit Parsing-Fehlern fehlschlagen.

ECK-verwalteter Lizenzabgleich

Die Enterprise-Lizenz (oder Testlizenz) wird als ECK-Lizenz-Secret deklariert, anstatt direkt über die Elasticsearch-Lizenz-API aktiviert zu werden. Da ECK die Clusterlizenz kontinuierlich abgleicht, werden außerhalb von ECK angewendete Lizenzen im nächsten Abgleichszyklus auf basic zurückgesetzt.

Annahmen und Einschränkungen

Annahmen

• Ein freigegebener GDC-Cluster und ein angehängtes Projekt sind verfügbar, mit ausreichender Rechen- und nichtflüchtiger Speicherkapazität für den ECK-Operator, Elasticsearch und Kibana.
• Das Elastic Marketplace-Paket und die entsprechenden Elasticsearch- und Kibana-Container-Images sind im GDC mit Air Gap-Marketplace und in der lokalen Harbor-Registry verfügbar.
• Nutzer haben die erforderlichen Projektrollen (namespace-admin, project-viewer, marketplace-editor und project-networkpolicy-admin).
• Ein LLM-Dienst (verwaltetes Gemini auf GDC oder ein selbstverwalteter OpenAI-kompatibler Inferenzserver) wird bereitgestellt und ist über das interne GDC-Netzwerk vom Kibana-Pod aus erreichbar.
• Eine Elastic Enterprise-Lizenz ist verfügbar oder die 30-tägige Enterprise-Testversion wird zur Evaluierung verwendet.

Beschränkungen

• LLM-Dienst nicht abgedeckt: Die Bereitstellung und der Betrieb eines selbstverwalteten LLM-Dienstes, einschließlich der GPU-Infrastruktur, werden von dieser Architektur nicht abgedeckt.
• Keine von Elastic gehosteten KI-Dienste: Von Elastic verwaltete LLMs und andere in der Cloud gehostete Elastic-KI-Dienste sind in der Air-Gap-Umgebung nicht verfügbar.
• Modellabhängige Qualität: Die Genauigkeit und Zuverlässigkeit der Ergebnisse von KI-Agent, Agent Builder und Attack Discovery hängen von den Funktionen des ausgewählten Modells und seiner Laufzeitkonfiguration ab.
• Standardeinstellungen für die Evaluierung: Die Referenzimplementierung verwendet einen Elasticsearch-Cluster mit einem einzelnen Knoten, selbst signierte Zertifikate und permissive Netzwerkrichtlinien, die für die Produktion gehärtet werden müssen.
• Versionsspezifität: Die Lösung wurde mit Elastic v9.4.0, dem Elastic Kubernetes Operator v3.4.0 und GDC v1.16.2 validiert. Für andere Versionen sind möglicherweise Anpassungen erforderlich.

Zusätzliche Materialien

Referenzimplementierung der Lösung (SRI): Generative KI-Funktionen von Elastic Stack in GDC mit Air Gap bereitstellen