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 einer isolierten Google Distributed Cloud-Umgebung (GDC) und die Integration in einen Large Language Model-Dienst (LLM), um die generativen KI-Funktionen von Elastic zu aktivieren.

Der Elastic Stack ist eine weit verbreitete Plattform für Suche, Observability und Sicherheitsanalysen. Mit den neuesten Versionen von Elastic wurden Kibana generative KI-Funktionen hinzugefügt, darunter der Elastic AI Agent, benutzerdefinierte Agenten, die mit Agent Buildererstellt wurden, und Attack Discovery. Diese Funktionen verwenden ein LLM, um Anfragen in natürlicher Sprache in Elasticsearch-Abfragen zu übersetzen, mehrstufige Toolaufrufe zu orchestrieren und Sicherheitswarnungen zu korrelieren.

Diese Architektur stellt den Elastic Stack mit dem offiziellen Elastic Cloud on Kubernetes-Operator (ECK) bereit, der im GDC mit Air Gap Marketplace verfügbar ist. Außerdem wird Kibana mit einem LLM-Inferenzendpunkt verbunden, der innerhalb der GDC-Grenzen gehostet wird. Dabei kann es sich entweder um den verwalteten Gemini-Dienst in GDC oder einen selbstverwalteten OpenAI-kompatiblen Inferenzserver wie Ollama oder vLLM handeln.

Funktionen

Die Lösung bietet mehrere funktionale Kernkomponenten für KI-gestützte Suche, Observability und Sicherheitsanalysen:

• Marketplace-basiertes Lebenszyklusmanagement: Installieren Sie den ECK-Operator aus dem GDC mit Air Gap Marketplace in einem Projekt-Namespace in einem freigegebenen Cluster und lassen Sie ihn die Bereitstellung, Konfiguration und Abstimmung von Elasticsearch und Kibana benutzerdefinierten Ressourcen automatisieren.
• Datenuntersuchung in natürlicher Sprache: Verwenden Sie den Elastic AI 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 Ergebnisse zusammen, ohne dass Vorkenntnisse des zugrunde liegenden Schemas erforderlich sind.
• Benutzerdefinierte Agenten und automatisierte Workflows: Mit Agent Builder können Sie speziell entwickelte 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 zu Angriffsketten korrelieren.
• Kompatibilität mit isolierten Umgebungen: Die Container-Images für den ECK-Operator, Elasticsearch und Kibana werden aus der lokalen GDC Harbor-Registrierung abgerufen und der gesamte LLM-Inferenz-Traffic bleibt im internen GDC-Netzwerk.
• Plug-in-fähige LLM-Back-Ends: Verbinden Sie Kibana mit dem verwalteten Gemini in GDC oder mit einem beliebigen selbstverwalteten Inferenzserver, der eine OpenAI-kompatible /v1/chat/completions API über den OpenAI -Connector von Kibana bereitstellt.

Architekturprinzipien

• Modell der geteilten Verantwortung: GDC stellt den freigegebenen Cluster, das Marketplace-Paket, die Harbor-Registrierung und die Netzwerke 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 verantwortlich (falls verwendet).
• Datenhoheit: Alle Betriebs- und Sicherheitsdaten, Prompts und Modell antworten bleiben innerhalb der GDC mit Air Gap-Umgebung. Es wird kein Traffic an von Elastic gehostete oder öffentliche LLM-Dienste gesendet.
• Cloud-nativer Betrieb: Verwendet das Kubernetes-Operatormuster, um zustandsbehaftete Elastic-Arbeitslasten deklarativ zu verwalten und so konsistente und wiederholbare Bereitstellungen zu gewährleisten.
• Protokollstandardisierung: Verwendet die weit verbreitete OpenAI-kompatible Chat-Vervollständigungs-API mit nativem Funktionsaufruf, wodurch Kibana von einem bestimmten Inferenz-Engine- oder Modellanbieter entkoppelt wird.

Architektur

Die Architektur besteht aus einer Elastic Stack-Bereitstellung, die vom ECK-Operator in einem Projekt-Namespace in 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:

