Falco Rehberi 2026: Kubernetes Runtime G…

Q: Falco kurallarımı nasıl test edip doğrularım?

Falco komut satırı aracı falcoctl ile kurallarınızı statik olarak doğrulayabilirsiniz: falcoctl rules validate my-rules.yaml . Ayrıca event-generator aracı (falcosecurity/event-generator), varsayılan kuralların çoğunu tetikleyecek sentetik olaylar üretir ve algılama boru hattınızın uçtan uca çalıştığını doğrular.

Güncelleme: 21 Temmuz 2026

Falco, Kubernetes düğümlerinde çekirdek seviyesinde sistem çağrılarını izleyerek konteyner içindeki şüpheli davranışları gerçek zamanlı tespit eden, CNCF tarafından "graduated" statüsüyle onaylanmış bir çalışma zamanı (runtime) güvenlik projesidir. Bu rehberde Falco 0.40+ sürümüyle gelen modern eBPF sürücüsünü kullanarak Helm ile kurulum, varsayılan kural setinin analizi, üretim ortamı için özel kural yazımı, Falcosidekick ile Slack/PagerDuty uyarı yönlendirmesi ve MITRE ATT&CK for Containers kapsamının nasıl doğrulanacağını adım adım göstereceğim. Amacım şu: kümenizde konteyner kaçış (container escape), kripto madencilik ve tedarik zinciri saldırılarını dakikalar içinde görebilir hale getirmek. Açıkçası, geçen yıl bir müşteri kümesinde çalışırken hafta sonumu kurtaran tam olarak bu bileşendi.

Falco, eBPF ile çekirdek sistem çağrılarını dinler; RBAC ve NetworkPolicy'nin göremediği konteyner içi davranışları izler.
2026'da varsayılan sürücü modern_ebpf'tir; çekirdek modülü ve legacy eBPF kullanımdan kaldırılmıştır.
Falco alarm üretir, engellemez. Engelleme için OPA/Gatekeeper veya Kyverno gibi admission controller'lar kullanılır.
Varsayılan kural seti 40+ MITRE ATT&CK for Containers tekniğini kapsar; k8s_audit kuralları için API sunucusundan denetim günlüğü akışı gerekir.
Falcosidekick, 70+ hedefe (Slack, PagerDuty, Elasticsearch, AWS SNS, Loki) uyarı yönlendirir ve üretim kurulumunda standart bileşendir.
eBPF sürücüsünün CPU maliyeti tipik iş yüklerinde %1 ile %5 arasındadır; kötü yazılmış kurallar bu maliyeti hızla yükseltir.

Falco nedir ve neden Kubernetes için gerekli?

Falco, 2016'da Sysdig tarafından oluşturulmuş ve 2024'te CNCF içinde "graduated" statüsüne yükselmiş açık kaynaklı bir çalışma zamanı güvenlik motorudur. Temel işlevi aslında oldukça basit: Linux çekirdeğinden akan sistem çağrılarını (syscalls) yakalar, bunları YAML tabanlı bir kural motorundan geçirir ve eşleşen olaylar için yapılandırılabilir çıktı kanallarına uyarı gönderir. Konteyner içinde açılan bir kabuk (shell), /etc/shadow okuma girişimi, çalıştırıldıktan sonra imaja eklenmemiş bir paket yöneticisinin tetiklenmesi... bunların hepsi Falco'nun standart repertuarındadır.

Kubernetes güvenliğinin katmanlı modelinde Falco kritik bir boşluğu doldurur. RBAC kullanıcıların API üzerinden ne yapabileceğini kontrol eder; NetworkPolicy pod'lar arası trafiği kısıtlar; PodSecurity Standards pod spesifikasyonlarını doğrular. Ancak bir pod başlatıldıktan sonra içinde neyin çalıştığını, hangi dosyanın açıldığını, hangi sürecin ana süreçten türediğini bu mekanizmaların hiçbiri göremez. Falco tam olarak bu "workload çalıştıktan sonra" katmanında yaşar. Bir saldırgan meşru bir imajı ele geçirip içinde curl | sh çalıştırdığında, admission controller'lar çoktan izin vermiş olur. Falco, olayı gerçek zamanlı yakalayan tek bileşen olur.

Falco tek başına bir konteyner güvenliği çözümü değildir; algılama ve uyarı katmanıdır. Engelleme yapmaz, çünkü bu görev OPA/Gatekeeper, Kyverno veya Kubernetes admission controller'larına aittir. Bu ayrım önemli: Falco'yu bir "duvar" olarak konumlandırmak yerine, konteyner içi olaylar için SIEM ve EDR arasında bir köprü olarak düşünün. Aşağıda okuyacağınız kurulum ve kural mimarisi bu felsefeyi izler. Kernel katmanında ek sıkılaştırma için Linux çekirdek güvenlik sıkılaştırma rehberimize bakabilirsiniz.

