Remarque :

Ce tutoriel nécessite un accès à Oracle Cloud. Pour vous inscrire à un compte gratuit, reportez-vous à Introduction à Oracle Cloud Infrastructure Free Tier.
Il utilise des exemples de valeur pour les informations d'identification Oracle Cloud Infrastructure, la location et les compartiments. A la fin de votre atelier, remplacez ces valeurs par celles propres à votre environnement cloud.

Installer Tetragon et configurer TracingPolicies sur Oracle Container Engine for Kubernetes

Introduction

Alors que les outils basés sur eBPF deviennent plus populaires pour les applications cloud natives, ce tutoriel explique comment exécuter Tetragon, un outil basé sur eBPF pour l'observabilité et l'application de la sécurité sur Oracle Cloud Infrastructure (OCI).

Qu'est-ce que l'eBPF et pourquoi est-il populaire ?

Un noyau de système d'exploitation est généralement le meilleur endroit pour observer et influencer un système car il y a très peu de barrières entre l'outil réalisant une fonction et les activités qu'il tente d'observer et d'influencer. L'exécution dans l'espace du noyau permet souvent à un programme d'avoir une surcharge très faible, mais au coût de la sécurité et de la maintenance.

eBPF fournit une méthode permettant d'introduire de nouvelles fonctionnalités pouvant s'exécuter dans un contexte restreint et privilégié sans modifier le code source du noyau ni charger un module de noyau. Il fonctionne essentiellement en créant un paradigme similaire à un langage de programmation basé sur une machine virtuelle. De manière similaire à la façon dont les programmes Java modernes sont compilés en byte-code que la JVM (Java Virtual Machine) compile en code natif à l'aide d'un compilateur JIT pour obtenir des performances natives, les programmes eBPF ont une représentation de code octet. BPF est profondément lié au noyau Linux et le compilateur JIT du noyau compile le code exécutable eBPF en code natif pouvant s'exécuter dans l'espace du noyau.

eBPF utilise un modèle basé sur les événements pour charger les programmes et les programmes eBPF sont écrits pour "hook" dans les événements réseau, les appels système, etc. Lorsqu'un événement auquel un programme eBPF s'accroche a été appelé, le programme eBPF est chargé dans le noyau après vérification et compilation JIT. L'étape de vérification garantit que le programme est exécuté en toute sécurité, dispose des privilèges appropriés et peut être exécuté jusqu'à la fin, tandis que la compilation JIT garantit des performances natives. Dans de nombreux cas, les programmes eBPF sont écrits dans des langues de niveau supérieur et compilés dans la représentation du code octet. Ceux-ci sont ensuite chargés dans un noyau en cours d'exécution après la compilation JIT en fonction des événements auxquels les programmes sont connectés.

Tetragon - Observabilité et application de la sécurité basée sur eBPF

Tetragon est un outil eBPF natif du cloud qui assure l'observabilité et l'application de la sécurité. C'est un élément du projet cilium. Grâce à eBPF, Tetragon peut filtrer et observer les événements et appliquer des stratégies en temps réel sans envoyer d'événements à un agent qui s'exécute en dehors du noyau. Tetragon peut traiter de nombreux cas d'utilisation de sécurité et d'observabilité en filtrant pour des événements tels qu'une charge de travail ouvrant une connexion réseau, accédant à un fichier ou même en démarrant un processus à l'intérieur d'un conteneur. Par exemple, un processus shell démarré dans un conteneur d'application peut être considéré comme un événement de sécurité. Il peut s'agir d'une personne qui tente de résoudre un problème ou d'une activité malveillante, de quelque manière que ce soit, ce qui devrait déclencher une vérification de sécurité pour exclure une attaque sur le système. Il en va de même pour les connexions réseau ouvertes ou la lecture de fichiers. Tetragon peut tracer et filtrer ces activités tout en introduisant peu ou pas de frais généraux et généralement au premier stade que ces événements peuvent être détectés dans le logiciel.

Tetragon convient parfaitement aux charges de travail Kubernetes et s'exécute en tant que daemonset dans chaque noeud du cluster. Tetragon peut alors extraire des métadonnées à partir du serveur d'API Kubernetes et corréler ces métadonnées avec les événements observés dans le noyau de chaque noeud. Tetragon facilite la mise en place de filtres en temps réel pour ces activités et plus encore en utilisant TracingPolicies. TracingPolicy est une ressource personnalisée créée par Tetragon qui permet aux administrateurs et à DevSecOps de créer et de déployer des filtres pour les événements de noyau en tant que ressources Kubernetes. Un élément TracingPolicy peut correspondre aux appels système, aux attributs de processus et aux arguments, et déclencher une action sur les correspondances.

