Mon premier contact avec Tetragon

Dans cette série d’articles, nous allons découvrir Tetragon qui est un outil pour sécuriser les clusters Kubernetes.

Voici les différentes questions que vous pourrez répondre après la lecture de ces articles :

• Est-ce que cet outil est fait pour votre cluster Kubernetes ?
• Comment on l’installe ?
• Comment cela fonctionne ?
• Comment étendre ses fonctionnalités de base ?

Dans ce premier article, nous allons avoir une vue d’ensemble de ce qu’est Tetragon.

Qu’est-ce que Tetragon ?

#

Qu’est-ce que c’est qu’ce bin’s ?

#

Vous vous êtes déjà demandé ce qu’il se passait réellement dans chacun de vos pods de vos clusters Kubernetes à un instant T ? Quels processus sont lancés ? Par qui ? Avec quels arguments ?

Et si un de vos pods était compromis, comment détecter le comportement malveillant avant qu’il ne cause de dégats ?

C’est exactement dans ces domaines que Tetragon intervient.

Il a été créé par l’entreprise Isovalent qui est également à l’origine de Cilium, un plugin CNI pour les clusters Kubernetes. Tout comme Cilium, Tetragon est basé sur eBPF.

C’est quoi eBPF ?

#

Les programmes eBPF sont des programmes qui s’exécutent dans le noyau Linux. Ils sont attachés (ou crochetés, hook en anglais) à des points spécifiques du noyau. Chaque fois que le noyau Linux passe par un hook, le programme est déclenché.

Ces programmes sont relativement difficiles à écrire car il faut connaître la programmation système bas niveau.

Comment Tetragon utilise eBPF ?

#

Tetragon est en fait un “générateur” de programmes eBPF :

• vous allez créer des tracing policies (en yaml) ;
• Tetragon va se charger de les traduire en programmes eBPF et de les installer dans le noyau Linux de chaque serveur ;
• chaque fois que l’événement (event) décrit dans la tracing policies aura lieu, Tetragon génèrera un log avec toutes les informations disponibles.

Ainsi vous n’aurez pas besoin de connaître un langage bas niveau. Mais comprendre eBPF et avoir une bonne compréhension du noyau Linux est fondamental pour devenir expert Tetragon.

Maintenant que nous avons vu le fonctionnement théorique de Tetragon, passons à la pratique.

Démonstration de Tetragon 🚀

#

Installation sur un serveur

#

Nous allons montrer comment on installe Tetragon hors Kubernetes. Cela permettra de mieux comprendre comment il fonctionne sans connaître Kubernetes.

Nous allons installer la dernière version de Tetragon (1.6.0 au moment de l’écriture). On va créer des variables pour que l’installation soit toujours compatible avec les nouvelles versions :

VERSION=v1.6.0
ARCH=amd64 #other choice arm64

N’hésitez pas à vérifier s’il n’y a pas des versions plus récentes.

Nous téléchargeons et décompressons le tar gz :

curl -LO https://github.com/cilium/tetragon/releases/download/$VERSION/tetragon-${VERSION}-${ARCH}.tar.gz
tar -xvf tetragon-${VERSION}-${ARCH}.tar.gz

Nous installons ensuite Tetragon :

cd tetragon-${VERSION}-${ARCH}/
sudo ./install.sh

Cela va simplement copier les binaires dans les bons répertoires, configurer systemd, etc.

Regardons les événements de Tetragon

#

Avant même de créer vos propres tracing policies, Tetragon produit déjà des events par défaut.
Grâce à la ligne de commande officielle tetra, vous pouvez récupérer ces events en direct :

tetra getevents -o compact

Grâce à cette commande, vous allez voir les logs que génèrent Tetragon. Ici, sans configuration, vous pourrez observer :

• tous les processus qui démarrent en direct (🚀)
• tous les processus qui meurent en direct (💥)

Ainsi à l’installation, Tetragon injecte déjà des programmes eBPF dans le noyau Linux permettant de logger tout le cycle de vie des processus.

À titre d’exemple, voici ce que je vois dans ma VM :

🚀 process lima-default /usr/sbin/iptables -t nat -S
💥 exit    lima-default /usr/sbin/iptables -t nat -S 0
🚀 process lima-default /usr/bin/touch /var/lib/apt/periodic/upgrade-stamp
🚀 process lima-default /usr/bin/apt-config shell MaxAge APT::Archives::MaxAge
🚀 process lima-default /usr/bin/dpkg --print-foreign-architectures
🚀 process lima-default /usr/bin/apt-config shell MaxAge APT::Periodic::MaxAge
🚀 process lima-default /usr/bin/dpkg --print-foreign-architectures
🚀 process lima-default /usr/bin/apt-config shell MinAge APT::Archives::MinAge
🚀 process lima-default /usr/sbin/iptables -t nat -S
💥 exit    lima-default /usr/sbin/iptables -t nat -S 0

• La première colonne est un emoji qui informe le statut du processus (🚀 ou 💥)
• La deuxième colonne est sa traduction (process ou exit)
• La troisième colonne est le nom du serveur
• La quatrième colonne est le nom de la commandes et ses arguments
• Si le processus est en exit, la dernière colonne est le code retour de commande (0 si cela se passe bien)

On peut également changer la sortie standard et avoir des logs plus standards avec du json et comme ça il ne reste plus qu’à installer des outils comme Prometheus, Grafana ou Fluentbit pour l’exploiter de manière asynchrone.

Introduction aux politiques de traces

#

L’installation de Tetragon permet déjà d’observer pas mal de choses. Mais certaines informations plus spécifiques ne sont pas disponibles automatiquement, par exemple :

• savoir quel pod communique avec une IP précise ;
• vérifier si un fichier particulier a été modifié.

Pour cela, il faut définir des tracing policies (politiques de traces, traduction français non officielle). Par ailleurs, ces tracing policies permettent d’aller encore plus loin : en plus d’observer, Tetragon pourra agir avant même que le binaire ait fini son exécution.

Tetragon peut alors agir de façon proactive en empêchant un processus d’accéder à une ressource par exemple.

Nous avons introduit ce qu’est Tetragon :

• son fonctionnement général ;
• son installation sur un serveur Linux ;
• son comportement par défaut ;
• et la manière d’étendre ses capacités via des Tracing Policies.

Dans la prochaine partie, nous installerons Tetragon dans son environnement naturel : Kubernetes.