Top-Level Security: Mengamankan Jaringan dan Infrastruktur Kluster Kafka #

Dalam mengamankan sistem data terdistribusi seperti Apache Kafka, pengamanan di tingkat perangkat lunak (seperti otentikasi klien dan ACL) tidak akan berguna jika pintu gerbang di tingkat infrastruktur jaringan dibiarkan terbuka lebar. Infrastruktur fisik, pengaturan port jaringan, dan pembagian lalu lintas data merupakan pilar-pilar penting dalam Top-Level Security kluster Kafka.

Tanpa adanya pembatasan lalu lintas di tingkat jaringan, penyerang dapat secara langsung memindai port komunikasi internal antar-broker, mencoba menyadap koordinasi metadata kontroler, atau melancarkan serangan Denial of Service (DoS) yang membanjiri port broker hingga mati total.

Artikel ini akan membedah arsitektur pengamanan jaringan kluster Kafka secara mendalam. Kita akan mengulas perbedaan krusial antara parameter listeners dan advertised.listeners, menjelaskan cara mengamankan port koordinasi internal (inter-broker dan KRaft controller quorum), mengonfigurasi pembatasan koneksi (connection rate limiting) untuk menangkis serangan DoS, serta merancang topologi isolasi jaringan menggunakan firewall.

Pembedahan Konfigurasi: Listeners vs Advertised Listeners #

Salah satu sumber kebingungan terbesar bagi administrator Kafka baru adalah kegagalan koneksi klien dengan pesan error TimeoutException atau Connection reset, padahal otentikasi dirasa sudah dikonfigurasi dengan benar. Masalah ini hampir selalu bersumber dari miskonfigurasi parameter listeners dan advertised.listeners di berkas server.properties.

flowchart TD
    Client["Klien Luar (Internet)"] -- "Akses via FQDN: kafka.badri.com:9093" --> Broker["KAFKA BROKER SERVER<br/>- LISTENERS: bind ke internal interface IP (misal, 10.0.1.5:9093)<br/>- ADVERTISED LISTENERS: mengembalikan nama domain publik (misal, kafka.badri.com:9093)"]

1. Listeners (Alamat Bind Internal) #

Parameter listeners mendefinisikan daftar alamat IP interface fisik dan port pada server tempat proses JVM Kafka broker akan mengikat (bind) soket jaringannya.

  • Fungsi: Menentukan port mana yang didengarkan oleh broker secara lokal.
  • Format: protocol://interface_ip:port (Contoh: listeners=PLAINTEXT://10.0.1.5:9092,SSL://10.0.1.5:9093).

2. Advertised Listeners (Metadata Alamat Publik) #

Parameter advertised.listeners mendefinisikan alamat host dan port yang akan ditulis oleh broker ke dalam metadata kluster (dan dilaporkan ke KRaft atau ZooKeeper).

  • Fungsi: Ketika klien pertama kali menghubungi Kafka (melalui salah satu broker penunjuk awal / bootstrap server), broker akan merespons dengan mengembalikan daftar advertised listeners dari seluruh broker di kluster. Klien kemudian menggunakan daftar alamat ini untuk melakukan koneksi aktual ke partisi-partisi pemimpin (partition leaders).
  • Format: protocol://dns_public_name:port (Contoh: advertised.listeners=PLAINTEXT://kafka-node-1.internal:9092,SSL://kafka.badri.com:9093).

Mengapa Pemisahan Ini Sangat Penting untuk Keamanan? #

Jika kita menjalankan Kafka di lingkungan Cloud (seperti AWS), broker biasanya memiliki IP privat (misal: 10.0.1.5) dan IP publik (atau terhubung ke Load Balancer dengan domain kafka.badri.com).

  • Jika kita mengisi advertised.listeners dengan IP privat (10.0.1.5), klien luar dari internet sukses menghubungi bootstrap port, namun saat menerima metadata, klien akan mencoba menghubungi IP privat 10.0.1.5 yang tidak dapat dirute dari internet. Koneksi akan gagal.
  • Sebaliknya, jika kita mengikat listeners langsung ke IP publik 0.0.0.0 (mendengarkan semua interface) tanpa pengamanan port, maka port internal koordinasi antar-broker akan terekspos ke internet luas, mengundang serangan siber.

Mengamankan Komunikasi Inter-Broker dan Quorum KRaft #

Di dalam kluster multi-node, broker-broker harus terus berkomunikasi satu sama lain untuk mereplikasi data partisi, memilih pemimpin baru (leader election), dan menyinkronkan status kluster. Selain itu, pada Kafka modern berbasis KRaft (Kafka Raft), broker-broker harus berkoordinasi secara aktif dengan node kontroler (controller quorum) untuk mengelola metadata.

