Hinweis:

• Dieses Tutorial erfordert Zugriff auf Oracle Cloud. Informationen zum Anmelden für einen kostenlosen Account finden Sie unter Erste Schritte mit Oracle Cloud Infrastructure Free Tier.
• Es verwendet Beispielwerte für Oracle Cloud Infrastructure-Zugangsdaten, -Mandanten und -Compartments. Wenn Sie Ihre Übung abgeschlossen haben, ersetzen Sie diese Werte durch die Werte, die für Ihre Cloud-Umgebung spezifisch sind.

Tetragon installieren und TracingPolicies auf Oracle Container Engine for Kubernetes konfigurieren

Einführung

Da eBPF-basierte Tools für cloud-native Anwendungen immer beliebter werden, wird in diesem Tutorial die Ausführung von Tetragon beschrieben, einem eBPF-basierten Tool zur Sicherheitsüberwachung und -durchsetzung auf Oracle Cloud Infrastructure (OCI).

Was ist eBPF und warum ist es beliebt?

Ein Betriebssystemkernel ist in der Regel der beste Ort, um ein System zu beobachten und zu beeinflussen, da es sehr wenige Barrieren zwischen dem Tool, das eine Funktion ausführt, und den Aktivitäten gibt, die es zu beobachten und zu beeinflussen versucht. Durch die Ausführung im Kernel-Speicherplatz kann ein Programm häufig einen sehr geringen Overhead, aber zu den Kosten für Sicherheit und Wartung haben.

eBPF bietet eine Methode zur Einführung neuer Funktionen, die in einem sandbox- und privilegierten Kontext ausgeführt werden können, ohne den Kernel-Quellcode zu ändern oder ein Kernel-Modul zu laden. Es funktioniert im Wesentlichen, indem ein Paradigma erstellt wird, das einer virtuellen maschinenbasierten Programmiersprache ähnlich ist. Auf ähnliche Weise wie moderne Java-Programme in Bytecode kompiliert werden, den die JVM (Java Virtual Machine) mit einem JIT-Compiler in nativen Code kompiliert, um native Performance zu erzielen, verfügen eBPF-Programme über eine Bytecode-Darstellung. BPF ist tief mit dem Linux-Kernel verbunden, und der In-Kernel-JIT-Compiler kompiliert den eBPF-Bytecode in nativen Code, der im Kernel-Bereich ausgeführt werden kann.

eBPF verwendet ein ereignisbasiertes Modell, um Programme zu laden, und eBPF-Programme werden in Netzwerkereignisse, Systemaufrufe und vieles mehr in "Hook" geschrieben. Wenn ein Ereignis aufgerufen wurde, in das ein eBPF-Programm eingehängt ist, wird das eBPF-Programm nach Überprüfung und JIT-Kompilierung in den Kernel geladen. Der Verifizierungsschritt stellt sicher, dass das Programm sicher ausgeführt werden kann, über die richtigen Berechtigungen verfügt und bis zum Abschluss ausgeführt werden kann, während die JIT-Kompilierung die native Performance gewährleistet. In vielen Fällen werden eBPF-Programme in übergeordneten Sprachen geschrieben und in die Bytecode-Darstellung kompiliert. Diese werden dann nach der JIT-Kompilierung in einen laufenden Kernel geladen, basierend auf den Ereignissen, mit denen die Programme verbunden sind.

Tetragon - eBPF-basierte Sicherheitsüberwachung und -durchsetzung

Tetragon ist ein cloud-natives eBPF-basiertes Tool, das Sicherheitsüberwachung und Durchsetzung ausführt. Es ist ein Bestandteil des Ciliumprojekts. Mit eBPF kann Tetragon Ereignisse filtern und beobachten und Policys in Echtzeit anwenden, ohne Ereignisse an einen Agent zu senden, der außerhalb des Kernels ausgeführt wird. Tetragon kann zahlreiche Sicherheits- und Beobachtbarkeitsanwendungsfälle lösen, indem es nach Ereignissen wie einer Workload filtert, die eine Netzwerkverbindung öffnet, auf eine Datei zugreift oder sogar einen Prozess innerhalb eines Containers startet. Beispiel: Ein Shell-Prozess, der in einem Anwendungscontainer gestartet wird, könnte als Sicherheitsereignis betrachtet werden. Es könnte jemand sein, der versucht, ein Problem zu beheben, oder es könnte eine böswillige Aktivität sein, die eine Sicherheitsprüfung auslösen sollte, um einen Angriff auf das System auszuschließen. Dasselbe gilt für das Öffnen von Netzwerkverbindungen oder das Lesen von Dateien. Tetragon kann diese Aktivitäten verfolgen und filtern und gleichzeitig wenig bis keinen Overhead einführen und in der Regel frühestens dann, wenn diese Ereignisse in Software erkannt werden können.

