Multi-Tenant Security: Isolasi, Quota, dan Pengamanan Multi-Tenant di Kafka #

Ketika kluster Apache Kafka dikonsumsi oleh banyak tim, aplikasi, atau departemen yang berbeda di dalam satu organisasi (atau bahkan klien eksternal yang berbeda dalam skenario Software-as-a-Service), kita dihadapkan pada tantangan pengelolaan multi-tenant (multi-tenant management). Tanpa adanya sistem isolasi dan batas keamanan yang ketat, aktivitas salah satu penyewa (tenant) dapat dengan mudah merusak kinerja penyewa lainnya. Skenario terburuknya adalah timbulnya masalah Noisy Neighbor (tetangga berisik) di mana satu tenant membanjiri kluster dengan jutaan request per detik, menghabiskan seluruh memori heap broker, atau memonopoli bandwidth jaringan sehingga menyebabkan timbal balik kegagalan fungsi (cascading failure) pada aplikasi kritis lainnya.

Selain masalah kestabilan performa, aspek kerahasiaan data juga menjadi pertaruhan. Tanpa isolasi logis yang kuat, tim pembukuan dapat secara tidak sengaja membaca data transaksi mentah dari tim pembayaran, atau departemen pemasaran dapat merusak konfigurasi topik milik departemen logistik.

Dalam panduan komprehensif ini, kita akan membahas arsitektur multi-tenancy di Apache Kafka, membandingkan isolasi fisik vs isolasi logis, merancang standarisasi penamaan (naming convention) namespace, mengonfigurasi batas kapasitas (Quotas) bandwidth dan request, serta menerapkan teknik perlindungan mutakhir untuk mencegah fenomena Noisy Neighbor di produksi.

Pilihan Arsitektur Multi-Tenancy: Fisik vs Logis #

Di dalam Apache Kafka, kita dapat menerapkan multi-tenancy melalui dua pendekatan utama:

1. Isolasi Fisik (Multi-Cluster) #

Pada metode ini, setiap tenant mendapatkan kluster Kafka fisiknya masing-masing yang terisolasi secara infrastruktur.

• Kelebihan: Keamanan mutlak. Tidak ada kompetisi sumber daya (CPU/RAM/Disk/Jaringan) antar-tenant. Kegagalan pada satu kluster tenant tidak berdampak pada tenant lain.
• Kekurangan: Biaya infrastruktur membengkak drastis. Overhead pengelolaan operasional (monitoring, patching, upgrade) menjadi sangat tinggi bagi tim administrator.

2. Isolasi Logis (Shared Cluster) #

Semua tenant berbagi satu kluster Kafka yang sama, namun dipisahkan secara logis menggunakan skema otorisasi (ACL), enkripsi (SSL), konvensi penamaan topik, dan pembatasan kuota (Quotas).

• Kelebihan: Efisiensi biaya yang sangat tinggi. Maksimalisasi pemanfaatan kapasitas server (resource utilization). Pengelolaan kluster terpusat yang memudahkan operasional tim DevOps.
• Kekurangan: Risiko gangguan performa antar-tenant (Noisy Neighbor) jika kuota tidak dikonfigurasi dengan benar. Kompleksitas manajemen kebijakan keamanan (ACL) yang menuntut otomatisasi tingkat tinggi.

Kerangka Kerja Isolasi Logis di Kafka #

Untuk membangun kluster multi-tenant terbagi (shared multi-tenant cluster) yang aman, kita harus menyusun tiga lapis pertahanan utama:

flowchart TD
    subgraph MultiTenantCluster ["KLUSTER KAFKA SHARED (MULTI-TENANT)"]
        direction TB
        
        subgraph Layer1 ["Lapis 1: Otentikasi & Identitas"]
            ClientA["Tenant A (Principal: User:tenant-a)"]
            ClientB["Tenant B (Principal: User:tenant-b)"]
        end

        subgraph Layer2 ["Lapis 2: Namespace & Otorisasi (ACL)"]
            ACL_A{"ACL: Read/Write ke 'tenant-a.*'"}
            ACL_B{"ACL: Read/Write ke 'tenant-b.*'"}
        end

        subgraph Layer3 ["Lapis 3: Pembatasan Kuota (Quotas)"]
            Quota_A["Quota: 10 MB/s Input | 20 MB/s Output"]
            Quota_B["Quota: 5 MB/s Input | 10 MB/s Output"]
        end

        subgraph Storage ["Penyimpanan Broker (Disk & Network)"]
            TopicA[("Topik: tenant-a.orders")]
            TopicB[("Topik: tenant-b.logs")]
        end

        ClientA -->|mTLS / SASL| ACL_A
        ClientB -->|mTLS / SASL| ACL_B

        ACL_A --> Quota_A
        ACL_B --> Quota_B

        Quota_A --> TopicA
        Quota_B --> TopicB
    end

