Tetragon apporte la sécurité d’exécution eBPF dans le noyau pour les flottes cloud-natives

Tetragon, sous-projet de Cilium et projet de la Cloud Native Computing Foundation, offre aux équipes qui travaillent avec Kubernetes une observabilité d’exécution et une application facultative des politiques dans le noyau, reposant sur eBPF. Pour les fournisseurs de services gérés qui exploitent des flottes clients hétérogènes, il ajoute une couche de détection et de contrôle située en dessous de ce que peuvent voir les scanners de conteneurs et les contrôleurs d’admission.

Application des politiques dans le noyau

Contrairement aux outils qui envoient chaque événement vers l’espace utilisateur avant de décider quoi faire, Tetragon filtre et applique les politiques directement dans le programme eBPF qui observe l’appel système. Cela referme la fenêtre entre la détection et l’action que les outils limités à l’espace utilisateur laissent ouverte, et maintient une surcharge suffisamment faible pour un usage en production. Le projet peut suivre l’exécution des processus, les accès aux fichiers et l’activité réseau, puis relier chaque événement au pod et au conteneur qui l’a produit, sans sidecar par charge de travail.

Sa place aux côtés des contrôles existants

Tetragon ne remplace pas l’analyse d’images ni les portes de CI\u00A0; il couvre ce qui se passe une fois qu’une charge de travail est déjà en cours d’exécution. Un déploiement pragmatique commence à petite échelle\u00A0: recensez les espaces de noms qui disposent déjà d’une TracingPolicy appliquée, puis étendez la couverture aux charges de travail client critiques en premier. Les politiques doivent être placées dans un contrôle de version comme toute autre configuration, afin que les modifications suivent la même revue que le code.

• Commencez par des politiques en mode alerte uniquement sur les espaces de noms sensibles avant d’activer une application bloquante.
• Surveillez les exécutions de processus inattendues et les accès aux fichiers sensibles comme premières règles de détection.
• Transférez les événements Tetragon vers le SIEM déjà utilisé pour les autres alertes de la flotte.
• Conservez les définitions de politiques dans git afin que les modifications soient revues comme du code.

Un compagnon pour l’hygiène des secrets

Tetragon surveille les charges de travail en cours d’exécution\u00A0; il ne vérifie pas ce qui est déjà versionné dans un dépôt. TruffleHog, un outil open source de détection de secrets largement utilisé, comble cette lacune en trouvant et en vérifiant les informations d’identification dans le code avant qu’elles n’atteignent la production. L’exécuter dans la CI à chaque demande de fusion et vérifier les résultats avant toute rotation permet aux deux outils de se concentrer sur des étapes différentes du même problème.

Aucun des deux outils ne remplace l’autre. Associer l’application des politiques à l’exécution à l’analyse des secrets avant commit donne aux MSP une couverture aux deux extrémités du pipeline, sans ajouter de détails d’attaque à la documentation destinée aux clients.

Sources\u00A0: Documentation Tetragon, GitHub — cilium/tetragon.