Moderne Observability und Security in Kubernetes mit Elastic und OpenTelemetry

Aufgrund seiner Struktur macht Kubernetes die Bereitstellung und Verwaltung von Diensten und Anwendungen wiederholbar und skalierbar. Dadurch hat sich die Plattform in den verschiedenen Marktsegmenten sowohl für lokale als auch für Cloud-Bereitstellungsmodelle durchgesetzt. Die autonome Ausführung von Kubernetes erfordert jedoch umfassende, vollständig konvergente Observability und Security. Dies ist aktuell nur mit der Elastic Platform möglich.

In diesem Artikel werden Best Practices für die Beobachtung und den Schutz von Anwendungs- und Dienst-Workflows auf Kubernetes mit Elasticsearch und OpenTelemetry vorgestellt. Sie lernen Folgendes:

• Bereitstellen und Konfigurieren von Elastic Agent in Ihrem Kubernetes-Cluster
• Ingestieren von OpenTelemetry-Anwendungs-Traces, -Metriken und -Events mit Elastic Agent
• Ingestieren von Kubernetes-Container-Logs, -Cluster-Metriken und -Netzwerkverkehrsmustern mit Elastic Agent
• Hinzufügen von sicherheitsbezogenem Monitoring und Bedrohungsschutz zu Ihrem Kubernetes-Cluster mit Elastic Defend
• Die integrierten Dashboards von Elastic zur Beobachtung, Korrelation und Durchführung von Ursachenanalysen bei Betriebsproblemen

Datensilos gefährden die Problembehandlung für Kubernetes-Bereitstellungen

Bislang wurden Anwendungs-Observability, Infrastruktur-Observability und Infrastruktur-Sicherheit in der Branche als getrennte Bereiche betrachtet, die jeweils mit separaten Tools von separaten Teams verwaltet werden. Auch wenn diese Betrachtungsweise oft aus organisatorischer Sicht praktisch ist, so zeigen sich doch schnell die damit verbundenen Probleme und Einschränkungen:

Analysten (ob menschliche Analysten oder Analyse-Engines) müssen auf Daten aus den Bereichen Anwendungs-Observability, Infrastruktur-Observability und Infrastruktursicherheit zurückgreifen, um festzustellen, ob es sich bei einem bestimmten betrieblichen Problem um ein Problem mit der Infrastruktur, einen Anwendungsfehler oder eine Sicherheitsverletzung handelt. Darüber hinaus benötigen Spezialisten Zugriff auf absolut zuverlässige Daten aus allen drei Quellen, um die Ursache eines bestimmten Problems zu ermitteln.

Als Ausweichlösung duplizieren Kunden häufig ausgewählte Observability-Daten über mehrere Datenplattformen hinweg. Im besten Fall verdoppeln oder verdreifachen sich dadurch die Kosten für Datenspeicherung, Support und Schulung. Im schlimmsten Fall fehlen den Analysten wichtige Daten, die sie für die genaue Ursachenanalyse benötigen. Durch die dynamische und skalierbare Struktur von Kubernetes wird dieses Problem noch verschärft. Die Trennung von Observability- und Security-Plattformen ist zweifellos ein Widerspruch zu dem ansonsten integrierten Modell der Dienstbereitstellung, das Kubernetes bietet. 

Ein günstiger Zeitpunkt für Observability

Letztlich benötigen Entwickler, Betreiber und Sicherheitsanalysten gleichermaßen eine zentrale Gesamtübersicht über ihr System, die sich über sämtliche Anwendungen und die gesamte Infrastruktur erstreckt. Teams für die Infrastrukturbereitstellung benötigen ein einheitliches, auf Kubernetes basierendes Bereitstellungsmodell, um diese Transparenz zu gewährleisten und ihre Cluster zu schützen.

Dazu sind drei Voraussetzungen erforderlich:

1. Alle Observability- und Security-Daten, einschließlich Anwendungs-, Dienst- und Infrastrukturlogs, Traces, Events und Metriken, müssen in einer einheitlichen Datenplattform gespeichert werden, die sowohl für die Suche (Korrelation und Latenz) als auch die Speicherung (Kosten) optimiert ist.
2. Die zentrale Datenplattform muss auch Daten korrelieren und rollenbasiert darstellen können: Wenn beispielsweise ein Analyst versucht, die Ursache eines Problems zu finden, sollte die Plattform den Analysten zu dem wahrscheinlichen Problem führen und ihm eine nahtlose Interaktion mit den Daten ermöglichen, unabhängig von der zugrunde liegenden Form oder Quelle.
3. Die Instrumentierung von Anwendungen und Infrastruktur sollte mit dem Grundsatz von Kubernetes im Einklang stehen: wiederholbare, skalierbare Bereitstellungen ohne individuelle Konfiguration.

Elastic: für Kubernetes

Das Zusammenspiel von Technologien von Elastic, OpenTelemetry, Kubernetes und moderner Computing-Hardware macht heute umfassende Kubernetes-Observability und -Security möglich:

• OpenTelemetry stellt einen Schlüssel für (interne wie externe) Entwickler dar, um alle ihre Anwendungen und Dienste vollständig zu instrumentieren, indem die Auswahl des APM-Anbieters von der APM-Implementierung entkoppelt wird.
• Moderne Computing-Hardware mit reichlich CPU und Arbeitsspeicher macht „permanentes“ Tracing ohne Leistungseinbußen möglich, selbst für Echtzeitanwendungen.
• Die neueste Elastic-Architektur, die durchsuchbare Snapshots umfasst, und der neue Zeitreihendaten-Stream in Verbindung mit dem intelligenten tail-basierten Sampling von Elastic APM machen eine mehrjährige Online-Speicherung von umfangreichen Observability- und Security-Daten möglich und erschwinglich.
• Die Bereitstellung von Elastic Agent im DaemonSet auf jedem Kubernetes-Knoten ermöglicht die wiederholbare und skalierbare Bereitstellung einer zentralen Datenerfassungs-Engine, die remote gesteuert werden kann. Nach der Bereitstellung können Elastic Agents als Flotte verwaltet werden, um auf einfache Art und Weise Datenintegrationen hinzuzufügen, zu konfigurieren oder zu entfernen.
• Die Elastic Platform bietet eine umfassend integrierte Kubernetes-Security-Lösung, die Schutz, Beobachtung und Zustandsverwaltung umfasst.
• Elasticsearch ermöglicht Korrelation und Empfehlungen für sämtliche gesammelten Datenquellen durch vordefinierte Dashboards, Anomalieerkennung und Warnmeldungen.