1. Standardisasi Penamaan Namespace Topik #

Dalam kluster bersama, kita wajib memberlakukan struktur penamaan topik yang ketat guna menghindari bentrokan nama (naming collision) dan menyederhanakan penulisan aturan ACL. Standar yang umum digunakan adalah menggunakan prefiks berbasis tenant:

$$\text{Format: } \langle\text{Tenant-ID}\rangle.\langle\text{Nama-Domain}\rangle.\langle\text{Spesifik-Fungsi}\rangle$$

Contoh:

• payment.core.ledger-entries (Tenant: payment)
• marketing.campaigns.user-clicks (Tenant: marketing)

Dengan format ini, kita dapat menetapkan aturan akses berbasis prefiks menggunakan wildcard ACL satu kali saja per tenant, alih-alih membuat ACL terpisah untuk setiap topik baru.

Mengonfigurasi Kafka Quotas untuk Menjinakkan Noisy Neighbor #

Kafka Quotas adalah mekanisme perlindungan paling penting dalam kluster multi-tenant. Tanpa kuota, satu klien yang salah menulis loop kode produser dapat membanjiri broker dengan megabyte data tanpa batas, memicu penumpukan memori dan menyumbat antrean jaringan.

Kafka mendukung tiga jenis kuota:

1. Bandwidth Quotas: Membatasi laju transfer data masuk (byte/detik) dan data keluar (byte/detik).
2. Request Rate Quotas: Membatasi persentase waktu CPU yang dihabiskan oleh broker untuk memproses request dari tenant tertentu.
3. Connection Quotas: Membatasi jumlah koneksi TCP baru yang dapat dibuat per detik dan jumlah total koneksi aktif.

Kita dapat menerapkan kuota ini pada tingkat User Principal (kredensial otentikasi) atau Client ID (identitas aplikasi klien). Menggunakan User Principal jauh lebih aman karena Client ID mudah dipalsukan di sisi kode aplikasi oleh developer.

1. Membatasi Bandwidth Input/Output Tenant #

Kita ingin membatasi agar tenant payment-service hanya diizinkan mengirimkan data (produksi) maksimal 10 MB/detik dan membaca data (konsumsi) maksimal 20 MB/detik.

Catatan: Parameter kuota dihitung dalam satuan byte per detik (10 MB = 10.485.760 bytes).

Jalankan perintah berikut untuk mengonfigurasi kuota secara dinamis:

# Menyetel kuota bandwidth untuk principal 'User:payment-service'
kafka-configs.sh --bootstrap-server localhost:9093 \
  --command-config /etc/kafka/client.properties \
  --alter \
  --entity-type users \
  --entity-name payment-service \
  --add-config "producer_byte_rate=10485760,consumer_byte_rate=20971520"

Jika aplikasi klien terhubung menggunakan kredensial tersebut dan mencoba mempublikasikan data melebihi 10 MB/detik, Kafka Broker tidak akan langsung memutuskan koneksi. Sebagai gantinya, broker akan menghitung berapa lama waktu penundaan (delay) yang diperlukan untuk membawa laju transfer kembali ke batas kuota, menahan respons (delaying response) ke produser tersebut selama masa penundaan itu, dan mengirimkan metrik durasi throttling kembali ke klien.

2. Membatasi Penggunaan CPU Broker (Request Rate Quotas) #

Ada kalanya aplikasi klien mengirim pesan dalam ukuran yang sangat kecil (misal 10 byte), tetapi dengan frekuensi yang sangat tinggi (ratusan ribu pesan per detik). Meskipun bandwidth data mereka kecil (hanya beberapa ratus kilobyte), jutaan request kecil ini memaksa CPU broker bekerja ekstra keras untuk memproses metadata dan melakukan verifikasi keamanan. Hal ini dapat membuat CPU broker mencapai utilisasi 100% dan membuat kluster tidak responsif.

Untuk mencegahnya, kita dapat menyetel batas persentase waktu thread I/O dan thread jaringan broker yang boleh dihabiskan untuk melayani satu tenant tertentu:

# Membatasi penggunaan CPU broker untuk user 'payment-service' sebesar 2%
kafka-configs.sh --bootstrap-server localhost:9093 \
  --command-config /etc/kafka/client.properties \
  --alter \
  --entity-type users \
  --entity-name payment-service \
  --add-config "request_percentage=2"

3. Membatasi Koneksi TCP (Connection Quotas) #

Connection quotas mencegah terjadinya kegagalan akibat kehabisan memori heap JVM atau batas file descriptor OS (sockets exhaustion). Kita dapat mengonfigurasi batas ini secara global atau per alamat IP di berkas server.properties broker:

# server.properties - CONNECTION QUOTAS

# Batas maksimum jumlah koneksi TCP aktif di seluruh listener per broker
max.connections=50000

# Batas maksimum pembuatan koneksi baru per detik per IP address (mencegah Connection Storm)
max.connection.creation.rate=50

# Batas koneksi khusus per IP address tertentu
# Format: host:max_connections
max.connections.per.ip=192.168.1.50:500,192.168.2.100:1000

Runbook Penanganan Krisis Noisy Neighbor di Produksi #

Jika kluster multi-tenant kita tiba-tiba mengalami degradasi performa akibat aktivitas anomali dari salah satu tenant, kita dapat menggunakan runbook penanganan insiden berikut untuk mengembalikan stabilitas kluster tanpa mematikan server:

Langkah 1: Identifikasi Principal Pelaku Menggunakan JMX #

Lihat dasbor Grafana kita atau lakukan query JMX MBean secara langsung pada broker aktif untuk mencari principal dengan metrik ThrottleTimeMs yang meroket tajam:

• MBean: kafka.server:type=RequestMetrics,name=ThrottleTimeMs,request=Produce
• Kelompokkan metrik berdasarkan tag user untuk mengetahui principal mana yang sedang memonopoli request.

Langkah 2: Lakukan Throttling Darurat Secara Dinamis #

Jika kita mendeteksi bahwa principal marketing-agent adalah penyebab kelebihan beban CPU karena mengirim jutaan request tanpa batas, kita dapat memperketat kuota mereka secara instan menjadi sangat rendah (misalnya hanya 500 KB/detik):

# Throttling darurat untuk user 'marketing-agent' menjadi 512 KB/s
kafka-configs.sh --bootstrap-server localhost:9093 \
  --command-config /etc/kafka/client.properties \
  --alter \
  --entity-type users \
  --entity-name marketing-agent \
  --add-config "producer_byte_rate=524288,consumer_byte_rate=1048576"

Perubahan ini langsung aktif dalam hitungan milidetik tanpa perlu mematikan broker. Aplikasi klien marketing-agent akan langsung merasakan keterlambatan pengiriman (throttled), sehingga mengamankan resource CPU broker untuk tenant kritis lainnya.

Langkah 3: Isolasi Melalui Konfigurasi Topik Dinamis (Log Cleaner) #

Apabila anomali terjadi akibat penumpukan log segmen tenant tertentu yang memakan kapasitas I/O disk (Disk IOPS starvation), kita dapat memperlambat frekuensi kompresi log segmen pada topik tenant tersebut agar tidak bersaing dengan I/O transaksi:

# Menurunkan prioritas pembersihan log pada topik tenant-b
kafka-configs.sh --bootstrap-server localhost:9093 \
  --command-config /etc/kafka/client.properties \
  --alter \
  --entity-type topics \
  --entity-name tenant-b.logs.raw \
  --add-config "min.cleanable.dirty.ratio=0.8,segment.ms=86400000"

Langkah Praktis Penerapan ACL Multi-Tenant #

Mari kita simulasikan penerapan aturan isolasi logis penuh untuk dua tenant: tenant-a dan tenant-b.

Skenario Hak Akses: #

1. tenant-a hanya boleh membaca dan menulis pada topik yang diawali dengan nama tenant-a.. Mereka juga hanya boleh bergabung dalam Consumer Group yang diawali dengan nama group.tenant-a..
2. tenant-b hanya boleh membaca dan menulis pada topik yang diawali dengan nama tenant-b., serta menggunakan Consumer Group berawalan group.tenant-b..

Perintah Konfigurasi ACL: #

# ------------------------------------------------------------------------------
# ATURAN ACL UNTUK TENANT A
# ------------------------------------------------------------------------------

# 1. Izinkan write (produksi) ke semua topik berawalan "tenant-a."
kafka-acls.sh --bootstrap-server localhost:9093 \
  --command-config /etc/kafka/client.properties \
  --add \
  --allow-principal User:tenant-a \
  --operation Write \
  --topic tenant-a. \
  --resource-pattern-type prefixed

# 2. Izinkan read (konsumsi) ke semua topik berawalan "tenant-a."
kafka-acls.sh --bootstrap-server localhost:9093 \
  --command-config /etc/kafka/client.properties \
  --add \
  --allow-principal User:tenant-a \
  --operation Read \
  --topic tenant-a. \
  --resource-pattern-type prefixed

# 3. Izinkan join ke Consumer Group yang diawali "group.tenant-a."
kafka-acls.sh --bootstrap-server localhost:9093 \
  --command-config /etc/kafka/client.properties \
  --add \
  --allow-principal User:tenant-a \
  --operation Read \
  --group group.tenant-a. \
  --resource-pattern-type prefixed


