Ikhtisar keamanan

Cluster Kafka yang dijalankan tanpa pengaturan keamanan menerima koneksi apa pun dan mengizinkan operasi apa pun, keadaan yang memadai untuk pengembangan lokal tetapi tidak untuk cluster yang digunakan bersama. Topik ini memberikan ikhtisar tiga lapisan keamanan Kafka, yaitu enkripsi SSL pada listener, autentikasi SASL yang memeriksa identitas klien, dan otorisasi ACL yang membatasi operasi per identitas. Setiap lapisan dibahas beserta contoh berkas konfigurasi atau perintahnya, lalu ditutup dengan perilakunya pada broker lokal dan layanan cloud. Setelah membaca topik ini, kombinasi lapisan yang dipasang pada sebuah cluster dapat dirancang dengan alasan yang jelas.

Tiga lapisan keamanan#

Kafka menyusun keamanan koneksi klien menjadi tiga lapisan yang bekerja berurutan pada listener. Enkripsi SSL melindungi byte yang berjalan di jaringan agar tidak terbaca oleh pihak lain, autentikasi SASL memeriksa identitas klien yang terhubung, dan otorisasi ACL menentukan operasi apa yang boleh dilakukan identitas tersebut pada setiap sumber daya. Ketiganya opsional dan diaktifkan lewat konfigurasi listener, sehingga sebuah cluster dapat berjalan dengan kombinasi berbeda, misalnya enkripsi saja, atau enkripsi beserta autentikasi tanpa otorisasi.

Gambar berikut menempatkan ketiga lapisan pada jalur koneksi dari klien menuju broker. Urutan nomor di dalamnya menunjukkan lapisan mana yang diperiksa lebih dahulu sebelum permintaan mencapai log.

Broker lokal pada jalur ini berjalan tanpa seluruh lapisan tersebut, yaitu listener PLAINTEXT tanpa autentikasi dan tanpa otorisasi. Konfigurasi bawaan semacam ini memudahkan pembelajaran, tetapi juga menegaskan bahwa keamanan Kafka tidak aktif dengan sendirinya, melainkan dipasang melalui keputusan konfigurasi yang eksplisit. Pembahasan berikut bergerak dari lapisan paling luar, yaitu enkripsi, menuju keputusan paling dalam, yaitu izin per operasi.

Enkripsi SSL pada listener#

Enkripsi SSL mengamankan jalur data antara klien dan broker menggunakan protokol TLS (Transport Layer Security), dan nama konfigurasinya mempertahankan awalan ssl. sebagai warisan (legacy) dari protokol sebelumnya. Broker yang melayani koneksi terenkripsi membuka listener bertipe SSL://, lalu memuat sertifikat dan kunci pribadinya dari keystore, sedangkan truststore menyimpan sertifikat pihak yang dipercaya. Blok berikut memuat potongan konfigurasi broker untuk listener SSL beserta penyimpanan sertifikatnya.

# Lapisan enkripsi SSL pada listener klien broker.
# Berkas ini berupa potongan server.properties untuk listener SSL.
listeners=SSL://:9092
listener.security.protocol.map=SSL:SSL
ssl.keystore.location=/etc/kafka/ssl/broker.keystore.p12
ssl.keystore.type=PKCS12
ssl.keystore.password=sandi-keystore
ssl.key.password=sandi-kunci
ssl.truststore.location=/etc/kafka/ssl/broker.truststore.p12
ssl.truststore.type=PKCS12
ssl.client.auth=required

Properti listeners membuka listener SSL pada port 9092, dan listener.security.protocol.map memetakan nama listener ke protokol keamanannya. Pasangan ssl.keystore.location dan ssl.truststore.location menunjuk berkas keystore serta truststore broker, sedangkan ssl.client.auth=required meminta sertifikat klien pada setiap koneksi. Pola terakhir disebut autentikasi mTLS (mutual TLS) karena identitas klien diverifikasi dari sertifikatnya pada lapisan TLS itu sendiri. Kata sandi pada contoh ditulis polos demi kejelasan, sedangkan deployment nyata memuat kata sandi melalui config provider agar rahasia tidak berada di berkas konfigurasi. Kombinasi lain yang lazim adalah SASL_SSL, yaitu listener yang mengenkripsi jalur dan menjalankan autentikasi SASL di atasnya, sedangkan SASL_PLAINTEXT mengautentikasi tanpa mengenkripsi dan hanya layak digunakan pada jaringan yang terpercaya.

Autentikasi SASL#