Datenerfassungsmodell

Wie Sie im folgenden Diagramm sehen können, empfehlen wir ein hybrides Modell für die Erfassung von Observability- und Security-Daten: Mit dem Elastic Agent werden Infrastrukturmetriken und Anwendungscontainer-Logs aus Kubernetes abgerufen und mit dem OpenTelemetry APM-Agent werden anwendungsbezogene Traces, Trace-Events und Metriken erfasst. Dieses Konzept wird im Folgenden näher erläutert.

Anwendungsbezogene Trace-, Event- und Metrikdaten

Um Anwendungs-Traces und -Metriken zu generieren, muss normalerweise eine APM-Bibliothek direkt in den Anwendungscode eingefügt werden. Durch den Einsatz von OpenTelemetry-APM-Agents können wir jedoch eine Anbieterbindung vermeiden, die einer APM-Einführung im Wege stehen könnte. Bis heute konzentriert sich OpenTelemetry auf zuverlässige und standardisierte Agent-Implementierungen zur Erfassung anwendungsbezogener Traces und Trace-Events und zunehmend auch von Anwendungsmetriken. Für fast jede gängige Programmiersprache gibt es heutzutage einigermaßen ausgereifte Agents. In vielen Fällen kann die automatische Instrumentierung verwendet werden, um Anwendungen mit wenig oder ganz ohne Programmieraufwand zu instrumentieren. Wenn Ihre Anwendungen in .NET, Java, NodeJS oder Python geschrieben sind und typische Frameworks verwenden, können Sie APM-Bibliotheken mit dem OpenTelemetry-Kubernetes-Operator sogar zur Laufzeit injizieren!

Für die Ursachenanalyse müssen APM-Daten mit Anwendungslogs und Infrastrukturmetriken korreliert werden. Um diese Korrelation zu ermöglichen, benötigen wir bestimmte identifizierende Metadaten oder Ressourcenattribute, die in allen Anwendungs-Traces, -Logs und Infrastrukturmetriken gleich sind. Die Elastic Platform verwendet service.name, pod.uid und container.id, um Observability-Daten von Anwendungen, die in Kubernetes laufen, zu verknüpfen. In der Vergangenheit mussten APM-Bibliotheken auf externe Instanzen zurückgreifen, um diese Metadaten zu erhalten. Einige der OpenTelemetry-APM-Bibliotheken unterstützen diese Funktionalität derzeit (z. B. Java), andere nicht (Rust). Dieser Ansatz vereinfacht zwar die Bereitstellung, ist aber zugegebenermaßen alles andere als ideal: APM-Agents (die im Kontext einer Anwendung laufen) müssen nicht nur ihre Laufzeitumgebung (Docker, Kubernetes usw.) bestimmen, sondern benötigen auch ausreichende Zugriffsrechte auf diese Identifikatoren (z. B. Zugriff auf /proc/self/cgroup oder die Kubernetes-APIs). Letzteres stellt offensichtlich ein potenzielles Sicherheitsproblem dar. Daher sollten wir idealerweise externe Instanzen nutzen, um solche Metadaten entweder (als Umgebungsvariablen) zu übergeben oder sie nach der Erstellung der Trace-Daten hinzuzufügen. Um container.id unabhängig von der verwendeten OpenTelemetry-APM-Bibliothek zuverlässig an Trace-Daten anzuhängen, stellen wir einen OpenTelemetry Collector bereit, der mit dem k8sattribute-Prozessor konfiguriert wird, der im DaemonSet des Knoten ausgeführt wird.

Nachdem die APM-Daten mit entsprechenden Kubernetes-Metadaten getaggt worden sind, werden sie vom OpenTelemetry Collector an einen Elastic Agent weitergeleitet, der ebenfalls im DaemonSet des Knotens läuft. Der Elastic Agent wurde über Fleet mit der APM-Integration konfiguriert. Durch die Verteilung der APM-Integration in das DaemonSet jedes Knotens wird die APM-Ingest-Last aufgeteilt und die Verfügbarkeit enger an die unterstützten Anwendungen gebunden. Außerdem bleibt der GRPC/HTTP2-Datenverkehr auf das DaemonSet selbst beschränkt, wodurch ein komplexer GRPC/HTTP2-Lastausgleich vermieden wird. Und schließlich wird die Sicherheit vereinfacht: OTLP kann auf dem Knoten ungeschützt bleiben, wenn zwischen dem Knoten und dem Elasticsearch-Cluster von Fleet verwaltete Elastic Agent-TLS-Sicherheit eingesetzt wird. Durch die Elastic-APM-Integration werden die Trace-, Metrik- und Event-Daten aus OpenTelemetry in das Elasticsearch Common Schema (ECS) umgewandelt. Die resultierenden Dokumente werden dann an Elasticsearch gesendet, um ingestiert und indexiert zu werden.

Container-Logs und Kubernetes-Infrastrukturmetriken

Der OpenTelemetry-Standard unterstützt zwar Logging, aber die Implementierungen befinden sich nur in der Entwurfsphase. Daher bieten viele der verfügbaren Agents noch nicht die Möglichkeit, Logging-Frameworks einzubinden. In der Praxis ist das Ingestieren von Container-Logdateien die einzige Möglichkeit zur Erfassung von Anwendungs-Logdaten. Mit dem OpenTelemetry Collector filelogreceiver ist dies zwar möglich, aber das Tool befindet sich derzeit noch in der Alpha-Phase und wird noch nicht für Anwendungsfälle in der Produktion empfohlen. Das Gleiche gilt für den k8sclusterreceiver, mit dem Kubernetes-Infrastrukturmetriken erfasst werden sollen.