Tetragon ist ideal für Kubernetes-Workloads geeignet und wird in jedem Knoten im Cluster als daemonset ausgeführt. Tetragon kann dann Metadaten vom Kubernetes-API-Server abrufen und diese Metadaten mit den Ereignissen korrelieren, die im Kernel jedes Knotens beobachtet werden. Tetragon erleichtert das Einrichten von Echtzeitfiltern für diese Aktivitäten und mehr mit TracingPolicies. TracingPolicy ist eine von Tetragon erstellte benutzerdefinierte Ressource, mit der Administratoren und DevSecOps Filter für Kernelereignisse als Kubernetes-Ressourcen erstellen und bereitstellen können. Eine TracingPolicy kann Systemaufrufe, Prozessattribute und Argumente abgleichen und eine Aktion bei Übereinstimmungen auslösen.

Zielsetzung

• Erfahren Sie, wie Sie Tetragon in einem OKE-Cluster in OCI einrichten.
• Erfahren Sie, wie Sie mit TracingPolicies Ereignisse beobachten und verfälschen.

Voraussetzungen

• Sie können sich registrieren oder sich bei Ihrem Oracle Cloud-Account anmelden.

• OKE-Cluster erstellen

  Hinweis: Tetragon kann in Kubernetes-Clustern wie Oracle Container Engine for Kubernetes (OKE) mit dem vom Tetragon-Projekt veröffentlichten Helm-Diagramm bereitgestellt werden. Nach der Installation wird die TracingPolicy CRD erstellt, und Tetragon wird auf den Clusterknoten als daemonset ausgeführt.

Voraussetzungen für Oracle Linux

OKE verwendet Oracle Linux, und Tetragon setzt auf die Unterstützung von BTF (BPF Type Format) im Kernel. Die letzten Oracle Linux-Kernel enthalten diese Out-of-the-box. Daher sollten Benutzer einen Kernel verwenden, der 5.4.17-2136.305.3.el7uek oder höher ist. Tetragon bietet auch keine Unterstützung für die Arm-Architektur (linux/arm64), und zum Zeitpunkt des Schreibens wird nur x86 (linux/amd64) unterstützt. Wenn sich Arm-Knoten in Ihrem OKE-Cluster befinden, bleibt das Daemon-Set im Status Init:CrashLoopBackOff.

Hinweis: Die neuesten Versionen der OKE-Knotenimages basieren auf Kerneln, die BTF-Unterstützung enthalten. Diese Caveat für die BTF-Unterstützung gilt nur für Cluster, bei denen das Knoten-BS nicht innerhalb einer bestimmten Zeit aktualisiert wurde und nicht für neu erstellte Cluster. Wenn Sie sich nicht sicher sind, können Sie am besten prüfen, ob Sie BTF-Unterstützung haben, indem Sie SSH auf dem Knoten ausführen und ls /sys/kernel/BTF ausführen, sollten Sie den Kernel (vmlinux) sowie die hier aufgeführten Module sehen. Im Allgemeinen werden Oracle Linux 8-basierte Knoten für dieses Deployment bevorzugt.

Um die Version des Kernels zu prüfen, auf dem Ihre Knoten ausgeführt werden, führen Sie uname -a auf dem Knoten aus. Wenn Sie eine ältere Version des Kernels ausführen, können Sie die Version in der Knotenpoolkonfiguration aktualisieren. Dies wirkt sich jedoch nur auf neu erstellte Knoten aus, und vorhandene Knoten werden nicht automatisch upgegradet, um die Kontinuität für die Workloads sicherzustellen, die auf ihnen ausgeführt werden können. Sie können den Upgradeprozess des Knotenpools befolgen, um die vorhandenen Knoten auf die neueren Kernel-Versionen zu aktualisieren.

