Belajar Apache Kafka - Authorization dengan ACLs

#Pendahuluan

Autentikasi menjawab pertanyaan siapa kalian. Authorization menjawab pertanyaan berikutnya: apa yang boleh kalian lakukan? Di Kafka, jawabannya diatur oleh ACLs (Access Control Lists) — aturan yang menghubungkan prinsipal dengan operasi pada resource tertentu.

Tanpa authorization yang benar, setiap user yang terautentikasi bisa menulis ke topic apa pun, membaca data apa pun, bahkan menghapus topic. Di episode 17 ini kalian akan belajar konsep prinsipal, resource, dan operasi, mengelola ACL dengan kafka-acls.sh, menerapkan pola ACL untuk producer dan consumer, serta memahami least privilege dan custom authorizer.

#Konsep ACL

#Prinsipal dan Resource Types

Prinsipal adalah identitas yang dihasilkan autentikasi, biasanya User:app-producer pada SASL/SCRAM atau User:CN=client pada SSL. ACL mengizinkan atau menolak prinsipal untuk beroperasi pada resource. Empat resource types utama:

• Topic: data yang ditulis dan dibaca.
• Group: consumer group; mengontrol siapa yang boleh mengonsumsi.
• Cluster: operasi cluster level seperti pembuatan topic dan reassignment.
• TransactionalId: operasi transaksi; mengontrol siapa yang boleh memakai id transaksi.

#Operations

Setiap resource memiliki operasi spesifik:

• Topic: Read, Write, Describe, Create, Delete, Alter.
• Group: Read (mengizinkan join dan commit offset), Describe.
• Cluster: Create, Alter, Describe, ClusterAction, IdempotentWrite.

#Cara Kerja Authorization

Saat broker menerima request, authorizer memeriksa: apakah ada ACL yang mengizinkan prinsipal ini melakukan operasi ini pada resource ini? Jika tidak ada, request ditolak. Perhatikan: default deny — tanpa ACL, semuanya ditolak ketika allow.everyone.if.no.acl.found=false (default).

#Pengelolaan ACL

#Membuat ACL

ACL dibuat dengan kafka-acls.sh:

bin/kafka-acls.sh --bootstrap-server localhost:9093 \
  --add --allow-principal User:app-producer \
  --operation Write,Describe \
  --topic orders

Perintah kafka-acls.sh --add menambahkan ACL. Prinsipal app-producer sekarang boleh menulis dan describe topic orders. Perhatikan bahwa operasi Describe sering perlu ditambahkan eksplisit karena klien membutuhkannya untuk metadata.

#Menampilkan dan Menghapus ACL

bin/kafka-acls.sh --bootstrap-server localhost:9093 --list --topic orders
bin/kafka-acls.sh --bootstrap-server localhost:9093 \
  --remove --allow-principal User:app-producer \
  --operation Write --topic orders

kafka-acls.sh --list menampilkan ACL untuk resource, dan kafka-acls.sh --remove menghapus aturan yang tidak lagi dibutuhkan. Audit rutin ACL yang tidak terpakai adalah bagian dari keamanan jangka panjang.

#Wildcard ACLs

--resource-pattern-type dengan nilai LITERAL atau PREFIXED menentukan pencocokan. Wildcard memakai --topic '*' atau prefixed pattern untuk mencakup banyak topic sekaligus:

bin/kafka-acls.sh --bootstrap-server localhost:9093 \
  --add --allow-principal User:analytics \
  --operation Read --resource-pattern-type PREFIXED \
  --topic analytics-

--resource-pattern-type PREFIXED mencocokkan semua topic yang diawali analytics-. Prefixed pattern lebih aman daripada '*' karena lingkupnya jelas.

#Pola Authorization

#Producer dan Consumer ACL

Pola minimal yang umum di produksi:

bin/kafka-acls.sh --bootstrap-server localhost:9093 \
  --add --allow-principal User:app-producer \
  --operation Write,Describe --topic orders
 
bin/kafka-acls.sh --bootstrap-server localhost:9093 \
  --add --allow-principal User:app-consumer \
  --operation Read,Describe --topic orders
 
bin/kafka-acls.sh --bootstrap-server localhost:9093 \
  --add --allow-principal User:app-consumer \
  --operation Read --group order-consumers

Consumer memerlukan Read pada topic dan Read pada group yang dipakainya — keduanya wajib. Tanpa ACL group, consumer gagal join group meskipun ACL topic sudah benar.

#Admin ACL dan Least Privilege

Aplikasi admin memakai ClusterAction dan Alter pada cluster — prinsipal ini harus sangat dibatasi. Terapkan prinsip least privilege: setiap prinsipal hanya mendapat operasi minimum yang dibutuhkan. Service account yang berbeda untuk producer dan consumer, bukan satu akun super user.

#Service Account Management

Buat service account terpisah per aplikasi, bukan memakai akun manusia. Rotasi kredensial service account tidak mengganggu pengguna, dan pelacakan aktivitas per aplikasi menjadi jauh lebih mudah. Gunakan pola penamaan seperti svc-<aplikasi>-<peran> agar ACL mudah diaudit.

#Custom Authorizers

#Implementasi Custom Authorizer

Jika kebijakan bawaan tidak cukup, implementasikan org.apache.kafka.server.authorizer.Authorizer dan konfigurasikan di broker:

authorizer.class.name=com.example.ExternalAuthorizer

authorizer.class.name mengganti authorizer bawaan. Authorizer custom menerima panggilan authorize() untuk setiap request dan bisa memutuskan berdasarkan logika apa pun — termasuk memanggil layanan eksternal.

#Integrasi Eksternal dan RBAC

Authorizer custom memungkinkan integrasi dengan kebijakan terpusat: database authorization, layanan RBAC, atau sistem IAM perusahaan. Prinsipal dipetakan ke peran, dan peran menentukan hak akses. Ini menghindari penyebaran ACL di banyak cluster dan menyatukan kebijakan dalam satu tempat.

#Penutup

Di episode 17 ini kalian sudah memahami konsep prinsipal, resource types, dan operasi ACL, mengelola ACL dengan kafka-acls.sh, menerapkan pola producer dan consumer ACL, prinsip least privilege, serta custom authorizer dan integrasi RBAC.

Inti yang harus dibawa pulang:

• Tanpa ACL, semua akses ditolak: default deny.
• Consumer butuh ACL Read pada topic dan group sekaligus.
• --resource-pattern-type PREFIXED memberi lingkup wildcard yang aman.
• Terapkan least privilege dengan service account terpisah per aplikasi.
• Admin dan ClusterAction dibatasi ketat untuk prinsipal khusus.
• Custom authorizer menyatukan kebijakan dengan sistem eksternal.

Di episode 18 selanjutnya kita akan membahas encryption dan TLS/SSL — pembuatan CA dan sertifikat, keystore dan truststore, konfigurasi TLS di broker dan klien, enkripsi data saat transit, serta pengelolaan siklus hidup sertifikat.