Im Vergleich dazu ist die Elastic-Integration in Kubernetes stabil, bewährt und bietet eine lückenlose Erfassung von Anwendungslogs und Kubernetes-Infrastrukturmetriken. Darüber hinaus kann unsere Kubernetes-Integration auf Fleet-Ebene über Kibana remote verwaltet werden, was die Konfiguration erheblich vereinfacht. Im Gegensatz zu Anwendungs-Traces und -Metriken läuft die Kubernetes-Integration von Elastic außerhalb Ihres Anwendungscodes, sodass Sie keine Bedenken wegen einer Anbieterbindung haben müssen.

Darüber hinaus hat die Verfügbarkeit eines Elastic Agent im DaemonSet eines jeden Knotens Vorteile, die weit über die Kubernetes-Integration hinausgehen. Wie Sie später in diesem Artikel sehen werden, nutzen wir dieselbe Elastic Agent-Instanz, um Elastic Defend zur Überwachung und Absicherung unserer Kubernetes-Knoten bereitzustellen.

Sicherheitsereignisse und Hostdaten

Moderne Observability- und Security-Workflows für Kubernetes müssen Hand in Hand gehen, damit Analysten die Ursache eines bestimmten Problems ermitteln können. Die Security-Lösungen von Elastic bieten umfassend integrierte Kubernetes-fähige SIEM-, SOAR- und XDR-Lösungen mit umfangreichen Funktionen, einschließlich Endpoint-Schutz.

Vor allem die Defend-Integration von Elastic bietet von Haus aus eine deutlich verbesserte Kubernetes-Observability. Unsere Integration „Kubernetes Security Posture Management“ kann Ihre Teams für Entwicklung, DevOps und DevSecOps auf potenzielle Konfigurationsprobleme bei Anwendungen aufmerksam machen, bevor sie von Ihrem Sicherheitsteam erkannt werden. Dank unseres Kubernetes-Security-Dashboards können Analysten genau verstehen, welche Prozesse auf Ihren Kubernetes-Knoten wann mit welchen Laufzeitparametern und unter welchem Konto ausgeführt wurden! Diese einzigartige Laufzeittransparenz ermöglicht es, unvorhergesehene Sicherheitsbedrohungen in Containerschichten zu erkennen, die als Abhängigkeiten in Ihren containerisierten Anwendungen verwendet werden.

Wie die APM-Integration von Elastic werden auch diese Sicherheitsintegrationen über Fleet hinzugefügt, konfiguriert und entfernt und innerhalb des Elastic Agent im DaemonSet auf jedem Knoten Ihres Kubernetes-Clusters ausgeführt.

An die Arbeit!

Voraussetzungen

Sie benötigen einen Kubernetes-Cluster, in dem Sie Ihre Anwendungen, den Elastic Agent und den OpenTelemetry Collector bereitstellen. Ich verwende gerne kOps zum einfachen Erstellen, Verwalten und Löschen von Testclustern in den Hyperscalern. Eine einzelne AWS EC2 t3.xlarge reicht aus, um die OpenTelemetry-Demo und unseren Elastic Agent bereitzustellen. Die Beispiele hier sollten mit jedem selbst verwalteten oder verwalteten (z. B. EKS, GKE) Kubernetes-Cluster in einem der gängigen Hyperscaler oder lokal (z. B. OpenShift) funktionieren. Theoretisch sollten sie auch mit Desktop-Kubernetes-Clustern (wie MicroK8s oder der in Docker integrierten Kubernetes-Engine) funktionieren, vorausgesetzt, Sie statten diese Umgebungen mit ausreichend RAM und CPU aus (z. B. 4 vCPUs und 16 GB RAM). Außerdem benötigen Sie grundlegende Kenntnisse in der Administration von Kubernetes (z. B. Bereitstellen der YAML, Überprüfen des Pod-Status und Anzeigen von Pod-Protokolldateien). Bevor Sie beginnen, sollten Sie sicherstellen, dass Ihr Kubernetes-Kontext auf den richtigen Cluster verweist.

Sie benötigen natürlich auch Anwendungen oder Dienste, die Sie mit OpenTelemetry instrumentieren können. Zum Einstieg können Sie unseren Fork der OpenTelemetry-Demo verwenden. Anschließend können Sie unsere Best Practices für die Instrumentierung Ihrer eigenen Anwendungen und Dienste befolgen.

Zu guter Letzt benötigen Sie Zugang zu einer modernen Elasticsearch-Installation (8.5 oder höher), mit der Sie experimentieren können (Sie können diese kostenlos in unserer Cloud erstellen!), die von Ihrem Kubernetes-Anwendungscluster aus erreichbar ist.

Tools

Bei diesem Tutorial wird davon ausgegangen, dass Sie zur Konfiguration Ihres Kubernetes-Clusters einen Linux- oder MacOS-basierten Host verwenden. Sie müssen sicherstellen, dass die folgenden Tools installiert sind:

• Helm
• curl
• patch

Erstellung Ihres Elasticsearch-Clusters

Wenn Sie bereits eine moderne Elasticsearch-Bereitstellung haben, mit der Sie experimentieren können, ist das optimal. Wenn nicht, richten Sie eine solche ein, indem Sie auf cloud.elastic.co einen kostenlosen Test-Cluster erstellen!

1. Navigieren Sie zu cloud.elastic.co, um sich für eine kostenlose Testversion zu registrieren (es wird keine Kreditkarte benötigt).
2. Nennen Sie Ihren Elasticsearch-Cluster z. B. „o11y“ und behalten Sie ansonsten die Standardeinstellungen bei.
3. Klicken Sie auf [ Create Deployment ] (Bereitstellung erstellen).
4. Warten Sie, bis Elasticsearch Cloud Folgendes meldet: „Your deployment is ready!“ (Ihre Bereitstellung ist fertig!).
5. Klicken Sie auf [ Continue ] (Weiter), um sich bei Kibana anzumelden.

Bereitstellen von Elastic Agent im DaemonSet

Wir werden Elastic Agent (mit Integrationen) verwenden, der im DaemonSet auf jedem Knoten Ihres Kubernetes-Clusters installiert ist, um Daten in Elasticsearch zu ingestieren.