• Sobald Sie sichergestellt haben, dass Sie auf einer aktuellen Version des Kernels auf Ihren Knoten laufen, können Sie mit der Tetragon-Installation mit dem Tetragon-Helm-Diagramm beginnen. Sie können auch die Anweisungen von Tetragon's Github-Seite befolgen.

  helm repo add cilium https://helm.cilium.io
  helm repo update
  helm install tetragon cilium/tetragon -n kube-system
  kubectl rollout status -n kube-system ds/tetragon -w
  
  

• Sobald das Daemon-Set bereit ist und die Tetragon-Pods den Status "Wird ausgeführt" aufweisen, können Sie mit dem Hören von Ereignissen auf Ihren Knoten beginnen. Out-of-the-box kann die Prozessausführung überwachen. Tetragon gibt die übereinstimmenden Ereignisse im JSON-Format aus, und die Logs können mit dem folgenden Befehl beobachtet werden (vorausgesetzt, Sie haben jq installiert).

  kubectl logs -n kube-system -l app.kubernetes.io/name=tetragon -c export-stdout -f | jq
  

• Je nachdem, welche Aktivität in Ihrem Cluster stattfindet, wird ein Stream von JSON-Objekten angezeigt, die diese Ereignisse darstellen. Das folgende Code-Snippet ist eine Beispielausgabe aus dem Cluster, auf dem ArgoCD ausgeführt wurde und ein Git-Repository geklont wurde.

  {
    "process_exec": {
      "process": {
        "exec_id": "MTAuMC4xMC4yMTg6OTE0MTQ2NjAzODU0MDcwOjEwNDA4Ng==",
        "pid": 104086,
        "uid": 999,
        "cwd": "/tmp/_argocd-repo/83c509d8-f9ba-48c3-a217-a9278134963e/",
        "binary": "/usr/bin/git",
        "arguments": "rev-parse HEAD",
        "flags": "execve clone",
        "start_time": "2022-06-07T17:03:42.519Z",
        "auid": 4294967295,
        "pod": {
          "namespace": "argocd",
          "name": "argocd-repo-server-7db4cc4b45-cpvlt",
          "container": {
            "id": "cri-o://1c361244fcb1d89c02ef297e69a13bd80fd4d575ae965a92979deec740711e17",
            "name": "argocd-repo-server",
            "image": {
              "id": "quay.io/argoproj/argocd@sha256:85d55980e70f8f7073e4ce529a7bbcf6d55e51f8a7fc4b45d698f0a7ffef0fea",
              "name": "quay.io/argoproj/argocd:v2.3.4"
            },
            "start_time": "2022-05-31T16:57:53Z",
            "pid": 319
          }
        },
        "docker": "1c361244fcb1d89c02ef297e69a13bd",
        "parent_exec_id": "MTAuMC4xMC4yMTg6MzA4OTk3NTAyODQyMTEzOjExMjQ3",
        "refcnt": 1
      }
    },
    "node_name": "10.0.10.218",
    "time": "2022-06-07T17:03:42.519Z"
  }
  

Der Ereignis-Stream als JSON-Ausgabe ist verbose und schwer zu verstehen, aber es ist Information dicht. Es gibt verschiedene Möglichkeiten, diese JSON-Daten aufzunehmen und daraus analytische Informationen abzuleiten. Es ist offensichtlich, dass Sie das tetragon-CLI-Tool verwenden. Isovalent, das Unternehmen hinter Cilium und Tetragon, bietet auch ein vollwertiges kommerzielles Produkt, das diese Daten analysieren und visualisieren kann, um sie verwertbarer und einfacher zu assimilieren.

Aufgabe 1: tetra-CLI installieren

• Tetragon cli tol tetra ist nützlich, um Ereignisse nach Pod, Host, Namespace oder Prozess zu filtern. Die CLI kann von der Seite Github-Releases heruntergeladen werden. Sie können das Tool basierend auf Ihrem Betriebssystem und Ihrer CPU-Architektur herunterladen und es untar in einen Standardspeicherort wie /usr/local/bin verschieben oder den Pfad zur Binärdatei zur Variable PATH für Ihre Shell hinzufügen.

• Wenn Sie go auf Ihrer Workstation installiert haben, auf der Sie die CLI ausführen möchten, können Sie sie auch mit den folgenden Befehlen herunterladen und installieren:

  GOOS=$(go env GOOS)
  GOARCH=$(go env GOARCH)
  curl -L --remote-name-all https://github.com/cilium/tetragon/releases/latest/download/tetra-${GOOS}-${GOARCH}.tar.gz{,.sha256sum}
  sha256sum --check tetra-${GOOS}-${GOARCH}.tar.gz.sha256sum
  sudo tar -C /usr/local/bin -xzvf tetra-${GOOS}-${GOARCH}.tar.gz
  rm tetra-${GOOS}-${GOARCH}.tar.gz{,.sha256sum}
  

