Observability eBPF dengan Cilium Tetragon di Kubernetes

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.

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.

# Install Tetragon as a DaemonSet
helm repo add cilium https://helm.cilium.io
helm repo update
helm install tetragon cilium/tetragon -n kube-system
kubectl rollout status -n kube-system ds/tetragon -w

# Stream process events in real time, human-readable
kubectl exec -ti -n kube-system ds/tetragon -c tetragon -- \
  tetra getevents -o compact

# Or filter the export stream by pod / process
kubectl logs -n kube-system -l app.kubernetes.io/name=tetragon \
  -c export-stdout -f | tetra getevents -o compact --pod xwing

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.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: monitor-sensitive-file-reads
spec:
  kprobes:
    - call: "security_file_permission"
      syscall: false
      args:
        - index: 0
          type: "file"
        - index: 1
          type: "int"
      selectors:
        - matchArgs:
            - index: 0
              operator: "Equal"
              values:
                - "/etc/shadow"
            - index: 1
              operator: "Equal"
              values:
                - "4"  # MAY_READ
          # Swap the action below for "Sigkill" to enforce, not just observe
          matchActions:
            - action: Post

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.

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.

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.