• Freigegebener GDC-Cluster: Ein organisationsweiter freigegebener Kubernetes-Cluster, der mit mehreren Projekten verbunden ist und GDC Marketplace Softwarepakete und Anwendungsarbeitslasten 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-Operator (ECK): Der Operator wird aus dem GDC Marketplace in den Projekt-Namespace installiert. Er verwaltet die Elasticsearch und Kibana benutzerdefinierten Ressourcen und stimmt die für generative KI-Funktionen und externe LLM-Connectors erforderliche Elastic-Lizenz ab.
• Elasticsearch: Speichert und indexiert Betriebs- und Sicherheitsdaten und führt Such- und ES|QL-Abfragen aus, die von den KI-Funktionen und Agenten von Kibana generiert wurden.
• 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 in GDC) oder ein selbstverwalteter Inferenzserver (z. B. Ollama oder vLLM), der Kibana über das interne GDC-Netzwerk Chat-Vervollständigungs- und Toolaufruffunktionen bietet.

Konzepte und Technologien

In diesem Abschnitt werden die funktionalen Komponenten, ihre Verantwortlichkeiten und die Art und Weise beschrieben, wie sie im System kommunizieren.

Infrastruktur und Plattform

• Freigegebener GDC-Cluster: Die primäre Compute Umgebung, in der sich die ECK-Operator-, Elasticsearch- und Kibana-Pods befinden in einem Projekt-Namespace.
• GDC Marketplace: Der Katalog, der zum Installieren und Aktualisieren des Elastic Marketplace-Pakets verwendet wird. Dadurch werden die benutzerdefinierten Ressourcendefinitionen von Elastic registriert und das StatefulSet elastic-operator bereitgestellt.
• Harbor-Registrierung: Die sichere, lokale Quelle der Wahrheit für die Container-Images des ECK-Operators, von Elasticsearch und Kibana in der isolierten Umgebung.
• Nichtflüchtiger Speicher: PersistentVolumeClaims, die über die Elasticsearch volumeClaimTemplates bereitgestellt werden, bieten dauerhaften Blockspeicher für Elasticsearch-Daten.
• GDC-Netzwerk: LoadBalancer-Dienste machen Elasticsearch (Port 9200) und Kibana (Port 5601) verfügbar, 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 Elasticsearch und Kibana benutzerdefinierte Ressourcen überwacht und sie in StatefulSets, Bereitstellungen, Dienste und Secrets abstimmt. Der license-controller stimmt die Clusterlizenz kontinuierlich mit den Lizenz-Secrets im Operator-Namespace ab.
• Elastic AI Agent: Der standardmäßige konversationelle Agent in Kibana. Er 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 ermitteln, ES|QL zu generieren und Ergebnisse zusammenzufassen.
• Agent Builder: Das Framework zum Erstellen benutzerdefinierter Agenten, die benutzerdefinierte Systemanweisungen mit integrierten und benutzerdefinierten Tools (esql, index_search, workflow, und mcp) kombinieren.
• Kibana-Workflows: Deklarative, in 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 Warnkontext an das LLM sendet, um Warnungen aus dem .alerts-security.alerts-default Index zu Angriffsketten zu korrelieren, die MITRE ATT&CK-Taktiken zugeordnet sind.
• LLM-Dienst: Bietet auf Anweisungen abgestimmte Chat-Vervollständigungen mit nativer Toolaufrufunterstützung. 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), aktiviertem nativem Funktionsaufruf und Server-Sent Events-Streaming.
• Elasticsearch REST- und ES|QL-APIs: Werden von Kibana und seinen Agenten verwendet, um Zuordnungen zu prüfen, Suchvorgänge auszuführen und ES|QL-Aggregationen auszuführen.
• Kibana REST APIs: Werden für die programmatische Verwaltung von Connectors (/api/actions), Agenten 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 vom 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 Standardeinstellungen für die Evaluierung an die Produktionsdatenmengen und die Abfragekonkurrenz 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 jeder Turn innerhalb dieses Limits bleibt.
  • Ein einzelner Agent-Turn kann verschachtelte LLM-Unteraufrufe auslösen. Der Inferenzserver sollte mehrere parallele KV-Cache-Slots verwalten (z. B. OLLAMA_NUM_PARALLEL=2), um zu verhindern, dass Unteraufrufe den im Cache gespeicherten Kontext der Hauptunterhaltung verdrängen.
