Hardening Cluster Kubernetes: Isolasi Network Pod via Cilium eBPF

Latar Belakang: Bahaya Lateral Movement pada Flat Network Default Kubernetes

Network Kubernetes default pakai model flat. Setiap pod terima IP unik, bebas hubungi pod lain di seluruh namespace tanpa filter. Kondisi ini buka celah keamanan.

Skenario serangan lateral movement: Penyerang eksploitasi Remote Code Execution (RCE) di pod frontend. Dari pod terkompromi, penyerang scan port internal, akses database PostgreSQL, atau panggil API internal terproteksi. NetworkPolicy bawaan Kubernetes pakai iptables. Engine iptables evaluasi rule secara sekuensial O(N). Ribuan pod dan rule sebabkan latency melonjak dan CPU overhead tinggi.

Cilium selesaikan masalah ini pakai Extended Berkeley Packet Filter (eBPF). eBPF inject bytecode langsung ke Linux Kernel. Packet filter jalan di level socket dan network interface tanpa lewati stack iptables. Lookup rule pakai BPF Maps dengan kompleksitas O(1).

Persiapan Environment dan Prasyarat Cluster

Prasyarat deploy Cilium CNI:

• Cluster Kubernetes v1.26+
• Linux Kernel v5.4+ di node worker (direkomendasikan Kernel v5.15+ untuk fitur eBPF L7 penuh)
• Akses kubectl dengan hak cluster-admin
• Cilium CLI terpasang di workstation lokal

Langkah 1: Deploy Cilium CNI dengan Kube-Proxy Replacement

Pasang Cilium CNI ganti CNI standar dan kube-proxy. Mode kube-proxy replacement maksimalkan performa eBPF untuk routing dan service load balancing.

# Unduh Cilium CLI
CILIUM_CLI_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt)
CLI_ARCH=amd64
if [ "$(uname -m)" = "aarch64" ]; then CLI_ARCH=arm64; fi
curl -L --fail --remote-name "https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-linux-${CLI_ARCH}.tar.gz"
tar xzvfAZ cilium-linux-${CLI_ARCH}.tar.gz -C /usr/local/bin
rm cilium-linux-${CLI_ARCH}.tar.gz

# Deploy Cilium ke cluster Kubernetes
cilium install \
  --version 1.15.1 \
  --set kubeProxyReplacement=true \
  --set hubble.enabled=true \
  --set hubble.ui.enabled=true \
  --set hubble.relay.enabled=true

Verifikasi status instalasi Cilium:

cilium status --wait

Langkah 2: Konfigurasi Isolasi Pod (CiliumNetworkPolicy L3-L7)

Arsitektur aplikasi di namespace production:

• frontend: Terima traffic publik.
• backend-api: Dipanggil frontend, akses database.
• database: PostgreSQL, khusus diakses backend-api di port 5432.

1. Terapkan Default Deny All Policy

Prinsip Zero Trust: Blokir seluruh traffic ingress dan egress secara default di namespace target.

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  endpointSelector: {}
  ingress:
  - {}
  egress:
  - {}

2. Konfigurasi Policy Layer 3 & Layer 4 (Isolasi Database)

Izinkan pod app=backend-api hubungi pod app=database pada TCP port 5432. Pod frontend dilarang akses database secara langsung.

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: allow-backend-to-db
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: database
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: backend-api
    toPorts:
    - ports:
      - port: "5432"
        protocol: TCP

3. Konfigurasi Policy Layer 7 (HTTP REST & FQDN Filtering)

Cilium inspect payload L7 HTTP. Batasi backend-api hanya boleh akses HTTP GET path /api/v1/metrics pada service payment api.payment-gateway.com via port 443/80.

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: allow-backend-to-payment-gateway
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: backend-api
  egress:
  - toFQDNs:
    - matchName: "api.payment-gateway.com"
    toPorts:
    - ports:
      - port: "80"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/api/v1/metrics"

Langkah 3: Simulasi dan Pengujian Lateral Movement

Uji efektivitas rule policy dengan simulasi pod frontend terkompromi.

Uji akses langsung dari pod frontend ke database (Harus FAIL / TIMEOUT):

kubectl exec -n production deploy/frontend -- nc -zvw3 database 5432

Hasil output terminal:

nc: connect to database (10.244.1.45) port 5432 (tcp) timed out

Uji koneksi sah dari pod backend-api ke database (Harus SUCCESS):

kubectl exec -n production deploy/backend-api -- nc -zvw3 database 5432

Hasil output terminal:

database (10.244.1.45:5432) open

Uji akses endpoint L7 HTTP terlarang dari backend-api (Harus BLOCKED / 403 Access Denied):

kubectl exec -n production deploy/backend-api -- curl -X POST http://api.payment-gateway.com/api/v1/charge

Traffic POST diblokir proxy L7 Cilium Envoy internal karena policy hanya izinkan method GET.

Langkah 4: Observability & Troubleshooting via Hubble CLI & UI

Hubble berikan visibilitas real-time traffic terizinkan (FORWARDED) atau terblokir (DROPPED).

Monitoring Paket via Hubble CLI

Jalankan Hubble observe untuk filter traffic terblokir policy di namespace production:

# Aktifkan port forward Hubble Relay
cilium hubble port-forward &

# Observe traffic dropped secara realtime
hubble observe --namespace production --verdict DROPPED --follow

Output log Hubble CLI:

TIMESTAMP            SOURCE                           DESTINATION                      TYPE      VERDICT
Mar 30 10:14:22.102  production/frontend-7d4b-x9z2  production/database-58f8-b2k1   POLICY    DROPPED (Policy denied by CiliumNetworkPolicy default-deny-all)

Visualisasi Flow Traffic via Hubble UI

Jalankan Hubble UI:

cilium hubble ui

Buka http://localhost:12000 di browser. Hubble UI tampilkan Service Map. Garis merah indikasi traffic terblokir, garis hijau indikasi traffic terizinkan.

Best Practice Tuning Network Policy Model Zero-Trust

• Gunakan Audit Mode sebelum Enforce: Tambah anotasi cilium.io/policy-mode: audit pada manifest policy. Paket melanggar tetap diizinkan tetapi dicatat di log Hubble. Ini cegah downtime akibat salah konfigurasi rule.
• Gunakan Namespace Isolation: Pakai CiliumClusterwideNetworkPolicy untuk policy global (contoh: blokir akses metadata cloud 169.254.169.254).
• Manfaatkan Identity-based Policy: Cilium beri Security Identity ke setiap pod berdasarkan label. Evaluasi kebijakan berbasis ID, bukan IP address yang sering berubah.

Performa: eBPF vs iptables Dalam Skala Besar

Perbandingan arsitektur pemrosesan paket iptables standar vs Cilium eBPF:

• iptables (Evaluasi Sekuensial O(N)): Paket data lewati daftar aturan netfilter satu per satu dari atas ke bawah. Cluster dengan 5.000 pod dan 20.000 rule sebabkan latensi pemrosesan naik drastis. CPU node terbeban untuk proses string matching di kernel space.
• Cilium eBPF (Hash Table Lookup O(1)): Bytecode eBPF simpan aturan pada BPF Maps (struktur data hash table di kernel). Paket masuk dievaluasi via lookup instan O(1) berbasis Security Identity. Latensi konstan < 0.1ms tanpa terpengaruh jumlah pod atau rule.

Rekomendasi Pipeline Audit & Otomasi Policy (GitOps)

Integrasikan pengujian CiliumNetworkPolicy ke pipeline CI/CD:

• Linting & Validation: Jalankan cilium policy validate -f policy.yaml pada step pull request CI.
• GitOps Sync: Simpan manifest CiliumNetworkPolicy di repository Git. Gunakan ArgoCD atau FluxCD untuk sinkronisasi otomatis ke cluster.
• Automated Matrix Test: Tambah stage automated integration test di pipeline CI untuk verifikasi ingress/egress antar service sebelum rilis image aplikasi.

Kesimpulan

Isolasi traffic Kubernetes berpatokan pada prinsip Zero Trust Network. Cilium eBPF hapus batasan performa iptables dan perkuat keamanan cluster. Kombinasi filter Layer 3 hingga Layer 7 serta visibilitas real-time Hubble tutup celah lateral movement penyerang di infrastruktur container.