# Observability eBPF dengan Cilium Tetragon di Kubernetes

> Bagaimana eBPF menjalankan program tersandbox di dalam kernel Linux tanpa modul, dan bagaimana Tetragon mengubahnya menjadi visibilitas proses, jaringan, dan berkas di Kubernetes.

URL: https://www.matthewswong.com/id/blog/ebpf-observability-cilium-tetragon/

- Author: Matthews Wong (https://www.matthewswong.com/id/about/)
- Published: 2026-07-14
- Updated: 2026-07-14
- Category: Security

> **Key takeaway:** eBPF memungkinkan Anda menjalankan program tersandbox di dalam kernel Linux tanpa memuat modul atau reboot. Tetragon, proyek CNCF dari tim Cilium, memakainya untuk mengamati eksekusi proses, koneksi jaringan, dan akses berkas di Kubernetes, serta bisa menegakkan kebijakan secara sinkron di dalam kernel dengan overhead di bawah satu persen.

Selama bertahun-tahun, mendapatkan visibilitas nyata atas apa yang benar-benar dilakukan sebuah kontainer saat berjalan berarti memilih satu dari dua opsi buruk: menempelkan agen sidecar ke setiap pod, atau mengirim modul kernel dan berharap ia tidak membuat node panik pada upgrade kernel berikutnya. Di klaster Kubernetes yang saya jalankan di VPS swakelola, tidak ada yang terasa dapat diterima. eBPF mengubah perhitungan itu, dan Tetragon adalah alat yang saya gunakan ketika ingin melihat setiap proses yang muncul, setiap koneksi keluar, dan setiap berkas sensitif yang disentuh, tanpa satu pun perubahan aplikasi.

Tulisan ini menjelaskan apa itu eBPF, bagaimana ia terpasang ke kernel dengan aman tanpa modul, dan bagaimana Tetragon mengubah mesin itu menjadi visibilitas proses dan jaringan yang praktis di Kubernetes. Semua di bawah ini berasal dari pengalaman menjalankannya secara nyata, bukan dari halaman pemasaran.

## Apa sebenarnya eBPF itu

eBPF, singkatan dari extended Berkeley Packet Filter, adalah teknologi yang tertanam di kernel Linux yang memungkinkan Anda menjalankan program kecil tersandbox di dalam ruang kernel. Anggaplah ini sebagai mesin virtual ringan yang tertanam di kernel. Anda menulis program, kernel memuatnya, dan ia dieksekusi saat sebuah peristiwa tertentu terpicu. Yang penting, Anda melakukan ini tanpa mengubah kode sumber kernel, tanpa mengompilasi modul kernel, dan tanpa reboot. Poin terakhir itulah alasan eBPF menguasai perkakas observability dan keamanan di dunia cloud native.

Program eBPF bersifat event-driven. Ia berjalan saat kernel atau aplikasi melewati sebuah hook point. Hook yang telah ditentukan mencakup system call, masuk dan keluar fungsi, tracepoint kernel, dan peristiwa jaringan. Ketika tidak ada hook bawaan yang cocok, Anda memasang kernel probe (kprobe) atau user probe (uprobe) untuk menempatkan program Anda hampir di mana saja di kernel atau di aplikasi ruang pengguna.

## Bagaimana ia mengait kernel tanpa modul

Alasan eBPF aman dijalankan di kernel sementara modul buatan tangan tidak, terletak pada tiga tahap: verifier, kompiler JIT, dan sandbox itu sendiri. Program Anda dikompilasi menjadi bytecode generik dan diserahkan ke kernel. Sebelum diizinkan berjalan, verifier menganalisis secara statis setiap jalur eksekusi yang mungkin.

- Verifier menolak program jika ia bisa berputar selamanya, membaca memori di luar batas, atau mendereferensi pointer tidak valid. Tidak ada loop tak berujung, tidak ada akses memori kernel sembarangan.
- Kompiler JIT lalu menerjemahkan bytecode terverifikasi menjadi instruksi mesin native, sehingga berjalan hampir secepat kode kernel terkompilasi.
- Program hanya menyentuh keadaan kernel melalui sekumpulan fungsi helper terbatas dan map bertipe, tidak pernah pointer mentah ke struktur sembarangan.

> Modul kernel yang bermasalah bisa membuat seluruh node crash. Program eBPF yang bermasalah ditolak saat pemuatan oleh verifier, atau ia sekadar kembali tanpa merusak kernel. Perbedaan itulah seluruh alasan teknologi ini dipercaya di produksi. Jangan menonaktifkan verifier atau menjalankan program tak terverifikasi dari sumber yang tidak tepercaya.

## Di mana Tetragon berperan

Menulis eBPF mentah bukan sesuatu yang ingin dilakukan sebagian besar engineer hanya untuk menjawab pertanyaan mendasar seperti biner apa yang berjalan di dalam sebuah pod. Tetragon adalah lapisan yang menghilangkan friksi itu. Ia adalah proyek CNCF yang dipelihara tim Cilium (awalnya Isovalent, kini bagian dari Cisco), dan berjalan sebagai DaemonSet di Kubernetes. Setiap agen Tetragon memuat program eBPF di node-nya dan mengalirkan peristiwa yang diperkaya dengan identitas Kubernetes: namespace, pod, kontainer, dan label.

Sejak awal, sebelum Anda menulis kebijakan apa pun, Tetragon sudah mengumpulkan peristiwa eksekusi dan keluarnya proses untuk setiap kontainer. Itu saja memberi Anda jejak yang dapat diaudit atas setiap perintah yang dijalankan di klaster, terkorelasi dengan beban kerja yang menjalankannya. Instalasi adalah latihan Helm dua menit.

## Visibilitas proses dan jaringan dalam praktik

Peristiwa proses default berguna, tetapi kekuatan sesungguhnya datang dari TracingPolicy: resource Kubernetes kustom yang memberi tahu Tetragon persis peristiwa kernel mana yang harus diamati, dan secara opsional apa yang harus dilakukan saat peristiwa itu terpicu. Anda bisa memantau system call tertentu seperti execve, memantau koneksi ke sebuah port TCP, atau menandai setiap pembacaan jalur sensitif seperti berkas yang menyimpan hash kata sandi. Karena penyaringan terjadi di kernel, Anda tidak membayar untuk mengirim jutaan peristiwa tak relevan ke ruang pengguna.

Kebijakan itu memantau setiap upaya membaca berkas kata sandi shadow di seluruh klaster. Jika dibiarkan sebagai Post, ia mengamati dan melaporkan. Ubah aksinya menjadi Sigkill dan Tetragon membunuh proses pelanggar secara sinkron, di dalam kernel, sebelum pembacaan selesai. Karena penegakannya berada di kernel dan sinkron, ia menutup celah time-of-check-to-time-of-use yang dialami agen ruang pengguna: tidak ada jeda antara mendeteksi peristiwa dan bertindak atasnya.

> Mulailah setiap TracingPolicy dalam mode amati-saja (aksi Post). Jalankan selama beberapa hari, baca peristiwanya, dan pastikan Anda tidak akan meng-Sigkill proses yang sah. Baru setelah itu beralih ke penegakan. eBPF memberi Anda pisau yang sangat tajam; verifier mencegah Anda melukai kernel, bukan diri Anda sendiri.

## Perkakas berbasis agen versus eBPF: kompromi

eBPF bukannya tanpa kekurangan. Layak untuk jujur tentang di mana ia unggul dan di mana ia membebani Anda, agar Anda masuk dengan ekspektasi yang tepat.

| Aspek | eBPF / Tetragon | Agen / modul tradisional |
| --- | --- | --- |
| Deployment | Satu DaemonSet, tanpa perubahan aplikasi | Sidecar per pod atau modul kernel per node |
| Overhead | Umumnya di bawah 1 persen, penyaringan di kernel | Lebih tinggi, menyalin peristiwa ke ruang pengguna dulu |
| Keamanan | Verifier menolak program tidak aman saat muat | Modul buruk bisa membuat seluruh node panik |
| Penegakan | Sinkron, di kernel, tanpa celah TOCTOU | Sering asinkron, jendela waktu yang bisa dieksploitasi |
| Ketergantungan kernel | Butuh kernel terbaru dan BTF untuk fitur penuh | Modul harus dibangun ulang per versi kernel |

Satu peringatan yang menyusahkan orang adalah versi kernel. Fitur eBPF dan CO-RE (kompilasi sekali, jalan di mana saja lewat informasi tipe BTF) bergantung pada kernel yang cukup modern. Pada kernel distro lama Anda mendapat set fitur yang berkurang. Periksa kernel node Anda sebelum merencanakan rollout, terutama di klaster terkelola tempat Anda tidak mengendalikan image.

## Kapan saya memakainya, dan kapan tidak

Jika Anda butuh jejak audit berbiaya rendah atas eksekusi proses dan aktivitas jaringan di seluruh klaster Kubernetes, atau penegakan runtime sinkron tanpa menginstrumentasi aplikasi, eBPF via Tetragon adalah opsi terkuat yang tersedia saat ini. Itulah yang saya jalankan untuk visibilitas tingkat klaster. Yang bukan ia adalah SIEM lengkap atau pengganti pemindaian image dan admission control; ia mengamati dan menegakkan saat runtime, jadi pasangkan dengan kontrol saat build dan deploy alih-alih memperlakukannya sebagai satu-satunya lapisan.

## Sources

- eBPF.io — What is eBPF? An Introduction and Deep Dive
- Tetragon — eBPF-based Security Observability and Runtime Enforcement (official site)
- Tetragon Documentation — Events concepts

## Source links

- https://ebpf.io/what-is-ebpf/
- https://tetragon.io/
- https://tetragon.io/docs/concepts/events/

## FAQ

### Apakah saya perlu memuat modul kernel untuk memakai eBPF?

Tidak. Itulah inti dari eBPF. Anda memuat program tersandbox ke kernel yang sedang berjalan dan memasangnya ke hook point tanpa mengompilasi modul, menambal kode sumber kernel, atau reboot. Verifier kernel memeriksa program secara statis untuk perilaku tidak aman sebelum diizinkan berjalan, dan kompiler JIT mengubahnya menjadi kode mesin native.

### Apa beda Cilium dan Tetragon?

Cilium adalah lapisan jaringan, keamanan, dan observability berbasis eBPF untuk Kubernetes, berfokus pada konektivitas dan kebijakan jaringan. Tetragon adalah sub-proyek di bawah Cilium yang berfokus khusus pada observability keamanan dan penegakan runtime: eksekusi proses, koneksi jaringan, dan akses berkas. Anda bisa menjalankan Tetragon tanpa memakai Cilium sebagai CNI.

### Berapa besar overhead yang ditambahkan Tetragon?

Karena penyaringan dan penegakan terjadi di dalam kernel memakai eBPF alih-alih menyalin setiap peristiwa ke agen ruang pengguna, overhead umumnya dilaporkan di bawah satu persen. Angka pastinya bergantung pada berapa banyak TracingPolicy yang Anda muat dan seberapa bising peristiwa yang dipantau. Penyaringan di kernel itulah yang membuatnya murah.

### Bisakah Tetragon memblokir serangan, atau hanya mengamati?

Ia bisa keduanya. Dalam mode amati, sebuah TracingPolicy memakai aksi Post dan melaporkan peristiwa. Ubah aksinya menjadi Sigkill dan Tetragon menghentikan proses pelanggar secara sinkron di dalam kernel, sebelum operasi selesai. Penegakan sinkron ini menutup celah time-of-check-to-time-of-use yang dibiarkan terbuka oleh agen ruang pengguna asinkron.

### Versi kernel apa yang saya butuhkan untuk eBPF dan Tetragon?

Anda butuh kernel Linux yang cukup modern. Fitur penuh, termasuk CO-RE via informasi tipe BTF, bergantung pada kernel yang lebih baru; kernel distro lama memberi set fitur yang berkurang. Selalu periksa kernel yang berjalan di node Anda sebelum merencanakan rollout, terutama di Kubernetes terkelola tempat Anda tidak mengendalikan image node.

---

- HTML version: https://www.matthewswong.com/id/blog/ebpf-observability-cilium-tetragon/
- English: https://www.matthewswong.com/en/blog/ebpf-observability-cilium-tetragon/
- Site index for agents: https://www.matthewswong.com/llms.txt
- Sitemap: https://www.matthewswong.com/sitemap.xml
- API description (OpenAPI): https://www.matthewswong.com/openapi.json