Lalu lintas koordinasi internal ini sangat sensitif dan tidak boleh dicampur dengan port lalu lintas yang digunakan oleh klien umum.

1. Isolasi Port Inter-Broker #

Kita harus mendedikasikan satu listener khusus yang terenkripsi dan terotentikasi secara eksklusif untuk komunikasi antar-broker.

# Mendefinisikan port internal 9092 untuk koordinasi broker, port 9093 untuk klien
listeners=INTERNAL://:9092,CLIENT_SSL://:9093
advertised.listeners=INTERNAL://kafka-broker-1.internal:9092,CLIENT_SSL://kafka.badri.com:9093

# Menentukan pemetaan protokol keamanan untuk masing-masing nama listener
listener.security.protocol.map=INTERNAL:SSL,CLIENT_SSL:SASL_SSL

# Memaksa komunikasi inter-broker menggunakan listener internal yang terenkripsi SSL
security.inter.broker.protocol=INTERNAL

2. Mengamankan Quorum Kontroler KRaft #

Pada arsitektur KRaft, node kontroler mengelola seluruh status kluster. Menjaga keamanan port kontroler adalah hal yang mutlak karena jika port ini disusupi, penyerang dapat mengambil alih kepemimpinan kluster secara penuh.

Berikut konfigurasi keamanan untuk mengunci port KRaft Quorum (9094) menggunakan protokol SSL di server.properties broker/controller:

# Mendaftarkan port kontroler di listener map
listener.security.protocol.map=INTERNAL:SSL,CLIENT_SSL:SASL_SSL,CONTROLLER:SSL

# Konfigurasi komunikasi quorum kontroler
process.roles=broker,controller
controller.listener.names=CONTROLLER
controller.quorum.voters=[email protected]:9094

# Mengaktifkan verifikasi sertifikat timbal balik (mTLS) pada port kontroler
listener.name.controller.ssl.client.auth=required

Dengan setelan di atas, hanya entitas yang memiliki sertifikat SSL resmi yang ditandatangani oleh root CA internal kita yang diizinkan mengirim perintah koordinasi ke quorum controller.

Proteksi Terhadap Serangan DoS: Connection Rate Limiting & Quotas #

Broker Kafka di produksi sangat rentan terhadap kegagalan akibat kehabisan memori atau port (port exhaustion) jika diserang dengan jutaan koneksi baru secara terus-menerus. Serangan ini bisa berupa serangan Denial of Service (DoS) yang disengaja, atau akibat kebocoran koneksi (connection leaks) dari aplikasi klien yang ditulis secara buruk (misalnya, membuat instansi produser baru pada setiap request HTTP masuk).

Untuk melindungi broker dari skenario di atas, kita dapat mengonfigurasi limitasi di tingkat jaringan:

1. Membatasi Laju Pembuatan Koneksi Baru #

Kafka menyediakan parameter untuk membatasi jumlah koneksi TCP baru yang diizinkan untuk dibuat per detik pada setiap broker. Jika batas ini terlampaui, broker akan menolak koneksi baru untuk melindungi dirinya agar tidak crash.

# Membatasi broker agar hanya menerima maksimal 100 koneksi baru per detik secara global
max.connection.creation.rate=100

# Atau membatasi laju koneksi secara spesifik per listener (misal, listener CLIENT_SSL)
# untuk menjaga agar port INTERNAL inter-broker tetap dapat terhubung dengan lancar
listener.name.client_ssl.max.connection.creation.rate=50

2. Membatasi Total Koneksi Aktif per Alamat IP #

Kita juga dapat membatasi jumlah total koneksi TCP yang sedang aktif dari satu alamat IP klien tertentu agar satu server klien yang rusak tidak menghabiskan seluruh jatah koneksi broker.

# Membatasi satu alamat IP maksimal hanya boleh membuka 50 koneksi aktif sekaligus
max.connections.per.ip=50

3. Menerapkan Bandwidth Quotas untuk Klien #

Selain membatasi jumlah koneksi fisik, kita juga harus mencegah satu klien menyerap seluruh lebar pita (bandwidth) jaringan kluster (misalnya tim analitik melakukan penarikan data masif tanpa batas). Kita dapat menyetel batasan kuota byte per detik untuk principal tertentu secara dinamis:

# Membatasi bandwidth produser 'payment-app' maksimal 10 MB/detik (10485760 bytes/sec)
# dan bandwidth konsumen 'payment-app' maksimal 20 MB/detik (20971520 bytes/sec)
kafka-configs.sh --bootstrap-server localhost:9093 \
  --command-config client-ssl.properties \
  --entity-type users --entity-name payment-app \
  --alter --add-config 'producer_byte_rate=10485760,consumer_byte_rate=20971520'

Isolasi Jaringan Menggunakan Topologi Firewall (Security Groups) #

Pengamanan jaringan terbaik adalah dengan menutup port secara fisik menggunakan sistem keamanan jaringan seperti firewall, AWS Security Groups, atau aturan perutean VPC.

Berikut adalah desain arsitektur port jaringan kluster Kafka yang aman:

flowchart TD
    subgraph PublicNetwork ["1. Jaringan Publik / Aplikasi Klien"]
        AppClients["Aplikasi Produser & Konsumen"]
    end

    subgraph VPC ["2. Virtual Private Cloud (VPC) Privat"]
        subgraph DMZ ["Subnet DMZ / Load Balancer"]
            LB["Network Load Balancer (Port 9093)"]
        end
        
        subgraph PrivateSubnet ["Subnet Internal Terisolasi"]
            Broker1["Kafka Broker 1"]
            Broker2["Kafka Broker 2"]
            Controller1["KRaft Quorum Controller"]
        end
    end

    AppClients -->|Hanya boleh akses Port 9093 via TLS| LB
    LB -->|Rute ke Broker| Broker1 & Broker2
    
    Broker1 <-->|Port 9092: Inter-Broker SSL| Broker2
    Broker1 & Broker2 <-->|Port 9094: Controller Quorum SSL| Controller1
    
    style DMZ stroke:#0288d1,stroke-width:2px
    style PrivateSubnet stroke:#2e7d32,stroke-width:2px

Aturan Emas Konfigurasi Firewall Produksi: #

  1. Port Klien Luar (9093): Hanya dibuka untuk IP server aplikasi klien atau melalui Network Load Balancer (NLB). Jangan pernah mengekspos port ini ke internet luas (0.0.0.0/0) tanpa pengamanan mTLS/SASL.
  2. Port Inter-Broker (9092): Hanya diizinkan untuk berkomunikasi antar alamat IP internal sesama broker di dalam kluster. Blokir akses ke port ini dari luar subnet Kafka.
  3. Port Controller Quorum (9094): Hanya diizinkan untuk komunikasi antara broker dengan node KRaft controller.
  4. Port JMX Monitoring (9999): Port JMX yang digunakan untuk pengumpulan metrik (oleh Prometheus/Grafana) mengirimkan data JVM mentah tanpa otentikasi standar. Port ini wajib dikunci rapat dan hanya diizinkan diakses oleh IP server monitoring Anda.

Pengamanan Port JMX Monitoring & Resolusi DNS Hostname #

Dua celah keamanan infrastruktur yang sering kali luput dari perhatian audit adalah pengamanan port Java Management Extensions (JMX) dan ketergantungan jabat tangan SSL pada resolusi nama domain (DNS).

1. Mengamankan Port JMX Monitoring #

JMX adalah teknologi bawaan Java yang sangat krusial untuk memantau metrik internal Kafka broker (seperti throughput, consumer lag, Under-Replicated Partitions, dan Garbage Collection). Secara default, administrator sering kali mengaktifkan JMX tanpa otentikasi menggunakan properti JVM berikut agar Prometheus dapat mengambil data dengan mudah:

# SANGAT BERBAHAYA DI LINGKUNGAN PRODUKSI
export KAFKA_JMX_OPTS="-Dcom.sun.management.jmxremote \
  -Dcom.sun.management.jmxremote.authenticate=false \
  -Dcom.sun.management.jmxremote.ssl=false \
  -Dcom.sun.management.jmxremote.port=9999"

Risiko Keamanan JMX Tanpa Otentikasi #

JMX berjalan di atas protokol RMI (Remote Method Invocation). Jika port JMX terbuka tanpa pengamanan, penyerang yang memiliki akses ke jaringan lokal tidak hanya dapat membaca metrik internal, tetapi juga dapat mengeksekusi kode jarak jauh (Remote Code Execution / RCE) melalui JVM, memicu siklus Garbage Collection secara paksa untuk melumpuhkan performa broker, atau mematikan proses JVM Kafka secara paksa.

Solusi 1: Mengaktifkan Otentikasi JMX #

Kita wajib mengaktifkan otentikasi dengan membuat berkas konfigurasi kredensial:

  1. Buat berkas /etc/kafka/jmxremote.password (isi dengan username dan password): 
    monitor-user  secureJmxPass123