Mimari: eBPF sürücüsü ve DaemonSet modeli

Falco'nun mimarisi üç temel bileşenden oluşur: sürücü (driver), userland motor ve kural motoru. Sürücü, çekirdekten sistem çağrısı olaylarını toplar ve userland Falco sürecine iletir. 2026 itibarıyla desteklenen tek üretim sürücüsü modern_ebpf'tir. Klasik çekirdek modülü ve legacy eBPF probu sırasıyla kullanımdan kaldırılmıştır ve Falco 0.40 sürümünde binary içine derlenmiş bir CO-RE (Compile Once, Run Everywhere) eBPF probu getirilmiştir. Bu, çekirdek başlıklarının (kernel headers) düğümlerde bulunmasına ihtiyaç duymadan Falco'nun Linux 5.8+ çekirdeğinin bulunduğu herhangi bir düğümde çalışabileceği anlamına gelir.

Kubernetes'te Falco bir DaemonSet olarak konuşlandırılır; yani her düğümde tam olarak bir Falco pod'u çalışır. Bu tercih tesadüf değildir. eBPF probu düğüm çekirdeğine bağlıdır ve o düğümde çalışan tüm konteynerlerin sistem çağrılarını görmek zorundadır. DaemonSet ayrıca hostNetwork, hostPID ve ayrıcalıklı çekirdek erişimi gerektirir; bunlar Helm chart tarafından güvenli varsayılanlarla ayarlanır ama SecurityContextConstraint (OpenShift) veya PodSecurity Standards ile açıkça izin verilmesi gerekebilir.

Kural değerlendirme motoru userland'de çalışır ve olayları paralel olarak çok sayıda kurala karşı eşleştirir. Falco 0.36'dan itibaren Falco Plugins mimarisi vardır: sistem çağrılarına ek olarak Kubernetes audit log'ları, AWS CloudTrail, GitHub audit event'leri gibi kaynaklardan da olay tüketilebilir. Bu, Falco'yu saf syscall gözlemcisinden çok kaynaklı bir tehdit algılama motoruna dönüştürür.

Falco'yu Helm ile Kubernetes'e nasıl kurarsınız?

Üretim ortamı için önerdiğim kurulum yöntemi resmi Falco Helm chart'ıdır. Aşağıdaki adımlar Kubernetes 1.28+ ve Helm 3.14+ üzerinde test edilmiştir. Öncelikle chart deposunu ekleyip güncelleyin.

# Falco Helm deposunu ekle ve indeksini güncelle
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update

# Mevcut sürümü doğrula (2026 Q2 itibarıyla ~0.40.x)
helm search repo falcosecurity/falco --versions | head -5

Kurulumu falco ad alanına, modern eBPF sürücüsü ve Kubernetes meta veri toplayıcı etkin şekilde yapın:

helm install falco falcosecurity/falco \
  --namespace falco \
  --create-namespace \
  --set driver.kind=modern_ebpf \
  --set collectors.kubernetes.enabled=true \
  --set tty=true \
  --set falcosidekick.enabled=true \
  --set falcosidekick.webui.enabled=true

# DaemonSet'in her düğümde hazır olmasını bekle
kubectl -n falco rollout status daemonset/falco --timeout=180s
kubectl -n falco get pods -o wide

Kurulumu doğrulamak için ünlü "hello world" testini çalıştırın: bir pod içinde kabuk açın ve Falco loglarında karşılık gelen uyarıyı arayın. İtiraf etmeliyim, ilk kurulumumda bu testi atlamıştım ve sonra bir üretim olayında Falco'nun aslında hiç uyarı üretmediğini fark etmek oldukça can sıkıcıydı.

# Falco'nun görebileceği bir pod başlat
kubectl run test-shell --image=alpine --restart=Never -- sleep 3600

# Konteyner içinde kabuk aç (Falco "Terminal shell in container" uyarısı üretmeli)
kubectl exec -it test-shell -- sh

# Falco loglarını izle
kubectl -n falco logs -l app.kubernetes.io/name=falco --tail=20 | grep -i "terminal shell"

Varsayılan kural seti ve MITRE ATT&CK kapsamı