1. Laden Sie die folgende YAML (hier zu finden) auf Ihren lokalen Rechner herunter. Mit dieser YAML werden wir Elastic Agent (mit Elastic Defend) im DaemonSet Ihrer Kubernetes-Knoten bereitstellen.

curl -L -O https://raw.githubusercontent.com/elastic/endpoint/main/releases/8.5.0/kubernetes/deploy/elastic-defend.yaml 

2. Laden Sie den folgenden Patch auf Ihren lokalen Rechner herunter. Mit diesem Patch werden die Standard-RAM- und CPU-Zuweisungen des Elastic Agent-Containers erhöht, um alle installierten Integrationen problemlos aufnehmen zu können. In der Produktion entscheiden Sie sich möglicherweise dafür, nur einen Teil der folgenden Integrationen bereitzustellen, sodass diese Änderung überflüssig ist.

curl -L -O https://raw.githubusercontent.com/ty-elastic/elastic-otel-k8s/main/agent/8.5.0/elastic-defend.yaml.patch 

3. Wenden Sie den Patch an.

patch elastic-defend.yaml elastic-defend.yaml.patch 

4. Stellen Sie sicher, dass Sie in Ihrem Elasticsearch-Cluster bei Kibana angemeldet sind.

5. Navigieren Sie zu [ Management / Fleet ] (Verwaltung/Fleet).

6. Klicken Sie auf [ Add agent ] (Agent hinzufügen).

7. Nennen Sie die neue Richtlinie z. B. „k8s-apps“. 

• Die Richtlinie „k8s-apps“ wird hier verwendet, um Integrationen auf dem DaemonSet der Knoten in Ihrem Kubernetes-Cluster bereitzustellen.

8. Legen Sie unter [ Advanced options ] (Erweiterte Optionen) die Option [ Unenrollment timeout ] (Deaktivierung wg. Zeitüberschreitung) auf den Wert „3600“ Sekunden fest. 

• Kubernetes kann Knoten dynamisch erstellen und löschen. Mit dieser Einstellung wird sichergestellt, dass Elastic Agents, die auf gelöschten Knoten bereitgestellt wurden, automatisch entfernt werden.

9. Wählen Sie [ Create policy ] (Richtlinie erstellen) aus.

10. Wählen Sie unter [ Install Elastic Agent on your host ] (Elastic Agent auf Ihrem Host installieren) die Option „Kubernetes“ aus.

11. Suchen Sie den Wert der Variable „FLEET_URL“ und kopieren Sie diesen zum Wert „FLEET_URL“ in der Datei „elastic-defend.yaml“, die Sie vorher heruntergeladen und gepatcht haben.

12. Suchen Sie den Wert der Variable „FLEET_ENROLLMENT_TOKEN“ und kopieren Sie diesen zum Wert „FLEET_ENROLLMENT_TOKEN“ in der Datei „elastic-defend.yaml“, die Sie vorher heruntergeladen und gepatcht haben.

13. Wenden Sie die Datei „elastic-defend.yaml“ mit folgendem Befehl auf Ihren Cluster an:

kubectl apply -f elastic-defend.yaml 

14. Warten Sie, bis unter [ Confirm agent enrollment ] (Agent-Aktivierung bestätigen) Folgendes angezeigt wird: „1 agent has been enrolled“ (1 Agent wurde aktiviert).

15. Warten Sie, bis unter [ Incoming data confirmed ] (Eingehende Daten bestätigt) Folgendes angezeigt wird: „Incoming data received from 1 of 1 recently enrolled agent“ (Eingehende Daten von 1 von 1 kürzlich aktiviertem Agent empfangen).

16. Klicken Sie auf „Close“ (Schließen).

Sie haben vielleicht bemerkt, dass Elastic vorkonfiguriertes YAML für die Bereitstellung des Elastic Agent bereitstellt, wenn Sie die Hostoption „Kubernetes auswählen“. Dieses Bereitstellungs-YAML enthält noch nicht das Elastic Defend-Image.

Einrichtung von Elastic Agent-Integrationen

Jetzt kommt der einfache Teil. Mit einem von Fleet verwalteten Elastic Agent, der in Ihrem DaemonSet bereitgestellt wurde, ist es ganz einfach, über die Kibana-Integrationsschnittstelle Integrationen per Remote-Zugriff hinzuzufügen/zu konfigurieren/löschen.

APM

Die Elastic-APM-Integration wird verwendet, um APM-Daten aus OpenTelemetry in Elastic zu importieren.

1. Navigieren Sie in Kibana zu [ Management / Integrations ] (Verwaltung/Integrationen).
2. Suchen Sie nach „APM“.
3. Klicken Sie auf [ APM ].
4. Klicken Sie auf [ Manage APM integration in Fleet ] (APM-Integration in Fleet verwalten).
5. Klicken Sie auf [ Add Elastic APM ] (Elastic-APM hinzufügen).
6. Legen Sie [ General / Server configuration / Host ] (Allgemein/Serverkonfiguration/Host) auf „0.0.0.0:8200“ fest (dadurch wird der APM-Integrations-Ingest anderen Pods auf dem Knoten zugänglich gemacht (einschließlich dem OpenTelemetry Collector, der ebenfalls im DaemonSet ausgeführt wird)).
7. Deaktivieren Sie [ Agent authorization / Anonymous Agent access ] (Agent-Autorisierung/Anonymer Agent-Zugriff) (dank dieser Vereinfachung kann der OpenTelemetry Collector OTEL-Daten ohne Autorisierungs-Token an die Elastic-APM-Integration senden (die APM-Integration ist außerhalb des Knotens nicht sichtbar)).
8. Optional können Sie [ Tail-based sampling ] (Tail-basiertes Sampling) aktivieren (dadurch wird ein intelligentes Sub-Sampling von Trace-Daten ermöglicht, um Anomalien und die Gesamtleistung zu erfassen und gleichzeitig den Speicherbedarf zu reduzieren).
9. Legen Sie [ Where to add this integration ] (Wo soll diese Integration hinzugefügt werden?) auf „Existing hosts“ (Vorhandene Hosts) und [ Agent policy ] (Agent-Richtlinie) auf „k8s-apps“ fest.
10. Klicken Sie auf [ Save and continue ] (Speichern und fortfahren).
11. Klicken Sie auf [ Save and deploy changes ] (Speichern und Änderungen anwenden).

