← Toate știrile
ARTICOL
17 octombrie 2026 Actualizat la 23 septembrie 2026 2 min de citit

Tetragon aduce securitate runtime eBPF în kernel pentru flotele cloud-native

Tetragon, proiectul eBPF Cilium/CNCF, adaugă observabilitate runtime specifică Kubernetes și aplicarea politicilor în kernel, oferind MSP-urilor detecție dincolo de scanerele statice.

În acest articol
  1. Aplicarea politicilor care rulează în interiorul kernelului
  2. Unde se integrează alături de controalele existente
  3. Un partener pentru igiena secretelor

Tetragon, un subproiect al Cilium și un proiect al Cloud Native Computing Foundation, oferă echipelor care lucrează cu Kubernetes observabilitate runtime și aplicarea opțională a politicilor în kernel, construită pe eBPF. Pentru furnizorii de servicii gestionate care administrează flote mixte de clienți, adaugă un strat de detecție și control care se află sub ceea ce pot vedea scanerele de containere și controlerele de admitere.

Un culoar rece dintr-un centru de date cu pereți albi, flancat de dulapuri înalte de servere cu uși din plasă
Foto: Eclipse55 (CC BY-SA 4.0), Wikimedia Commons.

Aplicarea politicilor care rulează în interiorul kernelului

Spre deosebire de instrumentele care trimit fiecare eveniment în spațiul utilizatorului înainte de a decide ce să facă, Tetragon filtrează și aplică politicile direct în interiorul programului eBPF care observă apelul de sistem. Acest lucru închide fereastra dintre detecție și acțiune pe care instrumentele care rulează doar în spațiul utilizatorului o lasă deschisă și menține suprasarcina suficient de scăzută pentru utilizarea în producție. Proiectul poate urmări execuția proceselor, accesul la fișiere și activitatea de rețea, apoi poate lega fiecare eveniment de podul și containerul care l-au generat, fără un sidecar pentru fiecare aplicație.

Unde se integrează alături de controalele existente

Tetragon nu înlocuiește scanarea imaginilor sau porțile CI; acoperă ceea ce se întâmplă după ce o aplicație rulează deja. O implementare practică începe cu pași mici: inventariați ce spații de nume au deja o TracingPolicy aplicată, apoi extindeți acoperirea întâi la aplicațiile critice ale clienților. Politicile trebuie păstrate în controlul versiunii, ca orice altă configurație, astfel încât modificările să treacă prin aceeași revizuire ca și codul.

  • Începeți cu politici doar de alertare pe spațiile de nume sensibile înainte de a activa aplicarea cu blocare.
  • Urmăriți execuția neașteptată a proceselor și accesul la fișiere sensibile ca primele reguli de detecție.
  • Trimiteți evenimentele Tetragon către SIEM-ul deja folosit pentru alte alerte ale flotei.
  • Păstrați definițiile politicilor în git, astfel încât modificările să fie revizuite ca și codul.

Un partener pentru igiena secretelor

Tetragon monitorizează aplicațiile aflate în execuție; nu verifică ce este deja trimis într-un repository. TruffleHog, un instrument open-source foarte utilizat pentru scanarea secretelor, umple acest gol prin găsirea și verificarea credențialelor din cod înainte ca acestea să ajungă în producție. Rularea lui în CI la fiecare pull request și verificarea constatărilor înainte de orice rotire mențin cele două instrumente concentrate pe etape diferite ale aceleiași probleme.

Niciunul dintre instrumente nu îl înlocuiește pe celălalt. Combinarea aplicării politicilor la runtime cu scanarea secretelor înainte de commit oferă MSP-urilor acoperire la ambele capete ale pipeline-ului, fără a adăuga detalii despre atac în documentația destinată clienților.

Surse: Documentația Tetragon, GitHub — cilium/tetragon.