SASL (Simple Authentication and Security Layer) adalah kerangka autentikasi yang menjalankan pemeriksaan identitas klien di atas listener, dan mekanismenya menentukan bentuk kredensial yang digunakan. Kafka mendukung beberapa mekanisme bawaan, dan pilihannya memengaruhi cara kredensial dikelola serta jaminan yang diperoleh. Tabel berikut membandingkan mekanisme yang paling lazim.

Di luar tabel, Kafka juga menyediakan SASL/OAUTHBEARER yang membawa token dari penyedia identitas. Mekanisme SCRAM menyimpan kredensial per pengguna pada broker dan dikelola dengan kafka-configs, sehingga kredensial dapat disiapkan sebelum listener SASL diaktifkan. Blok berikut membuat kredensial SCRAM-SHA-512 untuk pengguna demo pada broker lokal, lalu menampilkan mekanisme yang tercatat. Broker sandbox berjalan pada listener PLAINTEXT, dan perintah ini tetap berhasil karena penyimpanan kredensial terpisah dari listener yang aktif.

(
  cd /home/kal/my-project/kafka-runtime/kafka
  bin/kafka-configs.sh --bootstrap-server localhost:9092 --alter --entity-type users --entity-name m7-pengguna-demo --delete-config 'SCRAM-SHA-512' >/dev/null 2>&1
  bin/kafka-configs.sh --bootstrap-server localhost:9092 --alter --entity-type users --entity-name m7-pengguna-demo --add-config 'SCRAM-SHA-512=[password=sandi-demo]' >/dev/null 2>&1
  bin/kafka-configs.sh --bootstrap-server localhost:9092 --describe --entity-type users --entity-name m7-pengguna-demo 2>/dev/null | grep -o "SCRAM-SHA-512"
)

SCRAM-SHA-512

Keluarannya satu baris karena deskripsi kredensial memuat nilai salt acak yang berubah setiap kali dibuat ulang, sehingga barisnya disaring untuk menampilkan mekanisme yang terdaftar. Mekanisme yang diaktifkan ditetapkan lewat sasl.enabled.mechanisms dan listener.name.<listener>.sasl.enabled.mechanisms, sedangkan klien menyertakan kredensialnya melalui security.protocol beserta konfigurasi JAAS (Java Authentication and Authorization Service) di sisi aplikasi. Pada lingkungan yang tidak menggunakan Kerberos, SCRAM-SHA-512 menjadi pilihan umum karena kredensialnya cukup dikelola di broker.

Otorisasi ACL#

Otorisasi memutuskan operasi apa yang boleh dilakukan identitas yang sudah terautentikasi, dan mekanismenya berupa ACL (Access Control List), yaitu daftar aturan yang memasangkan identitas dengan operasi tertentu pada sumber daya tertentu. Identitas dalam ACL disebut principal dan ditulis dengan awalan jenisnya, misalnya User:penulis-laporan. Operasinya mengikuti jenis permintaan seperti Read, Write, Create, dan Describe. Sumber dayanya dapat berupa topic, consumer group, atau cluster. Aturan dapat dibatasi pada host tertentu melalui --allow-host maupun --deny-host.

Otorisasi aktif setelah broker dikonfigurasi dengan authorizer, yaitu komponen broker yang menegakkan ACL. Pada mode KRaft, kelasnya adalah org.apache.kafka.metadata.authorizer.StandardAuthorizer yang menyimpan aturan pada metadata cluster. Tanpa authorizer, broker mengizinkan semua operasi dan menolak setiap perintah ACL dengan error SecurityDisabledException, perilaku yang ditunjukkan blok berikut pada broker lokal.

(
  cd /home/kal/my-project/kafka-runtime/kafka
  bin/kafka-acls.sh --bootstrap-server localhost:9092 --list 2>/dev/null | grep "Error while executing"
)

Error while executing ACL command: org.apache.kafka.common.errors.SecurityDisabledException: No Authorizer is configured on the broker

Baris keluaran menyatakan tidak ada authorizer yang dikonfigurasi, keadaan yang juga berarti seluruh operasi diizinkan tanpa pemeriksaan. Pada broker dengan authorizer aktif, aturan dikelola melalui perintah kafka-acls, dan contoh berikut memberi izin tulis pada satu topic untuk satu principal dari satu host. Contoh ini ditandai tidak dijalankan karena membutuhkan broker dengan authorizer yang aktif.

# tidak-dijalankan
# broker sandbox tidak mengaktifkan authorizer, sehingga perintah ACL tidak dapat dieksekusi
bin/kafka-acls.sh --bootstrap-server localhost:9092 --add \
  --allow-principal User:penulis-laporan \
  --operation Write \
  --topic m7-laporan-harian \
  --allow-host 10.10.0.21