Kubernetes

Bereitstellen von Kube-Status-Metriken

Für die Kubernetes-Integration muss kube-state-metrics in Ihrem Kubernetes-Cluster verfügbar sein, damit die vorkonfigurierten Kubernetes-Dashboards aktiviert werden.

1. Fügen Sie das Helm-Repo „kube-state-metrics“ hinzu.

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts 

helm repo update 

2. Installieren Sie Kube-Status-Metriken in Ihrem Kubernetes-Cluster in denselben Namespace wie Elastic Agent (der bei Verwendung der mitgelieferten Bereitstellungs-YAML für Elastic Agent standardmäßig „kube-system“ heißt).

helm install --set namespaceOverride=kube-system kube-state-metrics prometheus-community/kube-state-metrics 

Installation der Kubernetes-Integration

Über die Kubernetes-Integration von Elastic werden Kubernetes-Metriken und -Logs in Elasticsearch importiert.

1. Navigieren Sie in Kibana zu [ Management / Integrations ] (Verwaltung/Integrationen).
2. Suchen Sie nach „Kubernetes“.
3. Wählen Sie [ Kubernetes ] aus.
4. Klicken Sie auf [ Add Kubernetes ] (Kubernetes hinzufügen).
5. Aktivieren Sie die Option [ Collect Kubernetes metrics from kube-state-metrics ] (Kubernetes-Metriken aus Kube-Status-Metriken erfassen), sofern diese noch nicht aktiviert ist.
6. Legen Sie [ Where to add this integration ] (Wo soll diese Integration hinzugefügt werden?) auf „Existing hosts“ (Vorhandene Hosts) und [ Agent policy ] (Agent-Richtlinie) auf „k8s-apps“ fest.
7. Klicken Sie auf [ Save and continue ] (Speichern und fortfahren).
8. Klicken Sie auf [ Save and deploy changes ] (Speichern und Änderungen anwenden).

Elastic Defend

Über die Elastic Defend-Integration werden Ihre Kubernetes-Knoten geschützt und zusätzliche sicherheitsbezogene Observability-Daten erfasst.

1. Navigieren Sie in Kibana zu [ Management / Integrations ] (Verwaltung/Integrationen).
2. Suchen Sie nach „Elastic Defend“.
3. Wählen Sie [ Elastic Defend ] aus.
4. Klicken Sie auf [ Add Elastic Defend ] (Elastic Defend hinzufügen).
5. Legen Sie [ Integration name ] (Integrationsname) auf „defend-1“ fest.
6. Navigieren Sie zu [ Select configuration settings ] (Konfigurationseinstellungen auswählen), legen Sie [ Select the type of environment you want to protect ] (Art von Umgebung auswählen, die geschützt werden soll) auf „Cloud Workloads (Linux servers or Kubernetes environments)“ (Cloud-Workloads (Linux-Server oder Kubernetes-Umgebungen)) und [ To reduce data ingestion volume, select Interactive only ] (Um das Daten-Ingest-Volumen zu reduzieren, ‚Nur interaktiv‘ auswählen) auf „All events“ (Alle Events) fest.
7. Legen Sie [ Where to add this integration ] (Wo soll diese Integration hinzugefügt werden?) auf „Existing hosts“ (Vorhandene Hosts) und [ Agent policy ] (Agent-Richtlinie) auf „k8s-apps“ fest.
8. Wenn Ihr Kubernetes-Cluster nicht auf GKE oder EKS ausgeführt wird, legen Sie unter [ Advanced options ] (Erweiterte Optionen) [ Namespace ] z. B. auf „k8sapps“ fest, wobei „k8sapps“ für Ihren Anwendungs-Kubernetes-Cluster steht (dies ist erforderlich, um die Elastic Defend-Telemetrie mit dem Namen des entsprechenden Kubernetes-Clusters zu versehen).
9. Klicken Sie auf [ Save and continue ] (Speichern und fortfahren).
10. Wählen Sie [ Settings ] (Einstellungen) aus.
11. Navigieren Sie zu [ Elastic Defend version ] (Elastic Defend-Version) und aktivieren Sie „Keep integration policies up to date automatically“ (Integrationsrichtlinien automatisch aktuell halten).
12. Wählen Sie [ Integration policies ] (Integrationsrichtlinien) aus und klicken Sie auf [ defend-1 ].
13. Navigieren Sie zu [ Type: Operating system / Event Collection: Linux ] (Typ: Betriebssystem/Event-Erfassung: Linux) und aktivieren Sie [ Capture terminal output ] (Terminalausgabe erfassen).
14. Klicken Sie auf [ Save and continue ] (Speichern und fortfahren).
15. Klicken Sie auf [ Save and deploy changes ] (Speichern und Änderungen anwenden).

Bestimmte Elasticsearch-Kubernetes-Dashboards benötigen den Namen und die ID Ihres Kubernetes-Clusters. Wenn Ihr Cluster auf GKE oder EKS läuft, ruft Elastic Agent diese Metadaten automatisch ab. Wenn Sie einen selbst verwalteten Kubernetes-Cluster betreiben, können Sie eine Ingest-Pipeline erstellen, um Sicherheitsereignisse automatisch mit den Feldern orchestrator.cluster.name und orchestrator.cluster.id zu versehen, die im von Ihnen zuvor definierten Richtlinien-Namespace festgelegt wurden.

1. Navigieren Sie zu [ Management / Dev Tools ] (Verwaltung/Entw.-Tools).
2. Führen Sie den folgenden Befehl aus:

Kubernetes Security Posture Management

Mit der Elastic-Integration „Kubernetes Security Posture Management“ können Sie Ihren Kubernetes-Cluster und Ihre Anwendungen anhand von Best Practices für eine sichere Kubernetes-Konfiguration validieren, wie vom Center for Internet Security (CIS) definiert. So können Ihre Entwicklungs- und Bereitstellungsteams Fehlkonfigurationen erkennen, bevor sie zu einer Sicherheitsverletzung führen.

