Belajar Cilium - Identity-Based Security Model

#Pendahuluan

Dari episode 4 kita sudah tahu bahwa setiap endpoint punya sebuah identity — angka numerik yang menjadi kunci security model Cilium. Episode 5 membedah konsep ini secara mendalam: bagaimana label Kubernetes diubah menjadi identity, mengapa keamanan berbasis identitas mengalahkan berbasis IP, serta bagaimana default allow dan deny bekerja di Cilium.

Pemahaman ini penting karena hampir semua policy yang akan kalian tulis di episode 6 hingga 13 memakai identity sebagai bahan bakunya. Jika kalian paham apa itu identity dan bagaimana ia dibentuk, menulis dan membaca policy menjadi terasa alami.

Penting juga untuk membedakan dua istilah yang sering tertukar: identity dan label. Label adalah string yang menempel pada pod; identity adalah angka yang diturunkan dari kumpulan label. Kalian boleh mengubah label kapan pun, tapi identity hanya berubah saat label yang membentuknya berubah. Seluruh policy Cilium sebenarnya berurusan dengan identity, bukan label secara langsung.

#Label menjadi Identity Numerik

Setiap pod di Kubernetes punya label — pasangan key dan value seperti app=frontend atau tier=web. Cilium mengambil kumpulan label dari sebuah pod, mengubahnya menjadi sebuah identity, yaitu angka unik. Semua pod yang memakai kombinasi label yang sama akan berbagi identity yang sama.

Keuntungannya sangat besar: ketika policy ditulis terhadap identity, dan sebuah pod baru lahir dengan label yang sama, policy otomatis berlaku tanpa perlu update. Sebaliknya, dalam pendekatan berbasis IP, setiap pod baru memaksa kalian menambah aturan baru. Ini adalah perbedaan fundamental antara Cilium dan NetworkPolicy bawaan Kubernetes.

Alokasi identity dilakukan oleh Cilium Operator dan disinkronkan ke semua agent. Pemetaan label ke identity disimpan dalam objek Kubernetes bernama CiliumIdentity, yang bisa kalian lihat dengan kubectl:

kubectl get ciliumidentity

kubectl get ciliumidentity menampilkan daftar identity beserta label yang memicunya. Kalian akan melihat banyak identity dengan label yang mirip dengan label pod di cluster kalian.

Konsekuensi dari pemetaan label ke identity yang perlu disadari: mengubah label sebuah pod berarti mengubah identity-nya. Jika sebuah deployment menambahkan label baru, semua pod yang sudah berjalan akan mendapatkan identity baru, dan policy yang menargetkan label lama bisa kehilangan cakupannya. Perubahan label pada deployment harus diperlakukan sebagai perubahan keamanan, bukan sekadar perubahan metadata.

#Default Allow vs Deny

Satu konsep yang sering membingungkan: Cilium secara default mengizinkan semua traffic. Tidak ada policy yang aktif berarti semua komunikasi diizinkan — sama seperti cluster Kubernetes bawaan. Default deny hanya muncul setelah policy terkait diterapkan.

Aturannya sederhana dan penting untuk diingat:

• Endpoint tanpa policy ingress menerima semua traffic masuk.
• Endpoint tanpa policy egress bisa mengirim ke mana saja.
• Ketika policy pertama diterapkan pada sebuah endpoint, mode berubah menjadi default deny untuk arah tersebut.
• Policy bersifat additive: menggabungkan semua rule yang diizinkan.

Pola ini disebut juga allow-list. Alih-alih menulis aturan untuk memblokir (block-list), kalian menulis apa yang boleh lewat, dan sisanya otomatis di-block. Untuk memahami kenapa ini penting, coba pikirkan: dalam sistem block-list, sebuah aturan yang terlupa artinya celah keamanan; dalam allow-list, sebuah rule yang terlupa artinya komunikasi tertahan — dan itu bisa dideteksi lewat observability.

Pola allow-list ini adalah alasan mengapa mendesain policy dari nol sering terasa "lebih mudah" daripada memperbaiki policy yang sudah berantakan: semuanya eksplisit dan bisa diverifikasi. Di episode 6 kita akan mempraktikkan cara menulis allow-list ini untuk ingress dan egress, dan di episode 13 kita akan memperluasnya ke level aplikasi.

#Evaluasi Policy di Dataplane

Ketika sebuah paket tiba di endpoint tujuan, dataplane melakukan evaluasi berlapis:

1. Baca identity dari paket (diambil dari metadata socket atau header tambahan).
2. Cari policy ingress yang berlaku untuk identity sumber.
3. Cocokkan terhadap rule yang ada (label selector, port, protokol).
4. Jika cocok dengan salah satu rule izin, paket diteruskan; jika tidak, paket di-drop.

Semua langkah ini terjadi di dalam kernel dengan bantuan eBPF. Karena identity disertakan dalam metadata, dataplane tidak perlu melakukan lookup label yang mahal per paket — cukup membandingkan angka identity, yang jauh lebih cepat daripada membandingkan string label.

Evaluasi ini berlaku untuk kedua arah: ingress dan egress. Untuk egress, dataplane memeriksa policy keluar dari endpoint sumber; untuk ingress, dataplane memeriksa policy masuk di endpoint tujuan. Sebuah koneksi hanya diizinkan jika kedua sisi mengizinkannya. Ini berarti policy ingress dan egress bekerja bersama-sama — kalian tidak bisa "menyelundupkan" traffic dengan hanya menulis satu sisi.

#Melihat Identity dengan Cilium

Selain kubectl, identity bisa dilihat dari sisi dataplane. Masuk ke pod agent dan jalankan:

kubectl exec -n kube-system -it ds/cilium -- cilium-dbg identity list

cilium-dbg identity list menampilkan tabel identity dari sudut pandang node tersebut, termasuk identity khusus seperti host, remote-node, dan world. Beberapa identity penting yang akan sering muncul:

• Identity host: traffic yang berasal dari node itu sendiri.
• Identity remote-node: traffic dari node lain di cluster.
• Identity world: traffic dari luar cluster (internet).
• Identity unreserved: pod yang belum punya policy atau belum teridentifikasi.

Untuk memeriksa identity dari satu pod spesifik, gunakan command yang menampilkan label dan identity sekaligus:

kubectl exec -n kube-system -it ds/cilium -- cilium-dbg endpoint list

cilium-dbg endpoint list menampilkan kolom Identity untuk setiap endpoint. Cocokkan nomor identity di sini dengan angka di cilium identity list untuk memahami kombinasi label yang membentuknya.

#Identity di Tingkat Kubernetes

Identity bukan konsep abstrak di dalam kernel; ia juga diekspos sebagai objek Kubernetes. Dua resource yang berguna untuk dilihat:

kubectl get ciliumidentity
kubectl get cep -n default

kubectl get ciliumidentity menampilkan identity beserta label pemicunya dari perspektif control plane. kubectl get cep -n default menampilkan CiliumEndpoint — resource per pod yang berisi alamat IP dan identity yang sedang dipakai pod tersebut.

Perbedaan sudut pandang ini penting: cilium-dbg identity list membaca state di dalam agent (dataplane), sedangkan kubectl get ciliumidentity membaca state di control plane. Keduanya biasanya sinkron, tetapi ketika tidak sinkron — misalnya identity baru belum disinkronkan ke agent — itulah titik awal masalah yang akan kita bahas di episode 19.

kubectl get ciliumidentity -n default -o yaml | grep -A5 -B2 labels

kubectl get ciliumidentity -o yaml menampilkan detail lengkap pemetaan label ke identity. Dengan menggabungkan output ini dan cilium-dbg endpoint list, kalian bisa menelusuri dari sebuah pod, ke label, ke identity, hingga ke policy yang menargetkannya — rantai yang menjadi tulang punggung security model Cilium.

#Penutup

Inti yang harus dibawa pulang:

• Label Kubernetes dipetakan menjadi identity numerik oleh Cilium Operator.
• Endpoint dengan label sama berbagi identity yang sama, apa pun IP-nya.
• Default Cilium adalah allow semua; default deny aktif saat policy pertama diterapkan.
• Policy Cilium adalah allow-list: rule menentukan apa yang boleh, sisanya di-block.
• Evaluasi policy terjadi di dataplane dengan membandingkan identity, bukan string label.
• Identity penting: host, remote-node, world, dan unreserved.

Di episode 6 selanjutnya kita akan membuat CiliumNetworkPolicy pertama — memahami struktur CNP untuk ingress dan egress, memilih target dengan label selector, membatasi port dan range, lalu menerapkan serta menguji policy menggunakan hubble observe. Di sinilah konsep identity di episode ini benar-benar dipakai.