Falco varsayılan olarak falco_rules.yaml, falco-incubating_rules.yaml ve falco-sandbox_rules.yaml setleriyle gelir. Sadece stabil kurallar üretime uygundur. Incubating ve sandbox kuralları eş zamanlı test edilmeli, kabul edilebilir gürültü seviyesine göre etkinleştirilmelidir. Stabil set, MITRE ATT&CK for Containers matrisindeki 40'tan fazla tekniği kapsar. Özellikle Execution (T1059 komut satırı yorumlayıcıları), Persistence (T1136 hesap oluşturma), Privilege Escalation (T1611 konteyner kaçışı) ve Discovery (T1082 sistem bilgisi keşfi) taktiklerinde güçlüdür.

Kutudan çıkan tespitlerin en önemli örnekleri şunlardır:

Terminal shell in container: bir konteyner içinde bash, sh, dash veya zsh çağrılması. En sık kaçış öncesi keşif işaretidir.
Write below binary dir: /bin, /sbin, /usr/bin gibi yollara yazma girişimleri. Meşru workload'lar bunu yapmaz.
Read sensitive file untrusted: /etc/shadow, SSH özel anahtarları, cloud credential dosyalarına okuma erişimi.
Contact K8s API server from container: konteynerlerin Kubernetes API'sine servis hesabı ile beklenmedik erişimi.
Launch privileged container: privileged: true flag'i ile pod başlatılması.
Modify binary dirs: mevcut binary'lerin üzerine yazılması.

Kural setinin kapsamını değerlendirmek için resmi falcosecurity/rules deposundaki mitre_tags etiketlerini inceleyin. Her kural, kapsadığı MITRE tekniğini metadata olarak taşır. Uzun soluklu bir güvenlik programı için, kümeye özel bir "kapsam matrisi" tutmanızı ve boşlukları özel kurallarla doldurmanızı öneririm.

Özel Falco kuralları nasıl yazılır?

Falco kuralları YAML'dır ve üç temel yapı taşından oluşur: lists (yeniden kullanılabilir değer listeleri), macros (yeniden kullanılabilir koşullar) ve rules (asıl algılama tanımları). Örnek olarak, çalışan bir konteynerde paket yöneticisinin çağrılmasını yakalayan bir kural yazalım. Bu, imajın çalışırken kurcalandığına dair oldukça güçlü bir sinyaldir.

# /etc/falco/rules.d/custom-package-manager.yaml
- list: package_management_binaries
  items: [apt, apt-get, dpkg, dnf, yum, rpm, apk, pip, pip3, npm, gem]

- macro: package_manager_in_container
  condition: >
    spawned_process
    and container
    and proc.name in (package_management_binaries)

- rule: Package Manager Launched in Container
  desc: >
    Bir çalışma zamanı konteynerinde paket yöneticisi çağrıldı. Paketler imaj
    aşamasında yüklenmeli, çalışan konteynerde değil. Bu, saldırgan yükleme
    veya izinsiz yapılandırma değişikliğinin işareti olabilir.
  condition: package_manager_in_container
  output: >
    Konteyner içinde paket yöneticisi çalıştırıldı
    (user=%user.name command=%proc.cmdline container=%container.name
    image=%container.image.repository:%container.image.tag)
  priority: WARNING
  tags: [container, mitre_execution, T1059]

Bu kuralı yükledikten sonra bir pod içinde apk add curl gibi bir komut çalıştırdığınızda Falco uyarı üretmelidir. Kurulum sırasında chart'a customRules parametresi ile dosyayı gömebilirsiniz:

helm upgrade falco falcosecurity/falco \
  --namespace falco \
  --reuse-values \
  --set-file customRules."custom-package-manager\.yaml"=./custom-package-manager.yaml

# Kural yükleme geçmişini doğrula
kubectl -n falco exec -it ds/falco -- falco --list-plugins
kubectl -n falco logs -l app.kubernetes.io/name=falco --tail=50 | grep -i "loading rules"

Falcosidekick ile uyarı yönlendirme

Falco tek başına stdout ve dosya çıktısı üretir. Üretim ortamında uyarıların Slack, PagerDuty, Elasticsearch, Loki veya bir olay yönetim sistemine ulaşması gerekir. Bunu Falcosidekick sağlar: Falco alarmlarını 70'ten fazla hedefe yönlendiren bir yan servistir. Yukarıdaki helm install komutunda falcosidekick.enabled=true ile aktive ettik; şimdi Slack ve Loki hedeflerini yapılandıralım.

# Slack webhook URL'sini sır olarak sakla
kubectl -n falco create secret generic falcosidekick-slack \
  --from-literal=webhookurl="https://hooks.slack.com/services/T00/B00/XXXXXXXX"

