Netflix’in mühendislik ekibi, 2023 sonunda üretim ortamında yaşanan ve yalnızca belirli ağ koşullarında tetiklenen bir gecikme sorununu iki haftada çözemedi. Çözüm, çekirdeği yeniden derlemeden ya da ajanı yeniden başlatmadan canlı sistem çağrılarını izleyebilen eBPF tabanlı bir araçtan geldi: Sorunu sekiz dakikada tespit etti. Bu hikâye, eBPF’nin neden kurumsal altyapı dünyasında bu denli hızlı yükseldiğini özetliyor.
\n\n
eBPF Nedir ve Neden Bu Kadar Farklı?
\n
Extended Berkeley Packet Filter (eBPF), Linux 3.18 çekirdeğiyle (2014) temeli atılan ve 5.x serisiyle olgunlaşan bir sanal makine mimarisidir. Kullanıcı alanından güvenli biçimde derlenen programları, çekirdek alanında çalıştırmanıza olanak tanır. Geleneksel yöntemlerde çekirdeği izlemek için ya çekirdek modülü yazılır (tehlikeli ve kırılgan) ya da /proc dosya sistemi sorgulanır (anlık görüntü verir, akış değil). eBPF ise bu ikilemden çıkar: Kernel değişikliği gerektirmez, donanım performansını yüzde 3-5’in altında etkiler ve yanlış yazılmış bir program sistemi çökertemez çünkü doğrulayıcı (verifier) bunu engeller.
\n\n
Gözlemlenebilirlik Katmanlarını Ayırt Etmek
\n
Kurumsal ortamda üç farklı gözlemlenebilirlik ihtiyacı vardır:
\n
- \n
- Ağ akışı izleme: Hangi pod hangi servise ne sıklıkla bağlanıyor, hangi bağlantılar zaman aşımına uğruyor?
- Sistem çağrısı denetimi: Hangi işlem hangi dosyaya dokundu, hangi komut çalıştırıldı?
- Uygulama profili: Bir HTTP isteğinin çekirdek düzeyinde nerede zaman harcadığı.
\n
\n
\n
\n
eBPF bu üç katmanı da ayrı bir ajan veya kütüphane eklemeden yönetir. Karşılaştırma için: sysdig veya tcpdump gibi geleneksel araçlar her paket/olay için bir kullanıcı alanı bağlamı geçişi (context switch) yapar. eBPF programları ise veri toplayıp filtrelemeyi doğrudan çekirdekte gerçekleştirir; sadece özet sonuçlar kullanıcı alanına aktarılır.
\n\n
Araç Ekosistemine Bakış: Cilium, Falco, Pixie
\n
Cilium: Kubernetes ağ politikası ve servis ağı (service mesh) için tasarlanmış en yaygın eBPF çözümüdür. iptables kuralları yerine eBPF haritaları kullandığı için büyük ölçekte %30-40 daha düşük gecikme sağladığı benchmark çalışmalarıyla belgelenmiştir. CNCF mezun projesidir.
\n
Falco: Aqua Security desteğiyle geliştirilen Falco, tehdit tespitine odaklanır. Kural motoru sistem çağrılarını (execve, open, connect vb.) izler ve şüpheli davranışları milisaniyeler içinde uyarıya dönüştürür. Örneğin bir container içinde kubectl veya bash çalışması anında tespit edilir.
\n
Pixie: New Relic tarafından satın alınan ve açık kaynak kalan Pixie, uygulama düzeyinde otomatik enstrümantasyon sunar. Go, Python, Java, Node.js proseslerini yeniden derleme yapmadan izler; HTTP/gRPC/Redis/MySQL protokollerini otomatik çözer.
\n\n
Adım Adım: Kubernetes Kümesine Falco Kurulumu
\n
Temel bir tehdit izleme altyapısı kurmak için:
\n
- \n
- Helm deposunu ekle:
helm repo add falcosecurity https://falcosecurity.github.io/charts - DaemonSet olarak dağıt:
helm install falco falcosecurity/falco --set driver.kind=ebpf - Varsayılan kural setini doğrula:
kubectl logs -l app.kubernetes.io/name=falco - Kural özelleştirmesi için
falco_rules.local.yamldosyasına izin verilen komutları whitelist’e ekle - Prometheus exporter’ı aktif ederek Grafana dashboard’una bağla
\n
\n
\n
\n
\n
\n\n
Güvenlik Denetiminde eBPF: sidecar’ı Geçersiz Kılar mı?
\n
Istio gibi sidecar tabanlı servis mesh’lerde her pod’a bir Envoy proxy eklenir; bu yaklaşım bellek ve CPU maliyeti açısından ağır olabilir. Küçük pod’larda sidecar, uygulamanın kendisi kadar kaynak tüketir. eBPF tabanlı Cilium Service Mesh ise bu proxy katmanını ortadan kaldırır. Cloudflare’in 2023 raporuna göre, 10.000’den fazla servise sahip iç ağda sidecar’dan eBPF’ye geçiş CPU kullanımını %26 düşürdü.
\n\n
Sınırlar ve Dikkat Edilmesi Gereken Noktalar
\n
eBPF sihirli bir çözüm değil. Linux çekirdeği 4.14 altındaki sistemlerde bazı özellikler çalışmaz; bu nedenle eski RHEL 7 kurulumları sorun çıkarabilir. Doğrulayıcı zaman zaman meşru programları da reddedebilir; özellikle döngü sayısı belirsiz olan kodlar. Bunun yanı sıra eBPF programı yazan bir saldırgan, hatalı yapılandırılmış sistemlerde ayrıcalık yükseltme açıklarından yararlanabilir — bu nedenle CAP_BPF yetki denetimi kritiktir.
\n\n
Gözlemlenebilirliğin Yeni Zemin Katı
\n
eBPF, gözlemlenebilirlik tartışmasını araçtan mimariye taşıdı. Artık soru \”hangi APM aracını kullanmalıyım\” değil \”hangi çekirdek düzeyindeki verilere ihtiyacım var ve bunu hangi güvenlik sınırları içinde toplayabilirim\” biçiminde sorulmalı. Bu paradigma değişikliği, altyapı ekiplerinin güvenlik ile performans izlemeyi ayrı disiplinler olarak değil, ortak bir çekirdek veri akışı üzerinde birleştirmesine imkân tanıyor.