1. Navigieren Sie in Kibana zu [ Management / Integrations ] (Verwaltung/Integrationen).
2. Suchen Sie nach „Kubernetes Security Posture Management“.
3. Wählen Sie [ Kubernetes Security Posture Management ] aus.
4. Klicken Sie auf [ Add Kubernetes Security Posture Management ] (Kubernetes Security Posture Management hinzufügen).
5. Legen Sie [ Kubernetes Deployment ] (Kubernetes-Bereitstellung) auf „Unmanaged Kubernetes“ (Nicht verwaltetes Kubernetes) (bei selbstverwaltetem Kubernetes) oder „EKS (Elastic Kubernetes Service)“, wenn Ihr Kubernetes-Anwendungscluster auf AWS EKS ausgeführt wird.
6. Legen Sie [ Where to add this integration ] (Wo soll diese Integration hinzugefügt werden?) auf „Existing hosts“ (Vorhandene Hosts) und [ Agent policy ] (Agent-Richtlinie) auf „k8s-apps“ fest.
7. Klicken Sie auf [ Save and continue ] (Speichern und fortfahren).
8. Klicken Sie auf [ Save and deploy changes ] (Speichern und Änderungen anwenden).

Network Packet Capture

Mit der Elastic-Integration „Network Packet Capture“ gewinnen Sie Einblicke in den Netzwerkverkehr zu und aus Ihren Kubernetes-Knoten.

1. Navigieren Sie in Kibana zu [ Management / Integrations ] (Verwaltung/Integrationen).
2. Suchen Sie nach „Network Packet Capture“.
3. Wählen Sie [ Network Packet Capture ] aus.
4. Klicken Sie auf [ Add Network Packet Capture ] Network Packet Capture hinzufügen).
5. Legen Sie [ Where to add this integration ] (Wo soll diese Integration hinzugefügt werden?) auf „Existing hosts“ (Vorhandene Hosts) und [ Agent policy ] (Agent-Richtlinie) auf „k8s-apps“ fest.
6. Klicken Sie auf [ Save and continue ] (Speichern und fortfahren).
7. Klicken Sie auf [ Save and deploy changes ] (Speichern und Änderungen anwenden).

Instrumentierung mit OpenTelemetry

Ich habe die OpenTelemetry-Demo und OpenTelemetry Helm Charts für Elastic Observability optimiert (Unter Instrumentieren Ihrer eigenen Anwendungen erfahren Sie, welche Änderungen aus welchen Gründen vorgenommen wurden). Wenn Sie nur die Anwendungen in der OpenTelemetry-Demo verwenden möchten, um zu verstehen, welchen Vorteil Elastic für die Observability und Security von Kubernetes bringt, beginnen Sie mit Einrichten der OpenTelemetry-Demo. Wenn Sie Ihre eigenen Anwendungen und Dienste beobachten möchten, beginnen Sie mit der Anleitung in Instrumentieren Ihrer eigenen Anwendungen.

Einrichten der OpenTelemetry-Demo

In diesem Abschnitt wird davon ausgegangen, dass Sie die bereits in der OpenTelemetry-Demo instrumentierten Anwendungen bereitstellen und beobachten möchten. Wir werden ein modifiziertes OpenTelemetry Helm Chart verwenden, mit dem sowohl die Demoanwendungen als auch eine OpenTelemetry-Collector-Instanz bereitgestellt werden.

1. Fügen Sie unser Helm-Repo hinzu.

helm repo add elastic-open-telemetry https://ty-elastic.github.io/opentelemetry-helm-charts 

helm repo update 

2. Installieren Sie die Demoanwendungen und den Collector in Ihrem Kubernetes-Cluster.

helm install elastic-otel elastic-open-telemetry/opentelemetry-demo 

3. Verifizieren Sie die Installation, indem Sie die ausgeführten Pods auflisten.

kubectl get pods 

Alle OpenTelemetry-Demo-Pods sowie eine Instanz des OpenTelemetry Collector sollten angezeigt werden:

4. Springen Sie zu Validierung und Beobachtung, um zu bestätigen, dass Ihre Anwendungs-Traces, -Metriken und Events in Elasticsearch eingehen.

Instrumentieren Ihrer eigenen Anwendungen mit OpenTelemetry

In diesem Abschnitt wird davon ausgegangen, dass Sie Ihre eigenen Anwendungen mit OpenTelemetry instrumentieren. Damit Ihre Anwendungen mit dem in diesem Artikel beschriebenen Bereitstellungsmodell verwendet werden können, müssen sie folgende Voraussetzungen erfüllen:

1. Sie müssen mit einer stabilen Version von OpenTelemetry APM-Agent instrumentiert sein.
2. Sie müssen mit spezifischen OpenTelemetry-Umgebungsvariablen instanziiert werden.
3. Bei einer manuellen Instrumentierung müssen bestimmte Span-Eigenschaften richtig festgelegt sein.
4. Sie müssen bestimmte Metadaten optional zu Logzeilen hinzufügen.
5. Sie müssen Logdaten an stdout und stderr ausgeben, um von der Elastic-Kubernetes-Integration erfasst zu werden.

Container-Umgebungsvariablen

Um die integrierten APM-Dashboards von Elastic nutzen zu können, müssen wir sicherstellen, dass Anwendungs-Traces, -Metriken und -Events geeignete kontextbezogene Metadaten enthalten. Wir können diese Metadaten aus der Kubernetes Downward API abrufen und über die Umgebungsvariable OTEL_RESOURCE_ATTRIBUTES an die Anwendung übergeben.

Wir müssen auch den OTEL_EXPORTER_OTLP_ENDPOINT so festlegen, dass Anwendungen ihre OpenTelemetry-Daten über OTLP an die OpenTelemetry Collector-Instanz senden, die wir später im DaemonSet des Knotens bereitstellen.