• Anforderungen an das LLM-Modell:
  • Das Modell muss auf Anweisungen abgestimmt sein und den nativen Funktionsaufruf unterstützen. Der native Funktionsaufruf sollte für den Kibana-Connector aktiviert sein, da der promptbasierte simulierte Funktionsaufruf für verschachtelte Toolaufrufe weniger zuverlässig ist.
  • Ein Kontextfenster von mindestens 128.000 Tokens wird dringend empfohlen, da mehrstufige Untersuchungen, die Tooldefinitionen, Indexschemata, ES|QL-Dokumentation und Suchergebnisse kombinieren, 70.000 Tokens überschreiten können.
  • Für Modelle mit Reasoning-Funktionen werden ein Limit von mindestens 8.192 Ausgabetokens und eine moderate Wiederholungsstrafe empfohlen, da Kibana einen length-Abschlussgrund als schwerwiegenden Fehler behandelt und Greedy Decoding verwendet.
  • Für Attack Discovery ist ein Modell der 30B-Klasse oder höher (z. B. gemma4:31b) erforderlich, um zuverlässig strukturierte Ausgaben mit mehreren Warnungen zu synthetisieren.
• Sicherheit und Compliance:
  • Alle Prompts, abgerufenen Daten und Modellantworten bleiben im internen GDC-Netzwerk.
  • Die Netzwerkrichtlinien sollten von permissiven Evaluierungseinstellungen auf restriktivere Einstellungen umgestellt werden, um den eingehenden Zugriff auf Elasticsearch und Kibana auf autorisierte Clients zu beschränken und den ausgehenden Zugriff 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 verwaltet werden.
• Ressourcenverwaltung und Lizenzierung:
  • Für die generativen KI-Funktionen von Elastic und externe LLM-Connectors ist eine Enterprise-Lizenz (oder eine aktive 30-tägige Enterprise-Testversion) erforderlich, die über ein ECK-Lizenz-Secret bereitgestellt werden muss, um über Operator-Abstimmungszyklen hinweg zu bestehen.
• Verfügbarkeit und Zuverlässigkeit:
  • Bei Produktionsbereitstellungen sollten mehrere Elasticsearch-Knoten mit Replikashards 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, Modellupdates und die Abstimmung verantwortlich.

Designentscheidung

Die wichtigsten architektonischen Entscheidungen für diese Lösung konzentrieren sich darauf, die generativen KI-Funktionen von Elastic innerhalb der Einschränkungen der Umgebung mit Air Gap zu ermöglichen.

ECK-Operator aus dem GDC Marketplace

Der ECK-Operator wird aus dem isolierten GDC Marketplace installiert und nicht manuell bereitgestellt. Das Marketplace-Paket ist vorkonfiguriert, um Container-Images aus der lokalen Harbor-Registrierung abzurufen, die erforderlichen benutzerdefinierten Ressourcendefinitionen zu registrieren und in IAM-Rollen auf GDC-Projektebene zu integrieren. Dadurch wird der Aufwand für das Spiegeln von Images reduziert und die Bereitstellung wird an den GDC-Softwarelebenszyklus angepasst.

Bereitstellung eines freigegebenen Clusters

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 bietet eine Isolation von Ressourcen, Secrets und Netzwerkrichtlinien.

Optionen für LLM-Dienste

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

Nativer Funktionsaufruf

Der native Funktionsaufruf ist für den Kibana-Connector aktiviert, sodass die Formatierung des Toolaufrufs an das OpenAI-Protokoll tools des Inferenzservers delegiert wird. Der standardmäßige promptbasierte simulierte Funktionsaufruf von Kibana ist bei verschachtelten Toolaufrufen weniger zuverlässig und kann zu Parsingfehlern führen.

ECK-verwaltete Lizenzabstimmung

Die Enterprise-Lizenz (oder Testlizenz) wird als ECK-Lizenz-Secret deklariert und nicht direkt über die Elasticsearch-Lizenz-API aktiviert. Da ECK die Clusterlizenz kontinuierlich abstimmt, werden Lizenzen, die außerhalb von ECK angewendet werden, im nächsten Abstimmungszyklus auf basic zurückgesetzt.

Annahmen und Einschränkungen

Annahmen

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

Einschränkungen

• LLM-Dienst außerhalb des Umfangs: Die Bereitstellung und der Betrieb eines selbstverwalteten LLM Dienstes, einschließlich der GPU-Infrastruktur, sind in dieser Architektur nicht enthalten.
• Keine von Elastic gehosteten KI-Dienste: Von Elastic verwaltete LLMs und andere in der Cloud gehostete KI-Dienste von Elastic sind in der Umgebung mit Air Gap 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 Knoten, selbst signierte Zertifikate und permissive Netzwerkrichtlinien, die für den Produktionseinsatz 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. Bei anderen Versionen sind möglicherweise Anpassungen erforderlich.

Zusätzliche Materialien

Referenzimplementierung der Lösung: Bereitstellung der generativen KI-Funktionen von Elastic Stack in einer GDC mit Air Gap