# Helm ile Slack ve Loki hedeflerini etkinleştir
helm upgrade falco falcosecurity/falco \
  --namespace falco \
  --reuse-values \
  --set falcosidekick.config.slack.webhookurl="$SLACK_WEBHOOK" \
  --set falcosidekick.config.slack.minimumpriority=warning \
  --set falcosidekick.config.loki.hostport="http://loki.observability.svc:3100" \
  --set falcosidekick.config.loki.minimumpriority=informational

Falcosidekick WebUI (falcosidekick.webui.enabled=true) uyarıları tarayıcıdan görselleştirmenize izin verir. Küçük ekipler için başlangıçta yeterlidir, ancak uzun vadeli saklama için Loki + Grafana veya Elasticsearch + Kibana önerilir. Yayılım (fan-out) desenleri için Falcosidekick resmi GitHub deposunun "outputs" dokümantasyonunu inceleyin.

Kubernetes audit log entegrasyonu ve k8s_audit kuralları

Falco'nun bir kısmı, özellikle "Create Privileged Pod", "Attach To Cluster Admin Role" gibi kurallar, syscall'lardan değil, Kubernetes API sunucusunun ürettiği audit log'lardan beslenir. Bu kurallar k8s_audit kaynağına aittir. API sunucusu bu log'ları Falco'ya iletmiyorsa, ne kadar kural aktif ederseniz edin uyarı almazsınız. Bu, yeni Falco kullanıcılarının en sık düştüğü tuzaklardan biridir (bir müşteride bunun yüzünden üç ay boyunca "sessiz Falco" ile yaşadıklarını gördüm).

API sunucusuna audit politikası tanımlayın ve log'ları Falco'nun webhook backend'ine gönderin. Yönetilen Kubernetes servislerinde (EKS, GKE, AKS) audit log'ları CloudWatch/Stackdriver'a akar; bunları Falco'ya bağlamak için k8saudit-eks, k8saudit-gke plugin'lerini kullanın. Kendi kubeadm kümenizde ise --audit-policy-file ve --audit-webhook-config-file flag'lerini kube-apiserver'a ekleyin. Doğrulama:

# Falco'nun k8s_audit kaynağını dinlediğini doğrula
kubectl -n falco exec -it ds/falco -- falco --list-sources
# Beklenen çıktı: syscall, internal, k8s_audit

# Test için ayrıcalıklı bir pod başlat
kubectl run test-priv --image=alpine --overrides='{"spec":{"containers":[{"name":"c","image":"alpine","securityContext":{"privileged":true}}]}}' --restart=Never

# Falco loglarında "Create Privileged Pod" uyarısı görünmelidir
kubectl -n falco logs -l app.kubernetes.io/name=falco --tail=20 | grep -i privileged

Performans, gürültü azaltma ve üretim ipuçları

Falco'nun modern eBPF probu, tipik Kubernetes düğümlerinde %1 ile %5 arası CPU maliyeti getirir. Bu maliyeti düşük tutmanın anahtarı, iyi yazılmış kurallardır. Saniyede milyonlarca syscall'ı eşleştiren zayıf koşullar CPU'yu hızla %20'lere çıkarabilir. Aşağıdaki üç uygulama, üretimde Falco'yu sürdürülebilir kılan temel taşlardır.

1. Gürültü tabanı belirleyin. Falco'yu kurduktan sonra ilk hafta hiçbir kuralı devre dışı bırakmayın; sadece dinleyin. Uyarı hacmini gün/gün ölçün, en gürültülü 10 kuralı çıkarın ve her birini ya sıkılaştırın (örneğin belirli namespace'lere kısıtlayın) ya da meşru davranış içinse istisna listeleri (exceptions) ekleyin. Kural devre dışı bırakmayı son çare olarak görün.

2. İstisna mekanizmasını doğru kullanın. Falco 0.28'den itibaren kurallara exceptions bloğu eklenebilir; bu, kuralı devre dışı bırakmadan bilinen meşru istisnaları hariç tutmanın standart yoludur. Örnek:

- rule: Terminal shell in container
  exceptions:
  - name: allowed_debug_containers
    fields: [container.image.repository, k8s.ns.name]
    values:
    - [busybox, debug-tools]
    - [alpine/curl, ops]

3. Yatay ölçek yerine sürücü ayarları. Falco DaemonSet'tir; yatay ölçek zaten otomatiktir (her düğüm = 1 pod). Yüksek syscall hacimli düğümlerde engine.kind=modern_ebpf ile birlikte syscall_event_drops.threshold: 0.1 ve syscall_buf_size_preset: 4 ayarlarını değerlendirin; bu, olay düşürme oranını azaltırken çekirdek bufferini büyütür. Ağ katmanı sıkılaştırması için nftables ile Linux güvenlik duvarı rehberimizi tamamlayıcı okuma olarak öneririm.