Objectif

Découvrez comment configurer Tetragon sur un cluster OKE dans OCI.
Découvrez comment utiliser TracingPolicies pour observer et regrouper des événements.

Prérequis

S'inscrire ou se connecter à votre compte Oracle Cloud
Création d'un cluster OKE

Remarque : Tetragon peut être déployé sur des clusters Kubernetes comme Oracle Container Engine for Kubernetes (OKE) à l'aide du graphique d'aide publié par le projet Tetragon. Une fois installé, le CRD TracingPolicy est créé et Tetragon s'exécute sur les noeuds de cluster en tant que daemonset.

Prérequis pour Oracle Linux

OKE utilise Oracle Linux et Tetragon repose sur la prise en charge de BTF (BPF Type Format) dans le noyau. Les noyaux Oracle Linux récents incluent ces noyaux prêts à l'emploi. Par conséquent, les utilisateurs doivent utiliser un noyau 5.4.17-2136.305.3.el7uek ou plus récent. Tetragon ne fournit pas non plus de support pour l'architecture Arm (linux/arm64) et au moment de l'écriture ne fournit que le support x86 (linux/amd64). Si vous disposez de noeuds de bras dans votre cluster OKE, l'ensemble de démon conserve le statut Init:CrashLoopBackOff.

Remarque : les versions récentes des images de noeud OKE sont basées sur des noyaux qui incluent la prise en charge de BTF. Cette mise en garde pour la prise en charge de BTF s'applique uniquement aux clusters dans lesquels le système d'exploitation du noeud n'a pas été mis à jour depuis un certain temps, et non aux clusters nouvellement créés. Si vous n'êtes pas sûr, le meilleur moyen de vérifier si la prise en charge de BTF est de vous connecter via SSH au noeud et d'exécuter ls /sys/kernel/btf, vous devriez voir le noyau (vmlinux) ainsi que les modules répertoriés ici. Notez que les noeuds basés sur Oracle Linux 8 sont préférés pour ce déploiement.

Pour vérifier la version du noyau que vos noeuds sont en cours d'exécution, exécutez uname -a sur le noeud. Si vous exécutez une ancienne version du noyau, vous pouvez mettre à niveau la version sur la configuration du pool de noeuds. Toutefois, cela n'affecte que les noeuds nouvellement créés et les noeuds existants ne sont pas mis à niveau automatiquement pour garantir la continuité des charges de travail susceptibles d'être exécutées sur eux. Vous pouvez suivre le processus de mise à niveau du pool de noeuds pour placer vos noeuds existants dans les versions de noyau les plus récentes.

Une fois que vous avez vérifié que vous utilisez une version récente du noyau sur vos noeuds, vous pouvez commencer l'installation de Tetragon à l'aide du graphique d'aide Tetragon. Vous pouvez également suivre les instructions de la page github de Tetragon.
```
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
```
Une fois que l'ensemble de démon est prêt et que les pods tetragon sont à l'état En cours d'exécution, vous pouvez commencer à écouter les événements sur vos noeuds. Prêt à l'emploi, il peut surveiller l'exécution des processus. Tetragon émet les événements correspondants au format JSON et les journaux peuvent être observés à l'aide de la commande suivante (en supposant que jq est installé)
```
kubectl logs -n kube-system -l app.kubernetes.io/name=tetragon -c export-stdout -f | jq
```

Selon l'activité qui se produit sur votre cluster, un flux d'objets JSON représentant ces événements apparaît. Le fragment de code suivant est un exemple de sortie du cluster qui exécutait ArgoCD, où il clonait un référentiel Git.

{
  "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"
}

Le flux d'événements en tant que sortie JSON est détaillé et difficile à comprendre, mais les informations sont denses. Il existe plusieurs façons d'ingérer ces données JSON et d'en dériver des informations analytiques. L'outil CLI tetragon est évident. Isovalent, l'entreprise derrière Cilium et Tetragon propose également un produit commercial complet qui peut analyser et visualiser ces données pour le rendre plus exploitable et plus facile à assimiler.

Tâche 1 : installation de l'interface de ligne de commande `tetra`

Le Tetragon cli tol tetra est utile pour filtrer les événements par pod, hôte, espace de noms ou processus. La CLI peut être téléchargée à partir de la page des versions de github. You can download the tool based on your operating system and CPU architecture, and untar it to a standard location such as /usr/local/bin or add the path to the binary to your PATH variable for your shell.

