Belajar Apache Kafka - Encryption & TLS/SSL

#Pendahuluan

SASL mengautentikasi identitas, tetapi data yang lewat tetap bisa dibaca oleh pihak yang mengintip jaringan. Untuk itu Kafka memakai TLS/SSL: protokol enkripsi yang menjaga kerahasiaan dan integritas data selama transit antara klien dan broker, serta antar broker.

Episode 18 ini akan membawa kalian menyiapkan infrastruktur sertifikat — CA, sertifikat broker dan klien, keystore serta truststore — mengonfigurasi TLS di kedua sisi, memahami enkripsi in-transit dan at-rest, serta praktik pengelolaan sertifikat seperti rotasi dan monitoring kedaluwarsa.

#Setup TLS/SSL

#Pembuatan CA dan Sertifikat

Alur standar: buat Certificate Authority (CA), lalu terbitkan sertifikat untuk setiap broker dan klien yang ditandatangani CA tersebut. Menggunakan keytool yang tersedia di JDK:

keytool -genkeypair -alias ca -keyalg RSA -validity 3650 \
  -keystore ca.jks -ext "SAN=dns:kafka-1.internal"
 
keytool -genkeypair -alias kafka-broker -keyalg RSA -validity 825 \
  -keystore broker.jks -ext "SAN=dns:kafka-1.internal"
 
keytool -certreq -alias kafka-broker -keystore broker.jks -file broker.csr
keytool -gencert -alias ca -keystore ca.jks -infile broker.csr -outfile broker.cer
keytool -importcert -alias ca -keystore broker.jks -file ca.cer
keytool -importcert -alias kafka-broker -keystore broker.jks -file broker.cer

keytool -genkeypair membuat pasangan kunci, dan keytool -gencert menandatangani CSR broker dengan CA. Alias CA dan broker disimpan dalam keystore terpisah.

#Keystore dan Truststore

Dua konsep penyimpanan kunci:

• Keystore: menyimpan kunci privat dan sertifikat milik sendiri. Broker memakai broker.jks.
• Truststore: menyimpan sertifikat pihak yang dipercaya — di sini CA. Broker dan klien memakai truststore untuk memverifikasi sertifikat lawan bicara.

Buat truststore untuk semua node dengan mengimpor CA:

keytool -importcert -alias ca -keystore truststore.jks -file ca.cer

keytool -importcert -alias ca menambahkan CA ke truststore. Broker membutuhkan keystore untuk menunjukkan sertifikatnya dan truststore untuk memverifikasi klien; klien membutuhkan truststore (dan opsional keystore jika mutual TLS).

#Konfigurasi TLS

#Sisi Broker

Aktifkan listener SSL di server.properties:

listeners=SASL_SSL://:9093
ssl.keystore.location=/etc/kafka/secrets/broker.jks
ssl.keystore.password=${file:/etc/kafka/secrets/pass}
ssl.key.password=${file:/etc/kafka/secrets/pass}
ssl.truststore.location=/etc/kafka/secrets/truststore.jks
ssl.truststore.password=${file:/etc/kafka/secrets/pass}
ssl.client.auth=required

ssl.keystore.location dan ssl.truststore.location menunjuk penyimpanan kunci; password dibaca dari file agar tidak tertulis di konfigurasi. ssl.client.auth=required mengaktifkan mutual TLS — klien juga harus menunjukkan sertifikat valid.

#Sisi Klien

Klien memverifikasi broker lewat truststore:

security.protocol=SASL_SSL
ssl.truststore.location=/etc/ssl/certs/kafka/truststore.jks
ssl.truststore.password=changeit

security.protocol=SASL_SSL mengaktifkan enkripsi (plus SASL jika dikombinasikan). Dengan mutual TLS, klien juga menambahkan ssl.keystore.location miliknya.

#Enkripsi Data

#In Transit

TLS mengenkripsi semua komunikasi: klien-ke-broker dan inter-broker. Setiap byte yang lewat jaringan — record, metadata, offset, kontrol — diamankan. Inilah dasar dari semua komunikasi produksi yang aman. Tanpa TLS, data sensitif bisa disadap di jalur jaringan atau di load balancer.

#At Rest

TLS hanya melindungi data saat bergerak. Untuk data yang tersimpan di disk broker, gunakan enkripsi at-rest:

• Filesystem encryption: LUKS atau dm-crypt pada volume data.
• Cloud-native: AWS EBS encryption, Google Persistent Disk encryption, Azure Disk Encryption — diaktifkan sekali dan otomatis.
• Enkripsi di sisi aplikasi untuk data paling sensitif, dengan key management terpusat (KMS).

Enkripsi at-rest bukan pengganti TLS; keduanya menangani ancaman yang berbeda.

#Pengelolaan Sertifikat

#Rotasi Sertifikat

Sertifikat memiliki masa berlaku terbatas. Rotasi berkala mencegah penggunaan sertifikat yang telah bocor atau kedaluwarsa. Proses rotasi broker: terbitkan sertifikat baru, perbarui keystore, lalu lakukan rolling restart broker satu per satu. Untuk klien, perbarui truststore sebelum CA baru berlaku.

#Monitoring Kedaluwarsa

Kegagalan TLS yang paling umum adalah sertifikat kedaluwarsa secara tak terduga. Otomatisasi adalah kuncinya:

• Pantau tanggal kedaluwarsa semua sertifikat (CA, broker, klien) dan kirim alert jauh sebelum deadline.
• Pakai sertifikat berumur pendek (misalnya 30-90 hari) yang diperbarui otomatis oleh infrastruktur seperti cert-manager atau Vault PKI.
• Uji proses rotasi secara berkala dalam staging agar tidak ada kejutan di produksi.

#Penutup

Di episode 18 ini kalian sudah memahami pembuatan CA dan sertifikat dengan keytool, perbedaan keystore dan truststore, konfigurasi TLS di broker dan klien, enkripsi data in-transit dan at-rest, serta pengelolaan sertifikat dengan rotasi dan monitoring.

Inti yang harus dibawa pulang:

• TLS melindungi data saat transit; keystore memegang identitas, truststore memegang pihak terpercaya.
• ssl.client.auth=required mengaktifkan mutual TLS.
• Jangan menulis password keystore langsung di konfigurasi — gunakan file rahasia.
• Enkripsi at-rest (EBS, LUKS) menangani data di disk.
• Sertifikat kedaluwarsa adalah penyebab outage TLS paling umum.
• Otomatiskan rotasi dan monitoring kedaluwarsa sertifikat.

Di episode 19 selanjutnya kita akan membahas quotas dan rate limiting — membatasi tulis dan baca per user atau client-id. Kalian akan belajar jenis quota, konfigurasi di level user dan client-id, mekanisme throttling, serta penggunaan untuk multi-tenancy dan SLA.