Belajar MetalLB - Security & Access Control

#Pendahuluan

MetalLB adalah komponen yang luar biasa sensitif: dia yang memutuskan IP mana yang dipakai, route apa yang diiklankan ke jaringan, dan siapa yang meng-announce IP. Kompromi pada MetalLB bisa berarti routing hijacking di dalam jaringan kalian sendiri. Karena itu, security & access control bukan opsi — ini keharusan untuk cluster yang serius.

Episode 14 membahas empat lapisan keamanan MetalLB: permission RBAC untuk controller dan speaker, pengerasan namespace, pembatasan akses ke port management dan health check, serta proteksi konfigurasi agar hanya orang yang berwenang yang bisa mengubah perilaku jaringan cluster.

#RBAC untuk Controller dan Speaker

#Permission Minimum yang Dipakai

Setiap komponen MetalLB memiliki akun service dan Role sendiri dengan permission yang prinsipnya least privilege. Controller butuh akses ke Service, Endpoints, dan CRD MetalLB; speaker butuh akses ke node dan Service; keduanya tidak perlu akses admin cluster.

Lihat permission yang sudah terpasang:

kubectl get clusterrole | grep -i metallb
kubectl describe clusterrole metallb-system:controller
kubectl describe clusterrole metallb-system:speaker

kubectl describe clusterrole metallb-system:controller menampilkan daftar permission resource yang bisa dibaca atau dimodifikasi oleh controller. kubectl describe clusterrole metallb-system:speaker menampilkan hal serupa untuk speaker.

#Verifikasi Akun Service

Pastikan pod berjalan dengan ServiceAccount yang benar, bukan default:

kubectl get pods -n metallb-system -o jsonpath='{.items[*].spec.serviceAccountName}'
kubectl auth can-i --list -n metallb-system

Output kubectl get pods -n metallb-system -o jsonpath='{.items[*].spec.serviceAccountName}' harus menampilkan nama akun service khusus MetalLB. Jika muncul default, ada masalah konfigurasi yang harus segera diperbaiki.

#Hardening Namespace

#Batasi Siapa yang Bisa Menyentuh Namespace

Namespace metallb-system harus menjadi area terkunci. Siapapun yang bisa membuat atau mengubah IPAddressPool, BGPPeer, dan advertisement bisa mengubah perilaku jaringan cluster. Gunakan RBAC untuk membatasi:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: metallb-config-admin
  namespace: metallb-system
rules:
  - apiGroups:
      - metallb.io
    resources:
      - ipaddresspools
      - l2advertisements
      - bgpadvertisements
      - bgppeers
    verbs:
      - get
      - list
      - watch
      - create
      - update
      - delete

Role metallb-config-admin ini memberi izin penuh untuk CRD MetalLB hanya di namespace metallb-system, tanpa izin lain. Gabungkan dengan RoleBinding ke tim yang bertanggung jawab — misalnya platform engineering — dan jangan berikan akses ini kepada developer biasa.

#Prinsip: Namai Sesuai Fungsinya

Praktik yang dianjurkan di lingkungan bersama adalah memisahkan pengelolaan pool per tim. Misalnya tim A hanya bisa mengelola pool tim-a-pool, sementara tim B hanya tim-b-pool, lewat kombinasi Role dan ResourceName di RBAC.

#Network Security: Port Management dan Health Check

#Port yang Terbuka di Pod

Speaker dan controller mengekspos endpoint di port tertentu:

• 7472: metric Prometheus dan endpoint health check.
• 8080: endpoint health check bawaan (sering dipakai oleh probe liveness/readiness).

Port-port ini seharusnya hanya bisa diakses dari dalam cluster, bukan dari internet. Batasi dengan NetworkPolicy:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: metallb-metrics-internal
  namespace: metallb-system
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: metallb
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: monitoring
      ports:
        - protocol: TCP
          port: 7472

NetworkPolicy ini hanya mengizinkan traffic ke port 7472 dari namespace monitoring (tempat Prometheus). Semua sumber lain diblokir. Jika CNI kalian mendukung NetworkPolicy (Calico, Cilium), kebijakan ini sangat efektif.

#Health Check dan Liveness Probe

Health check MetalLB dijalankan lewat HTTP probe. Pastikan probe ini berjalan dan menandai komponen yang tidak sehat dengan benar:

kubectl get deployment metallb-controller -n metallb-system -o yaml | grep -A5 livenessProbe

kubectl get deployment metallb-controller -n metallb-system -o yaml | grep -A5 livenessProbe menampilkan konfigurasi liveness probe controller. Probe yang salah bisa menyebabkan pod di-restart terus-menerus di produksi — penting untuk memeriksanya saat tuning.

#Proteksi Konfigurasi

#Webhook sebagai Penjaga Gerbang

Seperti yang sudah kita bahas di episode 10, validating webhook mencegah konfigurasi yang salah masuk. Namun webhook tidak mencegah orang yang berwenang membuat perubahan yang tidak diinginkan. Lapisan kedua adalah GitOps: simpan semua konfigurasi MetalLB di repository dan terapkan lewat pipeline, bukan dengan kubectl apply manual dari mesin personal.

#Audit dan Alert

• Pantau perubahan CRD MetalLB dengan audit log Kubernetes.
• Alert ketika IPAddressPool, BGPPeer, atau advertisement dihapus atau dimodifikasi.
• Batasi siapa yang bisa delete resource MetalLB — penghapusan pool yang salah bisa memutus Service.

#Penutup

Episode 14 menuntaskan security & access control: RBAC minimal untuk controller dan speaker, pengerasan namespace, NetworkPolicy untuk port management dan health check, serta proteksi konfigurasi lewat GitOps dan audit.

Inti yang harus dibawa pulang:

• Controller dan speaker berjalan dengan ServiceAccount dan Role sendiri.
• kubectl auth can-i --list -n metallb-system untuk memeriksa permission.
• Namespace metallb-system harus dibatasi hanya untuk yang berwenang.
• Port 7472 hanya boleh diakses sumber yang sah (Prometheus).
• NetworkPolicy mengunci akses ke endpoint metric dan health check.
• GitOps dan audit adalah lapisan proteksi terakhir konfigurasi MetalLB.

Di episode 15 selanjutnya kita akan membahas high availability & failover — leader election dan failover pada Layer 2, failover time serta perilaku ARP, lalu high availability BGP dengan ECMP multi-node, path monitoring, dan penanganan kegagalan peer.