eBPF Runtime Security di Kubernetes dengan Guardrail yang Praktis

Pendahuluan

Banyak cluster Kubernetes sudah terlihat rapi di atas kertas. Image dipindai di pipeline, admission policy aktif, dan beberapa namespace sensitif sudah memakai network policy. Namun blind spot yang paling mahal sering baru muncul setelah workload benar-benar berjalan. Shell interaktif muncul di container yang seharusnya immutable, proses asing mengeksekusi binary yang tidak pernah ada di baseline, atau service yang normalnya hanya berbicara ke tiga backend tiba-tiba membuat koneksi ke destination yang tidak dikenal.

Di sinilah eBPF runtime security mulai relevan. Ia memberi visibility dekat ke kernel tanpa memaksa tim memasang sidecar atau agent berat ke setiap service. Nilainya bukan pada buzzword eBPF itu sendiri, melainkan pada kemampuan melihat perilaku runtime yang sebelumnya gelap. Untuk production environment, pendekatan ini hanya berguna jika diterapkan dengan disiplin. Tanpa baseline yang baik dan policy yang sempit, runtime security akan berubah menjadi pabrik alert yang melelahkan.

Konsep Utama

Runtime security menjawab perilaku, bukan konfigurasi

Scanning di CI/CD dan admission control menjawab apa yang kita bangun dan apa yang kita izinkan masuk ke cluster. Runtime security menjawab apa yang benar-benar terjadi setelah container hidup. Ini termasuk:

• process execution yang menyimpang
• network flow yang tidak sesuai profil service
• file write di path yang seharusnya tidak berubah
• child process yang muncul dari binary atau interpreter yang tidak seharusnya ada

Perbedaan ini penting. Banyak insiden tidak datang dari image yang jelas-jelas berbahaya, tetapi dari workload sah yang dipakai untuk perilaku yang tidak sah.

Event kernel tanpa konteks Kubernetes nilainya rendah

Sinyal seperti execve, openat, atau connect memang berguna, tetapi nilainya rendah jika tidak diperkaya dengan metadata cluster. Tim perlu tahu namespace, pod, image digest, service account, owner deployment, dan environment. Tanpa itu, event eBPF terlihat teknis tetapi sulit dipakai untuk keputusan operasional.

Enforcement harus datang setelah fase belajar

Kesalahan paling umum adalah mencoba memblok perilaku terlalu cepat. Pada cluster nyata, ada migration job, init container, debug workflow, dan batch process yang tidak pernah terdokumentasi dengan sempurna. Jika semua deviasi langsung diblok, tim platform akan kehilangan kepercayaan dari engineer aplikasi sebelum kontrol ini sempat membuktikan nilainya.

Arsitektur / Cara Kerja

Arsitektur eBPF runtime security yang sehat biasanya terdiri dari beberapa lapisan:

1. eBPF program pada kernel untuk menangkap syscall dan event network yang relevan
2. node-level collector atau security agent untuk mengumpulkan event
3. enrichment pipeline untuk memetakan event ke metadata Kubernetes
4. policy engine untuk deteksi, severity classification, dan selective enforcement
5. sink observability seperti SIEM, data lake, atau incident pipeline

Pola rollout yang aman biasanya dibagi menjadi tiga tahap:

1. observability-only untuk membangun baseline
2. detection pada behavior yang hampir selalu salah
3. enforcement pada workload bernilai tinggi

Behavior yang biasanya cocok untuk fase awal antara lain shell execution di app container, package manager berjalan di runtime, atau file write pada path yang seharusnya read-only. Sinyal ini jauh lebih stabil dibanding mencoba mendeteksi semua anomali dari hari pertama.

Baseline per workload class lebih sehat daripada baseline cluster-wide

Cluster production jarang homogen. Stateless API, background worker, data plane, dan admin tooling punya pola runtime yang sangat berbeda. Menyatukan semuanya dalam satu baseline akan menghasilkan noise yang besar. Lebih sehat jika workload dikelompokkan berdasarkan pola perilaku dan criticality.

Korelasi dengan ownership menentukan kecepatan respons

