Belajar Flannel - Network Policy Ecosystem

#Pendahuluan

Kubernetes menyediakan NetworkPolicy sebagai standar untuk membatasi traffic antar Pod. Namun standar itu hanya jalan jika CNI-nya menerapkannya. Di sinilah Flannel jujur mengakui batasnya.

Episode 14 menjelaskan mengapa Flannel tidak menerapkan NetworkPolicy, lalu memandu menambahkan policy engine di atas Flannel tanpa mengganti CNI. Kalian akan menginstall Calico policy-only, menerapkan NetworkPolicy pertama, dan memverifikasinya.

#Kenapa Flannel Tidak Menerapkan NetworkPolicy

#Batasan CNI Data Plane

NetworkPolicy butuh mesin yang memfilter paket berdasarkan label Pod dan mempertahankan state koneksi. Flannel dirancang sebagai data plane sederhana yang hanya membangun route dan overlay. Menambahkan enforcement policy akan merusak kesederhanaan yang menjadi alasan utama orang memilih Flannel.

#Pola yang Umum Dipakai

Alih-alih mengganti CNI, pola yang umum adalah menambahkan policy engine terpisah. Engine ini membaca NetworkPolicy dari API server, mengonversinya menjadi aturan di node, dan mem-filter traffic tanpa ikut campur dalam pembentukan jaringan Pod. Flannel tetap menjadi data plane, engine menjadi policy plane.

#Menambahkan Policy Engine di Atas Flannel

#Calico Policy-Only

Calico menyediakan manifest khusus yang hanya men-deploy komponen policy, tanpa mengganti CNI Flannel:

kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.28.0/manifests/calico-policy-only.yaml

Perintah kubectl apply -f calico-policy-only.yaml men-deploy daemon dan komponen Calico yang menegakkan policy, sementara pembentukan jaringan Pod tetap di Flannel.

#Cilium Tanpa Ganti CNI

Cilium juga bisa berperan sebagai policy engine di atas Flannel dalam mode tertentu. Pilihannya kembali ke kenyamanan tim dan fitur yang dibutuhkan. Yang pasti, kedua pendekatan ini menghindari risiko migrasi CNI penuh yang jauh lebih besar.

#Menerapkan NetworkPolicy Pertama

#Policy: Blokir Lintas Namespace

Contoh yang paling umum: sebuah namespace hanya boleh menerima traffic dari namespace tertentu:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-kube-system-only
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system

Policy di atas membuat semua Pod di namespace tersebut hanya bisa menerima traffic dari namespace kube-system. Semua traffic lain akan diblokir oleh policy engine.

kubectl apply -f allow-kube-system-only.yaml

Perintah kubectl apply -f allow-kube-system-only.yaml mendaftarkan policy ke API server. Selanjutnya policy engine yang menegakkannya di setiap node.

#Verifikasi dan Pertimbangan

#Menguji Efek Policy

Deploy dua Pod di namespace berbeda dan uji konektivitasnya. Pod di namespace yang di-policy tidak boleh bisa diakses dari namespace lain:

kubectl run nettest-a --image=busybox --restart=Never -- sleep 3600
kubectl exec -it nettest-a -- ping -c 2 <ip-pod-namespace-lain>

Jika ping gagal setelah policy diterapkan, enforcement bekerja. Tanpa policy engine, ping akan berhasil karena Flannel memang tidak memfilter.

#Hal yang Perlu Diperhatikan

Menambahkan policy engine menambah komponen baru yang harus dirawat: daemon, RBAC, dan metriknya sendiri. Mulailah dari policy yang longgar dan uji dengan teliti sebelum mengetatkan. Kesalahan policy lebih mudah dibuktikan daripada diperbaiki di tengah insiden.

#Memverifikasi Policy Engine

#Pastikan Engine Benar-benar Aktif

Setelah menginstall policy engine, pastikan dia benar-benar menegakkan aturan. Banyak kasus terjadi: policy diterapkan, tetapi tidak ada efek karena engine tidak berjalan atau label namespace tidak cocok. Periksa Pod komponen policy engine di cluster:

kubectl get pods -n calico-system 2>/dev/null || kubectl get pods -n kube-system | grep -i calico

Output dari kubectl get pods -n calico-system menampilkan komponen Calico yang menegakkan policy. Pastikan semua berstatus Running.

#Uji dengan Skenario Nyata

Jangan puas dengan satu uji. Buat skenario tambahan: izinkan traffic dari namespace tertentu saja, lalu blokir namespace lain. Setiap perubahan policy harus diuji di staging sebelum dipakai di produksi, persis seperti praktik GitOps di episode 18.

#Penutup

Episode 14 melengkapi keamanan Flannel dengan policy plane: memahami batas Flannel pada NetworkPolicy, menambahkan Calico policy-only atau Cilium di atasnya, dan menerapkan policy pertama yang benar-benar bekerja.

Inti yang harus dibawa pulang:

• Flannel tidak menerapkan NetworkPolicy karena fokus pada connectivity.
• Policy engine menegakkan policy tanpa mengganti CNI Flannel.
• Calico policy-only bisa diinstall di atas Flannel dengan satu manifest.
• Cilium juga bisa berperan sebagai policy engine pendamping.
• Policy default deny di produksi butuh daftar izin yang matang.
• Verifikasi policy dengan uji konektivitas antar namespace.

Di episode 15 selanjutnya kita akan mengamankan lapisan host: firewall dan host networking — port yang harus dibuka untuk VXLAN, WireGuard, dan IPsec di firewall host maupun cloud, serta cara memilih interface host yang tepat dengan --iface dan menghindari konflik IP.