Das folgende Konfigurations-Snippet für Kubernetes-Container richtet die Umgebungsvariablen ein, die Sie auf Ihre Anwendungen in deren Bereitstellungs-YAML anwenden müssen.

Sie fragen sich vielleicht, warum wir k8s.container.restart_count=0 als Ressourcenattribut festlegen. Der aktuelle OpenTelemetry Collector k8sattrribute-Prozessor benötigt diese Informationen, um einen Container (über k8s.container.name) einer laufenden Instanz eines Containers zuzuordnen und so eine container.id zu erhalten. Die Festlegung k8s.container.restart_count=0 ist eine Vereinfachung: Es wäre schwierig nachzuverfolgen, wie oft ein bestimmter Container von Kubernetes in einem Pod neu gestartet wurde, und dies in eine Umgebungsvariable zu übertragen. Im Normalfall wird ein Container nur einmal während einer bestimmten Lebensdauer des Pods gestartet. Wenn ein Container vom Pod neu gestartet wird, greift diese Vereinfachung jedoch nicht.

Span-Eigenschaften

Elastic APM benötigt bestimmte Span-Eigenschaften, die explizit festgelegt werden müssen, um Span-Daten richtig zu charakterisieren, zu klassifizieren und zu visualisieren. Die meisten der APM-Auto-Instrumentierungsbibliotheken für OpenTelemetry legen diese Felder für Sie fest. Wenn Sie Ihre Anwendung jedoch manuell instrumentieren, müssen Sie die folgenden Eigenschaften explizit festlegen:SpanKind: Damit Elastic APM die Spans richtig klassifizieren kann, muss es die SpanKind kennen (z. B. INTERNAL, SERVER, CLIENT). Die meisten der APM-Auto-Instrumentierungsbibliotheken für OpenTelemetry legen dieses Feld für Sie fest. Wenn Sie Ihre Anwendung jedoch manuell instrumentieren, müssen Sie bei Spans, die RPC- oder REST-Aufrufe akzeptieren, SpanKind auf SERVER setzen, bei Spans, die RPC- oder REST- oder Datenbankaufrufe initiieren, auf CLIENT und bei Funktionsaufrufen innerhalb eines Dienstes auf INTERNAL (Standard). In Java würden Sie z. B. bei einem Span, der einen gRPC-Aufruf erhält, in etwa folgendermaßen SpanKind auf SERVER setzen:

RpcSystem/DbSystem: Damit Elastic APM Spans richtig klassifiziert, muss das Tool wissen, ob der Span eine RPC-Transaktion oder eine Datenbanktransaktion darstellt und welche Art von RPC- oder DB-System verwendet wird. Die meisten der APM-Auto-Instrumentierungsbibliotheken für OpenTelemetry legen dieses Feld für Sie fest. Wenn Sie Ihre Anwendung manuell instrumentieren, sollten Sie das Span-Attribut RpcSystem oder DbSystem festlegen. In Rust würden Sie z. B. bei einem Span, der einen gRPC-Aufruf erhält, in etwa folgendermaßen RpcSystem auf „grpc“ setzen:

NetPeerHost und NetPeerPort: Damit Elastic APM Abhängigkeiten zwischen Diensten korrekt abbilden kann, wenn SpanKind auf CLIENT gesetzt ist (d. h. ein ausgehender gRPC- oder Datenbankaufruf), müssen die Span-Attribute NetPeerName und NetPeerPort so festgelegt werden, dass sie den vorgesehenen Empfänger des Aufrufs angeben. Einige der APM-Auto-Instrumentierungsbibliotheken für OpenTelemetry legen dieses Feld für Sie fest. Wenn Sie Ihre Anwendung manuell instrumentieren, müssen Sie diese Attribute explizit festlegen. In JavaScript würden Sie z. B. NetPeerName und NetPeerPort etwa folgendermaßen für einen Span festlegen, die einen gRPC-Aufruf sendet:

Logattribute

Elastic APM kann bestimmte Logzeilen mit bestimmten Traces korrelieren. Um diese Funktion zu aktivieren, müssen die von Ihrer Anwendung ausgehenden Logzeilen ggf. mit den Schlüssel/Wert-Paaren span.id und trace.id gekennzeichnet werden. Einige der Elastic APM-Agenten (z. B. der Java-Agent) ändern automatisch Ihre Logging-Vorlage und fügen diese kontextbezogenen Metadaten hinzu.

Bereitstellen von OpenTelemetry Collector im DaemonSet

Wenn Sie mit der OpenTelemetry-Demo und unseren modifizierten OpenTelemetry Helm Charts arbeiten, wurde für Sie auf jedem Knoten im DaemonSet bereits ein optimierter OpenTelemetry Collector installiert.

Wenn Sie Ihre eigenen Anwendungen instrumentieren, können Sie die folgende YAML als Grundlage für die Konfiguration und Bereitstellung des OpenTelemetry Collector im DaemonSet auf den Knoten in Ihrem Cluster verwenden. Die Beispielkonfiguration (die mithilfe einer ConfigMap bereitgestellt wird) ingestiert OTLP-Trace-, Metrik- und Event-Daten von Anwendungen auf TCP-Port 4317 (grpc) und 4318 (http). Da der Collector im DaemonSet ausgeführt wird, ist dieser Port von anderen Pods, die auf demselben Knoten laufen, über die IP des Knotens erreichbar. Eingehende OTLP-Daten laufen durch den k8sattributes-Prozessor, um container.id anzuhängen. Wir verwerfen alle Logdaten, die möglicherweise eingehen (wir erhalten diese Daten ja über die Elastic-Kubernetes-Integration), und leiten Tracing, Events und Metriken an die Elastic-APM-Integration weiter, die ebenfalls im DaemonSet ausgeführt wird. Die Elastic-APM-Integration lauscht auf Port 8200, der auch über die IP des Knotens erreichbar ist (wird hier als Umgebungsvariable übergeben, die von der Kubernetes Downward API bezogen wird).

1. Laden Sie diese Beispiel-YAML für die Bereitstellung von OpenTelemetry Collector herunter.

curl -L -O https://raw.githubusercontent.com/ty-elastic/elastic-otel-k8s/main/collector/otel-collector.yaml 