• Nach der Installation der CLI können die Ereignisse ziemlich gedruckt werden, indem die JSON-Ausgabe an tetra getevents übergeben wird.

  kubectl logs -n kube-system ds/tetragon -c export-stdout -f | tetra getevents -o compact
  

  Mit der Option -o compact wird eine kompakte Ausgabe anstelle von JSON angezeigt. Mit dem Tool können Sie auch die Anzeige der Ausgabe auf bestimmte Namespaces, Prozesse und mehr beschränken. Die vollständige Liste der Flags wird unten angezeigt.

  Usage:
    tetra getevents [flags]
  
  Flags:
        --color string        Colorize compact output. auto, always, or never (default "auto")
    -h, --help                help for getevents
        --host                Get host events
    -n, --namespace strings   Get events by Kubernetes namespaces
    -o, --output string       Output format. json or compact (default "json")
        --pod strings         Get events by pod name regex
        --process strings     Get events by process name regex
        --timestamps          Include timestamps in compact output
  
  Global Flags:
    -d, --debug                   Enable debug messages
        --server-address string   gRPC server address (default "localhost:54321")
  

Aufgabe 2: TracingPolicies für FileAccess und Netzwerkbeobachtbarkeit konfigurieren

TracingPolicies sind benutzerdefinierte Ressourcen, mit denen Sie ganz einfach Echtzeitfilter für Kernel-Ereignisse einrichten können. Eine TracingPolicy gleicht das System ab und filtert es nach Beobachtbarkeit und löst auch eine Aktion für diese Übereinstimmungen aus. Tetragon bietet einige Beispiele, die diese Fähigkeit zeigen und als Ausgangspunkt zur Konfiguration von TracingPolicies verwendet werden können.

• Beispiel-Tracing-Policys für FileAccess und Beobachtbarkeit anwenden

  kubectl apply -f https://raw.githubusercontent.com/cilium/tetragon/main/crds/examples/sys_write_follow_fd_prefix.yaml
  kubectl apply -f https://raw.githubusercontent.com/cilium/tetragon/main/crds/examples/tcp-connect.yaml
  

• Wenn diese zusätzlichen TracingPolicies aktiviert sind, beginnt Tetragon mit der Verfolgung des Dateizugriffs und der Netzwerkaktivität. Die folgende Ausgabe zeigt die Aktivität, die vom Kernel angezeigt wird, wenn ein curl-Befehl aufgerufen wird. Sie zeigt das Programm curl, das auf Dateien wie etc/hosts und /etc/resolv.conf zugreift und TCP-Verbindungen öffnet und Daten übertragen.

  $ kubectl logs -n kube-system ds/tetragon -c export-stdout -f | tetra getevents -o compact
  
  ...[output truncated]
  🚀 process default/xwing /usr/bin/curl -Lv https://cloud.oracle.com
  📬 open    default/xwing /usr/bin/curl /etc/ssl/openssl.cnf
  📪 close   default/xwing /usr/bin/curl
  📬 open    default/xwing /usr/bin/curl /etc/hosts
  📪 close   default/xwing /usr/bin/curl
  📬 open    default/xwing /usr/bin/curl /etc/resolv.conf
  📪 close   default/xwing /usr/bin/curl
  🔌 connect default/xwing /usr/bin/curl tcp 10.244.1.152:65175 -> 23.212.250.69:443
  📬 open    default/xwing /usr/bin/curl /etc/ssl/certs/ca-certificates.crt
  📪 close   default/xwing /usr/bin/curl
  📤 sendmsg default/xwing /usr/bin/curl tcp 10.244.1.152:65175 -> 23.212.250.69:443 bytes 517
  📤 sendmsg default/xwing /usr/bin/curl tcp 10.244.1.152:65175 -> 23.212.250.69:443 bytes 126
  📤 sendmsg default/xwing /usr/bin/curl tcp 10.244.1.152:65175 -> 23.212.250.69:443 bytes 109
  📤 sendmsg default/xwing /usr/bin/curl tcp 10.244.1.152:65175 -> 23.212.250.69:443 bytes 31
  🧹 close   default/xwing /usr/bin/curl tcp 10.244.1.152:65175 -> 23.212.250.69:443
  💥 exit    default/xwing /usr/bin/curl -Lv https://cloud.oracle.com 0
  💥 exit    default/xwing /bin/bash  0
  ...[output truncated]
  