Otorisasi berlaku terhadap semua klien, termasuk alat CLI, worker Connect, dan aplikasi producer atau consumer, sehingga rancangan ACL memperhitungkan identitas aplikasi sekaligus identitas alat operasional. Aturan yang ditulis rapi per topic dan per group menjadikan cakupan akses setiap komponen terbaca langsung dari daftar ACL-nya. Penambahan dan penghapusan aturan berjalan secara dinamis tanpa menjalankan ulang broker, sehingga perubahan izin diterapkan sambil cluster tetap melayani klien.

Konteks keamanan pada layanan cloud#

Layanan Kafka terkelola mengemas ketiga lapisan di atas ke dalam pengaturan yang disediakan penyedia, sehingga listener, sertifikat, dan identitas dikonfigurasi melalui konsol atau berkas konfigurasi layanan. Enkripsi TLS lazim diwajibkan sejak awal, autentikasi ditawarkan dalam bentuk SASL/SCRAM atau integrasi dengan sistem identitas cloud, dan pembatasan akses menggunakan ACL Kafka atau kebijakan identitas milik layanan. Jaringan privat memperketat permukaan serangan, misalnya cluster hanya dapat dicapai dari dalam jaringan virtual organisasi, bukan dari internet. Pengaturan pada konsol memetakan langsung ke listener, mekanisme autentikasi, dan aturan izin yang sama dengan cluster mandiri, sehingga tiga lapisan tetap menjadi kerangka pembacaannya.

Tanggung jawab yang tersisa berpindah ke pengelola cluster. Kredensial SCRAM perlu dirotasi berkala, ACL perlu ditinjau setiap kali aplikasi berganti, dan enkripsi saat penyimpanan (encryption at rest) diatur bersama penyedia layanan. Perbedaan utama dengan cluster mandiri terletak pada siapa yang mengelola sertifikat dan identitas, bukan pada model keamanannya.

Kesalahan umum#

1. Menganggap SASL_PLAINTEXT aman karena menggunakan autentikasi. Mekanisme ini mengirim identitas dan kredensial tanpa enkripsi, sehingga keduanya dapat dibaca siapa pun di jaringan yang sama. Gunakan SASL_SSL untuk koneksi yang melewati jaringan, dan simpan SASL_PLAINTEXT untuk pengujian lokal.
2. Mengaktifkan autentikasi tanpa authorizer. Broker memeriksa identitas klien tetapi tetap mengizinkan semua operasi, sehingga tidak ada pembatasan yang benar-benar terjadi dan audit akses tidak dapat dilakukan. Konfigurasikan authorizer beserta ACL sejak awal.
3. Menyimpan kata sandi keystore di berkas konfigurasi yang ikut masuk repository. Nilai tersebut membuka akses ke kunci pribadi broker yang digunakan untuk memvalidasi seluruh koneksi. Muat rahasia melalui config provider atau variabel lingkungan yang dikelola terpisah, dan pisahkan berkasnya dari konfigurasi teknis.
4. Memberi aturan tingkat cluster kepada principal aplikasi. Aturan yang terlalu luas membuat satu kredensial yang bocor berdampak ke seluruh cluster. Batasi aturan pada topic dan consumer group yang benar-benar digunakan aplikasi, lalu tinjau ulang daftar ACL setiap kali komponen dihapus.

Ringkasan#

• Keamanan Kafka tersusun atas tiga lapisan opsional pada listener, yaitu enkripsi SSL, autentikasi SASL, dan otorisasi ACL.
• Listener SSL mengenkripsi jalur data dengan keystore dan truststore, sedangkan ssl.client.auth=required menjadikan sertifikat klien sebagai identitas.
• Mekanisme SASL dipilih dari PLAIN, SCRAM-SHA-512, GSSAPI/Kerberos, atau autentikasi sertifikat, dan kredensial SCRAM dikelola lewat kafka-configs.
• ACL memasangkan principal dengan operasi pada sumber daya, aktif setelah authorizer dikonfigurasi, dan tanpa authorizer broker mengizinkan semua operasi.

Referensi#

• Security overview — Apache Software Foundation — daftar ukuran keamanan yang didukung Kafka, yaitu autentikasi SSL/SASL, enkripsi, dan otorisasi.
• Encryption and authentication using SSL — Apache Software Foundation — konfigurasi keystore, truststore, dan ssl.client.auth pada listener SSL.
• Authentication using SASL — Apache Software Foundation — mekanisme PLAIN, SCRAM, GSSAPI/Kerberos, dan OAUTHBEARER beserta konfigurasinya.
• Authorization and ACLs — Apache Software Foundation — struktur principal, operasi izin, dan perintah kafka-acls.
• Listener configuration — Apache Software Foundation — pemetaan listener.security.protocol.map dan kombinasi listener SASL_SSL.