Sinon, si go est installé sur votre poste de travail sur lequel vous souhaitez exécuter le cli, vous pouvez le télécharger et l'installer à l'aide des commandes suivantes :

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}

Une fois l'interface de ligne de commande installée, les événements peuvent être assez imprimés en transmettant la sortie JSON à tetra getevents.

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

L'option -o compact affiche une sortie compacte au lieu de JSON. L'outil vous permet également de limiter l'affichage de sortie à certains espaces de noms, processus, etc. La liste complète des indicateurs est affichée ci-dessous

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")

Tâche 2 : configuration de TracingPolicies pour FileAccess et observation du réseau

TracingPolicies sont des ressources personnalisées qui facilitent la configuration de filtres en temps réel pour les événements de noyau. Un TracingPolicy met en correspondance et filtre les appels système pour l'observabilité et déclenche également une action sur ces correspondances. Tetragon propose quelques exemples qui présentent cette capacité et peuvent être utilisés comme point de départ pour configurer votre TracingPolicies.

Appliquer les exemples de stratégie de trace pour FileAccess et Observability

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

Lorsque ces TracingPolicies supplémentaires sont activés, Tetragon démarre le suivi de l'accès aux fichiers ainsi que de l'activité réseau. La sortie ci-dessous illustre l'activité vue à partir du noyau lorsqu'une commande curl est appelée. Il indique au programme curl d'accéder à des fichiers tels que etc/hosts et /etc/resolv.conf, d'ouvrir des connexions TCP et de transférer des données.

$ 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]

Comme ces événements sont surveillés directement à partir du noyau, il ajoute très peu de temps système à l'acte de traçage de ces appels et très peu peut être brouillé ou masqué par un acteur malveillant.

Le principal inconvénient de cette approche est que les actions que vous pouvez prendre comme dire, tuer un processus qui lit un fichier est réactionnaire, en ce que nous savons sur l'événement tel qu'il se produit, et pas avant. Pourtant, il est extrêmement puissant de pouvoir disposer d'une solution à faible surcharge pour filtrer et mettre en correspondance les événements au niveau du noyau et de pouvoir créer des stratégies qui peuvent nous aider à les observer et à agir dessus.

Dépannage

Erreur : si vous voyez que les pods Tetragon sont dans un état CrashLoopBackOff, cela peut être dû à deux raisons.

Raison possible : la raison la plus probable est que cela se produit sur les noeuds basés sur Arm, si vous les avez dans votre cluster. Tetragon ne fonctionne pas encore sur Arm.

Résoudre les problèmes :

Pour confirmer, utiliser
```
kubectl describe pod
```
Pour afficher le conteneur d'initialisation nommé tetragon-operator. Cela est probablement en échec et dans un état terminé avec le code de sortie 1. Vous pouvez utiliser
```
kubectl logs <pod_name> -c tetragon-operator -n kube-system
```
Pour afficher les journaux du conteneur d'initialisation, vous pouvez voir la raison pour laquelle le conteneur d'initialisation se termine en tant que standard_init_linux.go:228: exec user process caused: exec format error, ce qui indique que le fichier binaire n'est pas destiné à être utilisé sur l'architecture de la CPU Arm.

La deuxième raison peut être que vous avez un ancien noyau sur votre noeud et que la prise en charge de BTF n'est pas incluse. Pour vérifier s'il s'agit effectivement du problème, obtenez les journaux de conteneur pour le conteneur défaillant dans le pod comme décrit ci-dessus. Si l'absence de prise en charge de BTF dans le noyau est le problème, un message d'erreur semblable au suivant s'affiche :

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

Cela est attendu sur les noeuds dont le système d'exploitation n'a pas été mis à jour récemment ou sur des versions antérieures du système d'exploitation. Pour résoudre ce problème, vous pouvez passer aux dernières images OKE ou de plate-forme basées sur Oracle Linux 8 pour vos noeuds de processus actif. La configuration du pool de noeuds doit être mise à jour avec ce choix et les noeuds mis à niveau après le processus de mise à niveau du pool de noeuds standard.

Remerciements

Auteur - Jeevan Joseph (chef de produit principal)

Ressources de formation supplémentaires

Explorez d'autres ateliers sur docs.oracle.com/learn ou accédez à davantage de contenu de formation gratuit sur le canal Oracle Learning YouTube. En outre, accédez à education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.

Pour consulter la documentation produit, consultez Oracle Help Center.

Informations relatives au titre et au copyright

Install Tetragon and configure TracingPolicies on Oracle Container Engine for Kubernetes

F74876-01

December 2022