Da diese Ereignisse direkt aus dem Kernel überwacht werden, fügt sie dem Akt der Verfolgung dieser Anrufe sehr wenig Overhead hinzu und kann sehr wenig von einem böswilligen Schauspieler verschleiert oder maskiert werden.

Der Hauptnachteil dieses Ansatzes ist, dass Aktionen, die Sie ausführen können, wie z.B. einen Prozess, der eine Datei liest, reaktionär sind, da wir über das Ereignis wissen, während es geschieht, und nicht vorher. Dennoch ist es äußerst mächtig, eine Low-Overhead-Lösung zur Filterung und Anpassung von Ereignissen auf Kernel-Ebene haben zu können und Policys zu erstellen, die uns helfen können, sie zu beobachten und zu bearbeiten.

Fehlersuche

Fehler: Wenn Sie sehen, dass Tetragon-Pods den Status CrashLoopBackOff aufweisen, kann dies aus zwei Gründen verursacht werden.

Mögliche Ursache: Der wahrscheinlichste Grund ist, dass dies auf ARM-basierten Knoten geschieht, wenn diese in Ihrem Cluster vorhanden sind. Tetragon läuft noch nicht auf Arm.

Fehlerbehebung:

• Zur Bestätigung verwenden Sie

  kubectl describe pod
  

• So zeigen Sie den Init-Container mit dem Namen tetragon-operator an. Dies ist wahrscheinlich nicht erfolgreich und befindet sich in einem beendeten Status mit dem Beendigungscode 1. Verwenden Sie

  kubectl logs <pod_name> -c tetragon-operator -n kube-system
  

• Um die Initialisierungscontainerlogs anzuzeigen, und möglicherweise wird der Grund für den Beenden des Initialisierungscontainers als standard_init_linux.go:228: exec user process caused: exec format error angezeigt. Dies bedeutet, dass die Binärdatei nicht für die Verwendung in der Arm-CPU-Architektur bestimmt ist.

Der zweite Grund könnte sein, dass Sie einen alten Kernel auf Ihrem Knoten haben, und BTF-Unterstützung ist nicht enthalten. Um zu prüfen, ob dies tatsächlich der Fall ist, rufen Sie die Containerlogs für den fehlerhaften Container wie oben beschrieben im Pod ab. Wenn die fehlende BTF-Unterstützung im Kernel das Problem ist, sehen Sie eine Fehlermeldung ähnlich der

aborting. kernel autodiscovery failed: Kernel version BTF search failed kernel is not included in supported list.
Use --btf option to specify BTF path and/or '--kernel' to specify kernel version

Dies wird auf Knoten erwartet, bei denen das Betriebssystem nicht vor kurzem oder in älteren Versionen des Betriebssystems aktualisiert wurde. Um dies zu beheben, können Sie zu den neuesten Oracle Linux 8-basierten OKE- oder Plattformimages für Ihre Worker-Knoten wechseln. Die Knotenpoolkonfiguration muss mit dieser Auswahl aktualisiert werden, und die Knoten müssen nach dem Upgradeprozess des Standardknotenpools upgegradet werden.

Verwandte Links

• OKE-Dokumentation
• Tetragon-Dokumentation
• Oracle Cloud Free Tier
• Bei Ihrem Oracle Cloud-Account anmelden

Danksagungen

• Autor - Jeevan Joseph (Senior Principal Product Manager)

Weitere Lernressourcen

Sehen Sie sich andere Übungen zu docs.oracle.com/learn an, oder greifen Sie auf weitere kostenlose Lerninhalte im Oracle Learning YouTube-Kanal zu. Besuchen Sie außerdem die Website education.oracle.com/learning-explorer, um Oracle Learning Explorer zu werden.

Produktdokumentation finden Sie im Oracle Help Center.

---

Titel und Copyright-Informationen

Install Tetragon and configure TracingPolicies on Oracle Container Engine for Kubernetes

F74876-01

December 2022

Copyright © 2022, Oracle and/or its affiliates.