Belajar Flannel - Security & Hardening

#Pendahuluan

Setiap CNI punya model keamanan sendiri. Flannel dengan jujur memilih fokus pada connectivity: menghubungkan Pod dengan cepat dan andal. Konsekuensinya, keamanan lapisan traffic antar node harus diusahakan secara eksplisit.

Episode 13 membedah model keamanan Flannel, lalu membahas hardening dari dua sisi: enkripsi traffic antar node lewat backend WireGuard dan IPsec, serta pengamanan DaemonSet Flannel itu sendiri.

#Model Keamanan Flannel

#Connectivity, Bukan Policy

Flannel menangani lapisan jaringan dengan satu tujuan: membuat Pod saling terhubung. Dia tidak menegakkan NetworkPolicy dan tidak menawarkan isolasi antar workload. Ini bukan kekurangan, melainkan keputusan desain yang membuat Flannel tetap sederhana.

Konsekuensinya jelas: security di atas Flannel harus dibangun dari komponen lain. NetworkPolicy bisa ditambahkan lewat policy engine seperti Calico policy-only atau Cilium, yang akan dibahas di episode 14. Segmentasi dan enkripsi traffic antar node diurus lewat backend, yang dibahas di episode ini.

#Threat Model Flannel

Threat model Flannel mencakup: traffic antar node yang bisa disadap di jaringan host, ConfigMap yang bisa diubah pihak tak berizin, dan image flanneld yang bisa membawa versi lama dengan celah. Ketiga titik ini yang harus di-hardening.

#Enkripsi Backend: WireGuard

#Traffic Antar Node Terenkripsi

WireGuard mengenkripsi semua traffic antara interface tunnel antar node. Jika kalian berjalan di jaringan yang tidak bisa dipercaya, misalnya provider network bersama, backend ini membuat traffic Pod tidak bisa dibaca pihak lain.

net-conf.json: |
  {
    "Network": "10.244.0.0/16",
    "Backend": {
      "Type": "wireguard",
      "Port": 51820
    }
  }

Dengan Type: wireguard, setiap node membangun tunnel WireGuard ke node lain. Port UDP 51820 harus dibuka di firewall, detailnya di episode 15.

#Verifikasi Tunnel

Untuk memastikan tunnel terbentuk, periksa interface WireGuard di node:

ip link show

Output dari ip link show menampilkan interface wg0 atau sejenisnya. Keberadaannya menandakan backend WireGuard aktif di node tersebut.

#Enkripsi Backend: IPsec

#Alternatif Enterprise

IPsec adalah standar yang lebih lama dan banyak dipakai di lingkungan enterprise yang sudah punya kebijakan IPsec. Flannel mengintegrasikannya melalui strongSwan, dengan IKEv2 untuk negosiasi kunci.

net-conf.json: |
  {
    "Network": "10.244.0.0/16",
    "Backend": {
      "Type": "ipsec"
    }
  }

Backend IPsec membutuhkan strongSwan dan modul kernel yang sesuai tersedia di node. Port yang dipakai adalah 500 dan 4500 untuk IKE dan NAT traversal.

#WireGuard vs IPsec

WireGuard lebih sederhana, lebih cepat, dan berbasis kernel modern. IPsec lebih diterima di lingkungan dengan kebijakan baku dan audit yang menuntut standar tertentu. Pilihan bergantung pada kebijakan organisasi, bukan performa semata.

#Hardening DaemonSet

#Image Pinning dan Update

Selalu pin image flanneld ke versi spesifik dan perbarui secara berkala. Image tag yang melayang seperti latest bisa membawa perubahan tak terduga saat DaemonSet di-restart. Gunakan tag versi penuh:

kubectl get ds -n kube-flannel kube-flannel-ds -o jsonpath='{.spec.template.spec.containers[0].image}'

Output dari kubectl get ds -n kube-flannel kube-flannel-ds menunjukkan image saat ini. Pastikan berupa tag versi seperti docker.io/flannel/flannel:v0.28.8, bukan latest.

#Batasi Akses ConfigMap

CVE-2026-32241 mengingatkan kita bahwa konfigurasi Flannel bisa menjadi vektor serangan. Batasi siapa yang bisa mengubah ConfigMap kube-flannel-cfg melalui RBAC. Hanya tim platform yang seharusnya bisa mengubah backend dan argumen flanneld.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: flannel-admin
  namespace: kube-flannel
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list", "watch", "update"]

Role di atas memberi akses update ConfigMap hanya kepada entitas yang memang ditugaskan mengelola Flannel.

#Security Context yang Wajar

flanneld membutuhkan privilege tertentu karena mengelola jaringan host, tetapi jangan berikan hak yang tidak perlu. Batasi mount, gunakan readOnlyRootFilesystem di mana memungkinkan, dan jangan menjalankan container sebagai root kecuali diperlukan oleh cara kerja flanneld di node.

#Penutup

Episode 13 membingkai keamanan Flannel dengan jujur: Flannel mengurus connectivity, dan kalian yang mengurus keamanan traffic antar node lewat backend enkripsi serta hardening DaemonSet.

Inti yang harus dibawa pulang:

• Flannel fokus pada connectivity dan tidak menerapkan NetworkPolicy.
• WireGuard mengenkripsi traffic antar node lewat tunnel UDP port 51820.
• IPsec memakai strongSwan dengan port IKE 500 dan 4500.
• Pin image flanneld ke versi penuh, bukan tag latest.
• Batasi akses edit ConfigMap kube-flannel-cfg dengan RBAC.
• CVE-2026-32241 mengingatkan pentingnya update dan pembatasan konfigurasi.

Di episode 14 selanjutnya kita akan melengkapi keamanan: network policy ecosystem — mengapa Flannel tidak menerapkan NetworkPolicy, serta cara menambahkan policy engine seperti Calico policy-only atau Cilium di atas Flannel tanpa mengganti CNI.