Falco, Tetragon ve Sysdig Secure karşılaştırması

Konteyner çalışma zamanı güvenliği alanında 2026 itibarıyla üç ana seçenek öne çıkıyor: Falco, Cilium Tetragon ve ticari Sysdig Secure. Doğru seçim, önceliklerinizle (algılama, engelleme veya yönetilen çözüm) doğrudan ilgilidir.

Özellik	Falco	Tetragon	Sysdig Secure
Lisans	Apache 2.0 (CNCF Graduated)	Apache 2.0 (CNCF Incubating)	Ticari (SaaS)
Çekirdek arayüzü	eBPF (CO-RE)	eBPF (CO-RE, kprobe)	eBPF + çekirdek modülü
Engelleme (blocking)	Hayır (sadece uyarı)	Evet (BPF LSM, signal)	Evet
Kural dili	YAML (declarative)	TracingPolicy CRD	YAML + politika UI
k8s audit desteği	Evet (plugin)	Sınırlı	Evet
Uyarı yönlendirme	Falcosidekick (70+ hedef)	Hubble, JSON export	Yerleşik SaaS
Öğrenme eğrisi	Orta	Yüksek	Düşük
Kurumsal destek	Sysdig (opsiyonel)	Isovalent/Cisco	Sysdig (dahil)

Pratik özet: algılama önceliğiniz ise ve mevcut SIEM'inize entegre olmak istiyorsanız Falco doğal tercihtir. Engelleme gerekiyorsa (örneğin sıfır güven mimarisi kapsamında konteynerden dış ağa erişimi kesmek) Tetragon'un BPF LSM tabanlı yetenekleri güçlüdür. Yönetilen tek panel arıyorsanız Sysdig Secure ticari, ancak operasyonel yükü minimumdur. Birçok ekip Falco + Tetragon'u birlikte konuşlandırır: Falco geniş kapsamlı algılama, Tetragon kritik yollar için sert engelleme sağlar. Ben kendi kurulumlarımda bu ikili yaklaşımı tercih ediyorum, çünkü bir bileşenin gürültüsü diğerinin sessizliğini doğruluyor.

Sık Sorulan Sorular

Falco kullanmak için özel bir Linux çekirdeği gerekir mi?

Hayır. Falco 0.40+ ile gelen modern eBPF sürücüsü, CO-RE (Compile Once, Run Everywhere) tekniğini kullanarak Linux 5.8 ve üzeri çekirdek çalıştıran herhangi bir düğümde çekirdek başlıkları yüklemeden çalışır. Bulut sağlayıcılarının çoğu (EKS AL2023, GKE COS, AKS Ubuntu 22.04) bu şartı karşılar.

Falco olayları engelleyebilir mi yoksa sadece uyarı mı verir?

Falco tasarım gereği yalnızca uyarı verir; engelleme yapmaz. Engelleme için OPA/Gatekeeper, Kyverno veya Cilium Tetragon gibi araçlarla birlikte kullanılması gerekir. Bu ayrım, Falco'yu ağ ve syscall katmanında düşük gecikmeli tutar ve yanlış pozitiflerin üretim iş yüklerini durdurmasını engeller.

Falco'nun performans maliyeti nedir?

Modern eBPF sürücüsüyle tipik Kubernetes düğümlerinde %1 ile %5 arası CPU ek yükü ölçülür. Bu değer, aktif kural sayısına ve syscall hacmine göre değişir. Kötü yazılmış geniş koşullu kurallar bu maliyeti %20'ye kadar çıkarabilir; iyi ayarlanmış üretim kural setleri %3'ün altında kalır.

Falco ve Fail2ban arasındaki fark nedir?

Fail2ban, log dosyalarını (özellikle SSH ve web sunucusu logları) izleyerek brute-force saldırılarını IP bazında engeller ve host seviyesinde çalışır. Falco ise konteyner içindeki syscall'ları izler ve Kubernetes iş yüklerine odaklıdır. İkisi tamamlayıcıdır; ayrıntı için Fail2ban kurulum ve yapılandırma rehberimize bakabilirsiniz.

Falco kurallarımı nasıl test edip doğrularım?

Falco komut satırı aracı falcoctl ile kurallarınızı statik olarak doğrulayabilirsiniz: falcoctl rules validate my-rules.yaml. Ayrıca event-generator aracı (falcosecurity/event-generator), varsayılan kuralların çoğunu tetikleyecek sentetik olaylar üretir ve algılama boru hattınızın uçtan uca çalıştığını doğrular.