# ------------------------------------------------------------------------------
# ATURAN ACL UNTUK TENANT B
# ------------------------------------------------------------------------------

# 1. Izinkan write ke topik berawalan "tenant-b."
kafka-acls.sh --bootstrap-server localhost:9093 \
  --command-config /etc/kafka/client.properties \
  --add \
  --allow-principal User:tenant-b \
  --operation Write \
  --topic tenant-b. \
  --resource-pattern-type prefixed

# 2. Izinkan read ke topik berawalan "tenant-b."
kafka-acls.sh --bootstrap-server localhost:9093 \
  --command-config /etc/kafka/client.properties \
  --add \
  --allow-principal User:tenant-b \
  --operation Read \
  --topic tenant-b. \
  --resource-pattern-type prefixed

# 3. Izinkan join ke Consumer Group berawalan "group.tenant-b."
kafka-acls.sh --bootstrap-server localhost:9093 \
  --command-config /etc/kafka/client.properties \
  --add \
  --allow-principal User:tenant-b \
  --operation Read \
  --group group.tenant-b. \
  --resource-pattern-type prefixed

Dengan konfigurasi ini, jika pengguna tenant-a mencoba membaca data dari topik milik tenant-b (misalnya tenant-b.sales-data), otorisasi Kafka langsung memblokir request tersebut dengan melemparkan error TopicAuthorizationException ke aplikasi klien.

Pemantauan (Monitoring) Throttling Multi-Tenant #

Mengaktifkan kuota menuntut kita untuk selalu memantau kapan dan seberapa sering penyewa kluster kita mengalami pembatasan (throttling). Klien Kafka Java SDK yang ter-throttle akan mencatatkan pesan log info, namun kita wajib mengumpulkan metrik ini secara terpusat melalui Prometheus/Grafana untuk memicu alert proaktif sebelum aplikasi klien mengalami keterlambatan pemrosesan data (lag).

Metrik JMX Kunci untuk Pemantauan Quota Throttling: #

1. Broker-side Throttle Time (Produser):
   • JMX MBean: kafka.server:type=Produce,name=QueueTimeMs atau kafka.server:type=RequestMetrics,name=ThrottleTimeMs,request=Produce
   • Deskripsi: Mengukur rata-rata waktu (dalam milidetik) produser ditahan oleh broker karena melebihi kuota bandwidth input.
2. Broker-side Throttle Time (Konsumen):
   • JMX MBean: kafka.server:type=Fetch,name=QueueTimeMs atau kafka.server:type=RequestMetrics,name=ThrottleTimeMs,request=Fetch
   • Deskripsi: Mengukur rata-rata waktu konsumen ditahan karena melebihi kuota bandwidth output.
3. Request Throttle Time:
   • JMX MBean: kafka.server:type=RequestMetrics,name=ThrottleTimeMs,request=*.
   • Deskripsi: Mengukur penundaan akibat melebihi kuota persentase CPU request.

Jika di Grafana kita melihat nilai metrik ThrottleTimeMs di atas 0 untuk principal tertentu, itu berarti tenant tersebut telah melampaui kapasitas yang dialokasikan untuk mereka. Tim operasional dapat menggunakan data ini untuk memutuskan apakah perlu menaikkan kuota tenant tersebut (skala horizontal bisnis) atau meminta developer aplikasi tersebut melakukan audit kode untuk mengoptimalkan efisiensi penulisan data.

Checklist Audit Keamanan Multi-Tenant #

Gunakan panduan berikut untuk memverifikasi keamanan dan isolasi kluster multi-tenant kita:

Ringkasan #

• Terapkan Kuota Sejak Awal — Jangan menunggu kluster kita tumbang akibat masalah Noisy Neighbor. Selalu pasang batas kapasitas bandwidth input/output dan kuota request CPU untuk setiap user principal produksi.
• Wajibkan Prefiks Topik — Gunakan standardisasi prefiks penamaan topik berbasis tenant (misal tenant-name.domain-name.topic-name) untuk mempermudah pemetaan hak akses ACL secara modular dan otomatis.
• Gunakan Otentikasi Kuat — Otorisasi multi-tenant yang aman bergantung penuh pada proses otentikasi yang tangguh. Gunakan otentikasi mTLS atau SASL/SCRAM-SHA-512 agar principal tenant tidak dapat dipalsukan.
• Pantau Throttle Time — Amati metrik ThrottleTimeMs di Grafana secara berkala untuk mengidentifikasi tenant mana saja yang sering mengalami pembatasan laju transfer akibat penggunaan resource berlebih.

← Sebelumnya: Encryption at Rest   Berikutnya: Kafka Metrics →