admin-user    superJmxAdminPass
  2. Buat berkas /etc/kafka/jmxremote.access (isi dengan hak akses): 
    monitor-user  readonly
admin-user    readwrite
  3. Setel izin berkas di Linux agar hanya dapat dibaca oleh user proses Kafka (keamanan OS): 
    chmod 400 /etc/kafka/jmxremote.password
chown kafka:kafka /etc/kafka/jmxremote.password
  4. Perbarui opsi startup JMX Kafka: 
    export KAFKA_JMX_OPTS="-Dcom.sun.management.jmxremote \
  -Dcom.sun.management.jmxremote.port=9999 \
  -Dcom.sun.management.jmxremote.authenticate=true \
  -Dcom.sun.management.jmxremote.password.file=/etc/kafka/jmxremote.password \
  -Dcom.sun.management.jmxremote.access.file=/etc/kafka/jmxremote.access \
  -Dcom.sun.management.jmxremote.ssl=false"

Solusi 2: Menggunakan Prometheus JMX Exporter (Rekomendasi Modern) #

Pendekatan terbaik di lingkungan cloud-native modern adalah dengan tidak membuka port remote JMX sama sekali. Kita dapat memasang Java Agent Prometheus JMX Exporter (jmx_prometheus_javaagent.jar) langsung di dalam JVM Kafka saat startup.

Agen ini akan membaca metrik JMX secara internal di dalam memori JVM dan mengeksposnya sebagai HTTP endpoint teks biasa standar Prometheus pada port tertentu (misalnya port 7071):

# Menjalankan Prometheus exporter secara internal di dalam JVM Kafka
export KAFKA_OPTS="-javaagent:/opt/prometheus/jmx_prometheus_javaagent.jar=7071:/etc/prometheus/kafka-config.yml"

Dengan cara ini, port JMX RMI (9999) tetap mati, dan kita cukup mengamankan port HTTP 7071 menggunakan aturan firewall agar hanya dapat diakses oleh IP server Prometheus scraper.

2. Ketergantungan SSL Terhadap Resolusi DNS Hostname #

Banyak tim infrastruktur mencoba mengonfigurasi advertised.listeners menggunakan IP address (misalnya 192.168.1.10) untuk menghindari kebutuhan pengelolaan server DNS internal. Namun, jika kita menggunakan enkripsi SSL/TLS, penggunaan IP address ini adalah resep kegagalan koneksi.

Mengapa? #

Protokol SSL/TLS melakukan verifikasi apakah nama host (hostname) yang dihubungi oleh klien cocok dengan kolom Subject atau Subject Alternative Name (SAN) yang tertulis di dalam sertifikat digital yang disodorkan oleh broker.

  • Jika klien menghubungi 192.168.1.10, sementara sertifikat broker dibuat atas nama CN=kafka-broker-1.internal, maka pustaka keamanan klien (misalnya Java SSL engine) akan membatalkan jabat tangan karena ketidakcocokan identitas host (endpoint identification failure).
  • Membuat sertifikat SSL berbasis IP address (menggunakan field SAN IP) sangat tidak fleksibel di lingkungan dinamis seperti cloud atau Kubernetes karena alamat IP broker dapat berubah sewaktu-waktu saat node di-scale atau dipindahkan.

Solusi #

Kita wajib menggunakan alamat domain FQDN (Fully Qualified Domain Name) secara konsisten pada konfigurasi advertised.listeners (misal: kafka-broker-1.internal) dan memastikan server DNS internal (atau CoreDNS di Kubernetes) menyelesaikan nama tersebut ke alamat IP fisik broker yang tepat dari sudut pandang klien dan broker.

Ringkasan #

  • Listeners vs Advertised — Listeners mengatur port lokal yang diikat (bind), sedangkan Advertised Listeners mengatur alamat DNS yang disodorkan kepada klien untuk dikoneksikan.
  • Isolasi Port — Selalu pisahkan port lalu lintas klien (CLIENT_SSL / 9093) dengan port komunikasi koordinasi antar-broker (INTERNAL / 9092).
  • KRaft Security — Port quorum KRaft (9094) adalah jantung metadata kluster. Amankan port ini menggunakan mTLS timbal balik yang ketat.
  • Proteksi DoS — Aktifkan limitasi pembuatan koneksi baru per detik (max.connection.creation.rate) untuk melindungi broker dari kebanjiran koneksi akibat client leaks.
  • Firewall VPC — Terapkan aturan firewall ketat untuk menutup seluruh port internal (JMX, inter-broker, KRaft) dari akses jaringan luar.

← Sebelumnya: Access Control Lists (ACL)   Berikutnya: Common Security Mistakes →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact