Belajar Iptables - Automation & IaC (Ansible, Docker, Kubernetes)

#Pendahuluan

Aturan firewall yang diketik manual adalah bom waktu: tidak konsisten antar mesin, tidak terdokumentasi di mana pun, dan hilang begitu ada yang "memperbaiki" sesuatu. Episode 21 menutup lubang itu dengan Infrastructure as Code (IaC) — firewall sebagai konfigurasi yang bisa di-review, diuji, dan direproduksi dari satu sumber kebenaran.

Tapi dunia IaC lebih luas dari Ansible. Di episode ini kalian juga melihat bagaimana teknologi yang menggerakkan modernisasi — Docker dan Kubernetes — ternyata berdiri di atas iptables. Memahami mereka berarti memahami iptables di ekosistem nyata, bukan hanya di server kosong.

#Ansible: Aturan Idempotent

Modul ansible.builtin.iptables mengelola satu aturan per task secara idempotent — jalankan 10 kali, hasilnya sama:

- name: Buka port HTTPS
  ansible.builtin.iptables:
    chain: INPUT
    protocol: tcp
    destination_port: "443"
    jump: ACCEPT
    comment: "HTTPS publik"

Kekuatan idempotensi terlihat saat perintah dijalankan ulang: modul membandingkan state yang diinginkan dengan yang ada di mesin, dan tidak melakukan apa-apa jika aturan sudah terpasang. Tidak ada duplikat, tidak ada kejutan.

Contoh dengan source dan state:

- name: Blokir IP penyerang
  ansible.builtin.iptables:
    chain: INPUT
    source: "203.0.113.7"
    jump: DROP
    state: present
    comment: "Ban manual - lihat ticket SEC-123"

#Mengelola Seluruh Ruleset: iptables_state

Untuk mengelola ruleset secara menyeluruh — bukan satu-satu — gunakan modul iptables_state dari collection community.general. Modul ini me-restore sebuah file ruleset utuh dan membandingkannya dengan state aktif:

- name: Terapkan seluruh ruleset
  community.general.iptables_state:
    path: "{{ playbook_dir }}/files/rules.v4"

Pendekatan full-file lebih cocok untuk ruleset produksi yang kompleks (episode 17): satu file = satu sumber kebenaran, dan drift langsung terlihat saat iptables-save tidak cocok dengan file.

#Menghindari Race dengan Handler

Aturan firewall sering berpasangan dengan restart layanan. Pola handler membuat urutan pasti:

- name: Siapkan ruleset
  community.general.iptables_state:
    path: "{{ playbook_dir }}/files/rules.v4"
  notify: reload firewall
 
handlers:
  - name: reload firewall
    ansible.builtin.command: iptables-restore < /etc/iptables/rules.v4

#Docker dan iptables

Docker membangun jaringan kontainernya di atas iptables — chain DOCKER, DOCKER-USER, dan NAT untuk port publishing:

sudo iptables -L DOCKER -n -v
sudo iptables -L DOCKER-USER -n -v
sudo iptables -t nat -L POSTROUTING -n -v | head

Dua konsekuensi operasional yang wajib kalian tahu:

1. Jangan menulis ke chain DOCKER — Docker akan menimpa saat restart. Kebijakan kustom ditulis ke DOCKER-USER (ingat episode 18).
2. --publish = aturan nat+filter otomatis — port yang di-publish diizinkan di FORWARD oleh Docker sendiri.

Untuk kendali penuh, Docker bisa memakai iptables: false:

{
  "iptables": false
}

Dengan mode ini Docker tidak menyentuh iptables sama sekali — kalian mengelola semua aturan sendiri, termasuk publishing port secara manual. Lebih transparan, tapi kalian memikul semua tanggung jawabnya.

#Kubernetes dan kube-proxy

Di cluster Kubernetes, kube-proxy menerjemahkan Service dan LoadBalancer menjadi aturan jaringan. Mode paling umum:

• iptables mode — kube-proxy menulis aturan iptables untuk setiap Service (yang bisa mencapai ribuan aturan).
• ipvs mode — memakai kernel IPVS (LVS) untuk load balancing kernel-level, lebih scalable dari iptables untuk cluster besar.

kubectl -n kube-system get cm kube-proxy -o yaml | grep -i mode

sudo iptables -L KUBE-SERVICES -n -v | head

Perlu dipahami: memanipulasi chain KUBE-* secara manual itu sia-sia — kube-proxy akan menimpanya. Kebijakan network policy di Kubernetes dikelola lewat CNI (Calico, Cilium) yang menulis aturannya sendiri ke iptables/ebpf. Inilah ekosistem lengkap tempat iptables masih menjadi fondasi.

#firewalld dan nftables: Default RHEL

Sebagai penutup peta ekosistem: distro modern sudah memilih default masing-masing.

• RHEL 8/9 & Fedora: firewalld sebagai manajer — di RHEL 9 berbasis nftables, dengan nft sebagai engine di balik layar.
• Debian/Ubuntu: iptables (backend nft) klasik + ufw sebagai frontend opsional.
• Arch: paket iptables-nft dan nftables berdampingan; kalian memilih.

Bagi kalian yang bekerja di RHEL, mengenal firewall-cmd setara dengan mengenal iptables: keduanya adalah bahasa untuk satu mesin yang sama. Perbandingan lengkap empat tool ini ada di episode 22.

#Workflow IaC yang Sehat

Merangkum praktik terbaik automation firewall:

• Satu sumber kebenaran: file ruleset di git (episode 17).
• Deploy lewat Ansible/CI — bukan login manual.
• Verifikasi drift: bandingkan iptables-save dengan file.
• Documentation: modul comment di setiap aturan.

#Penutup

Inti yang harus dibawa pulang:

• ansible.builtin.iptables idempotent per-aturan; community.general.iptables_state untuk file utuh.
• Docker: jangan sentuh chain DOCKER; kebijakan kustom masuk DOCKER-USER; ada opsi iptables: false.
• kube-proxy menulis iptables untuk Service (mode iptables) atau memakai IPVS (mode ipvs).
• RHEL modern = firewalld di atas nftables; pilih satu "bahasa" per mesin.

Di episode 22 — episode terakhir — kita akan membahas perbandingan ekosistem & refleksi akhir: membandingkan iptables, nftables, UFW, dan firewalld secara mendalam, menentukan kapan memilih yang mana, merekap seluruh 22 episode, dan menutup dengan checklist production-ready beserta sumber-sumber resmi untuk lanjut belajar. Sampai jumpa di episode 22!