Sebuah event proses mencurigakan lebih berguna jika langsung terhubung ke owner service dan jalur incident response. Tim tidak ingin berhenti pada “ada shell di pod tertentu”. Mereka ingin cepat menjawab:

• service apa yang terdampak
• siapa owner-nya
• apakah ini production atau sandbox
• image mana yang sedang berjalan
• apakah ada deployment baru sebelum sinyal muncul

Studi Kasus / Masalah Nyata

Shell muncul pada image distroless

Pada beberapa insiden, tim menemukan proses sh atau bash pada workload yang seharusnya menggunakan image minimal. Ini bisa berasal dari debug container yang tidak terkontrol, perubahan image yang lolos review, atau indikasi compromise. Tanpa runtime visibility, cluster tetap terlihat sehat di level deployment meski boundary operasionalnya sudah berubah.

Alert volume meledak setelah rollout pertama

Ketika event kernel mulai dikumpulkan, organisasi sering baru menyadari betapa bising runtime sebenarnya. Job sementara, utility legacy, dan script internal yang tidak terdokumentasi memunculkan banyak deviasi. Jika tidak ada fase tuning dan ownership mapping, security team akan tenggelam dalam alert yang tidak bisa diprioritaskan.

False confidence dari health check biasa

Service mungkin tetap lulus liveness dan readiness probe walau sedang menjalankan proses tambahan yang tidak sah, atau membuat koneksi keluar ke destination yang tidak sesuai desain. Health check hanya menjawab bahwa service masih merespons, bukan bahwa perilakunya masih sehat.

Enforcement menghambat recovery

Pada insiden production, engineer kadang perlu melakukan debug sementara. Jika runtime enforcement terlalu kaku dan tidak ada break-glass yang diaudit, tim bisa kehilangan kemampuan untuk memulihkan layanan dengan cepat. Kontrol keamanan yang baik harus mengurangi blast radius tanpa membunuh jalur recovery.

Best Practices

Mulai dari namespace dan workload yang paling bernilai

Prioritaskan:

• identity service
• payment path
• secret broker
• CI control plane
• cluster admin tooling

Pendekatan ini memberi sinyal yang lebih bernilai dan mengurangi noise sejak awal.

Gunakan policy yang hampir pasti benar

Contoh policy awal yang biasanya sehat:

• shell execution di workload aplikasi
• package manager pada runtime
• write ke filesystem pada container read-only
• binary troubleshooting di image yang seharusnya minimal

Pisahkan channel alert dan channel investigation

Tidak semua runtime event harus masuk ke pager. Banyak event lebih tepat diarahkan ke jalur triage, enrichment tambahan, atau correlation dengan deployment timeline. Jika semua hal menjadi incident, tidak ada yang benar-benar terasa penting.

Siapkan break-glass yang sempit dan diaudit

Runtime security bukan alasan untuk melarang semua exception. Yang dibutuhkan adalah jalur pengecualian yang time-bound, jelas owner-nya, dan tercatat.

Ukur kualitas kontrol, bukan jumlah alert

Metrik yang lebih berguna:

• false positive rate
• mean time to triage
• cakupan pada workload tier-1
• jumlah policy yang benar-benar masuk ke mode enforce

Kesalahan Umum

• menganggap runtime security sebagai pengganti hardening di pipeline
• memblok perilaku sebelum baseline terbentuk
• tidak memperkaya event dengan konteks Kubernetes
• mengirim semua event ke kanal incident yang sama
• mengabaikan biaya storage dan query dari telemetry runtime
• menganggap semua workload punya pola perilaku yang seragam

Kesimpulan

eBPF runtime security berguna bukan karena ia modern, tetapi karena ia membantu tim melihat perilaku yang sebelumnya tidak terlihat. Nilainya muncul saat event kernel diterjemahkan menjadi konteks workload yang dapat ditindaklanjuti. Pada cluster production, pendekatan yang paling sehat bukan memblok semuanya sejak hari pertama, melainkan membangun baseline, memilih sinyal yang stabil, dan menegakkan enforcement hanya di area yang benar-benar bernilai tinggi. Dengan cara itu, runtime security menjadi guardrail yang operasional, bukan sekadar dashboard yang bising.