2. Bearbeiten Sie diese nach Bedarf für Ihre Bereitstellung.

3. Wenden Sie diese auf Ihren Kubernetes-Cluster an.

kubectl apply -f otel-collector.yaml 

Validierung und Beobachtung

In diesem Abschnitt werden wir prüfen, ob die Observability- und Security-Daten, die wir oben konfiguriert haben, wie erwartet in unserem Elasticsearch-Cluster ankommen. Mit dieser Übung erhalten Sie auch einen kurzen Überblick über einige der integrierten Observability- und Security-Dashboards, die Ihnen in Elasticsearch zur Verfügung stehen. Sie können diese Übung gerne als Anlass dazu nehmen, sich über unser umfangreiches Angebot an Visualisierungs- und Analytics-Funktionen zu informieren.

APM Service Map

Die APM Service Map liefert eine Visualisierung Ihrer Dienste und deren Beziehung zueinander. Bestimmte Arten von Dienstfehlern und Warnungen werden auf dieser Map entsprechend hervorgehoben. Von dieser Map aus können Sie zu einer detaillierten Ansicht der einzelnen Dienste wechseln, die mit OpenTelemetry (oder dem eigenen APM-Agent von Elastic) instrumentiert wurden.

1. Wählen Sie in der Navigationsseitenleiste von Kibana unter [ Observability ] die Option [ APM ] aus.
2. Wählen Sie unter [ APM ] die Option [ Service Map ] aus.

APM Service

Die APM Service-Ansicht bietet einen Überblick über einen bestimmten Dienst. Von diesem Dashboard aus können Sie ganz einfach einen Drilldown zu Traces, Logs und zugehörigen Infrastrukturmetriken durchführen. In der Vergangenheit mussten für eine ungefähre Korrelation zwischen diesen Datenquellen die Zeitstempel und Dienstkennungen der einzelnen Observability-Plattformen manuell übersetzt werden. Mit Elastic und OpenTelemetry erfolgt diese Korrelation automatisch, sodass sich Analysten, Nutzer und Entwickler auf die Ursachenanalyse konzentrieren können und sich nicht um die Besonderheiten der Observability-Tools kümmern müssen.

1. Wählen Sie in der Navigationsseitenleiste von Kibana unter [ Observability ] die Option [ APM ] aus.
2. Wählen Sie unter [ APM ] die Option [ Service Map ] aus.
3. Klicken Sie mit der rechten Maustaste auf einen Dienst in der Map.
4. Wählen Sie [ Service Details ] (Details zum Dienst) aus.

Ausgehend von dieser Ansicht können Sie ganz einfach die Transaktionen und Spans untersuchen, die Ihre Nutzer mit Ihren Diensten und die Dienste untereinander verbinden.

1. Wählen Sie in der Kopfzeile [ Transactions ] (Transaktionen) aus.
2. Wählen Sie im Unterabschnitt [ Transactions ] (Transaktionen) eine Transaktion aus, die Sie interessiert.

Kubernetes-Cluster-Metriken

Die Kubernetes-Dashboards von Elastic bieten sowohl einen Überblick als auch einen detaillierten Einblick in den Betrieb Ihres Kubernetes-Clusters. Hier können Sie Metriken für Cluster, Nodes, Pods, DaemonSets, Dienste und mehr überwachen.

1. Wählen Sie in der Navigationsseitenleiste von Kibana unter [ Analytics ] die Option [ Dashboard ] aus.
2. Wählen Sie im Menü [ Tags ] die Option [ Kubernetes ] aus.
3. Wählen Sie das Dashboard [ Cluster Overview ] (Cluster-Überblick) aus.

Monitoring von Kubernetes-Prozessen

Die Elastic Defend-Integration bietet sicherheitsorientierte Observability für Ihre sämtlichen Kubernetes-Ressourcen. Das Kubernetes-Security-Dashboard ermöglicht es Analysten, genau zu verstehen, welche Prozesse auf Ihren Kubernetes-Knoten wann mit welchen Laufzeitparametern und unter welchem Konto ausgeführt wurden.

1. Wählen Sie in der Navigationsseitenleiste von Kibana unter [ Security ] die Option [ Dashboards ] aus.
2. Wählen Sie [ Kubernetes ] aus.

Kubernetes Security Posture Management

Das Kubernetes Security Posture Management (KSPM)-Dashboard bietet automatisierte Analysen und Empfehlungen zur Behebung von Problemen auf Basis einer Reihe von Kubernetes-Best-Practices für die sichere Bereitstellung. Entwicklern und DevOps-Mitarbeitern kann dieses Dashboard wertvolle Hinweise auf potenzielle Konfigurationsprobleme liefern, bevor diese in der Produktion zu Störungen führen.

1. Wählen Sie in der Navigationsseitenleiste von Kibana unter [ Security ] die Option [ Dashboards ] aus.
2. Wählen Sie [ Cloud Posture ] (Cloud-Status) aus.

Analyse des Netzwerkverkehrs

Mit der Network Packet Capture-Integration können Sie den IP-Datenverkehr in und aus Ihren Kubernetes-Knoten genau unter die Lupe nehmen und nach problematischen Diensten oder einer Sicherheitsverletzung suchen.

1. Wählen Sie in der Navigationsseitenleiste von Kibana unter [ Security ] die Option [ Explore ] (Untersuchen) aus.
2. Wählen Sie [ Network ] (Netzwerk) aus.

Elastic: Observability und Security speziell für Kubernetes!

Kubernetes stellt für viele Unternehmen ein neues Modell für die Anwendungsbereitstellung dar. Ein neues Bereitstellungsmodell erfordert einen offenen, modernen und ganzheitlichen Ansatz für Observability und Sicherheit. Wie hier gezeigt wurde, ist die Elastic Platform in der Branche hervorragend positioniert, um umfassend integrierte Observability und Security für Kubernetes zu bieten, und das mit vollem Funktionsumfang und hoher Zuverlässigkeit.

Sie sind interessiert? Wenden Sie sich zum Einstieg in die Entwicklung mit Elastic an unser Pre-Sales-Team!