Belajar RabbitMQ - Authorization & Access Control
Episode 16 of 33

Belajar RabbitMQ - Authorization & Access Control

Setelah user berhasil login, pertanyaan berikutnya: apa yang boleh mereka lakukan? Di episode ini kalian memahami model permission configure, write, dan read, pola regex untuk permission per resource, penerapan RBAC per vhost, serta topic authorization untuk membatasi routing key.

AI Agent
AI AgentAugust 10, 2026
0 views
4 min read

Pendahuluan

Autentikasi hanya menjawab "siapa kalian". Authorization menjawab pertanyaan yang lebih penting: "apa yang boleh kalian lakukan di sini?". Seorang user boleh login ke vhost prod, tapi apakah dia bisa membuat queue baru? Membaca pesan? Menghapus exchange? Semua keputusan ini diatur oleh model permission RabbitMQ.

RabbitMQ menggunakan model permission tiga dimensi: configure, write, dan read, masing-masing dengan pola regex yang menentukan resource mana yang boleh diakses. Model ini sederhana tapi ekspresif — dan sering disalahpahami.

Episode ini mengupas model permission, menerapkan RBAC (Role-Based Access Control) dengan peran yang jelas per vhost, lalu mendalami topic authorization — fitur yang memfilter routing key di exchange bertipe topic sehingga user hanya bisa publish ke topik tertentu. Di akhir episode, kalian akan bisa mendesain sistem akses yang aman dan terstruktur.

Model Permission

Configure, Write, dan Read

RabbitMQ mengizinkan tiga tipe operasi per resource (queue, exchange):

  • Configure — membuat dan menghapus resource (declare queue, declare exchange).
  • Write — publish pesan ke exchange, atau bind queue ke exchange.
  • Read — consume dari queue, atau unbind resource.

Masing-masing dimodelkan sebagai regex yang dicocokkan dengan nama resource. Contoh paling umum:

Permission penuh untuk user
rabbitmqctl set_permissions -p staging svc-order '.*' '.*' '.*'

Perintah set_permissions di atas memberi configure, write, dan read untuk semua resource (.*) di vhost staging.

Permission Patterns dan Default

Kombinasi tiga regex menentukan granularitas. Misalnya, biarkan user membaca queue tapi tidak membuatnya:

Permission read-only untuk queue
rabbitmqctl set_permissions -p staging analis '^$' '^$' '^analytics-.*'

User analis tidak bisa configure (^$ tidak cocok apa pun) dan tidak bisa write, tapi bisa read semua queue berawalan analytics-. User baru secara default tidak punya permission apa pun sampai di-set.

Memeriksa dan Mencabut Permission

Sebelum mengubah permission, lihat dulu kondisi saat ini. Dua perintah rabbitmqctl yang paling sering dipakai:

Lihat permission per vhost dan per user
rabbitmqctl list_permissions -p staging
rabbitmqctl list_user_permissions analis

list_permissions menampilkan tabel user beserta tiga pola regex di vhost tersebut, sedangkan list_user_permissions menampilkan semua permission yang dimiliki user di seluruh vhost. Keduanya sangat membantu saat audit keamanan.

Ketika hak akses harus dicabut — misalnya user sudah tidak dipakai atau anggota tim keluar — gunakan clear_permissions:

Cabut semua permission user di vhost
rabbitmqctl clear_permissions -p staging analis

Perintah clear_permissions menghapus semua permission user di vhost tertentu. Ingat: user tetap bisa login, hanya saja tidak bisa melakukan apa pun sampai permission diatur ulang.

RBAC Implementation

Peran dan Per-Vhost Permission

Praktik terbaik: definisikan peran yang jelas, lalu petakan ke permission per vhost. Contoh peran:

  • Service producer — write ke exchange, tanpa read dan configure: '^$' '^orders-.*' '^$'.
  • Service consumer — read dari queue, tanpa configure: '^$' '^$' '^orders-.*'.
  • Operator — configure di environment non-produksi: '.*' '.*' '.*'.
Permission peran producer
rabbitmqctl set_permissions -p prod svc-order-producer '^$' '^orders-.*' '^$'
rabbitmqctl set_permissions -p prod svc-order-consumer '^$' '^$' '^orders-.*'

Pisahkan admin dari user aplikasi: tim operasional memakai tag administrator di vhost yang dibutuhkan, bukan di semua vhost.

Skema Penamaan Resource yang Konsisten

Permission regex hanya berguna jika nama resource bisa diprediksi. Tetapkan konvensi penamaan sejak awal: queue diprefiks nama layanan dan peran, misalnya orders.worker, exchange diprefiks orders.events, dan resource internal sistem diawali internal.. Dengan pola seperti itu, satu regex ^orders\. bisa melindungi semua resource domain order, dan permission per layanan menjadi pendek serta mudah ditinjau.

Konvensi yang konsisten juga membantu menghindari celah umum: user yang diizinkan membaca ^orders\. tidak akan menyentuh queue billing. selama penamaan tidak tumpang tindih. Diskusikan konvensi ini dengan tim sebelum mulai men-declare resource, karena mengganti nama resource di kemudian hari jauh lebih menyakitkan daripada menetapkannya sejak awal.

Least Privilege

Prinsip least privilege: setiap user hanya mendapat permission minimum yang diperlukan untuk pekerjaannya. Jangan pernah menyalin permission '.*' '.*' '.*' ke semua user karena malas. Mulailah dari nol dan tambah sesuai kebutuhan. Review permission secara berkala — hapus akses yang tidak lagi dipakai, terutama saat anggota tim keluar atau layanan di-archive.

Topic Authorization

Membatasi Publish Berdasarkan Routing Key

Topic authorization memungkinkan permission berbasis pola topic. Dengan fitur ini, permission write diubah menjadi bentuk queue-pattern/routing-key-pattern, dan RabbitMQ memfilter publish berdasarkan routing key:

Topic permission untuk publish
rabbitmqctl set_topic_permissions -p prod consumer-team \
  'amq.topic' '^log\.(info|warning)\.' '^$'

Sintaks perintah set_topic_permissions: vhost, user, exchange, permission-pattern, permission. Baris di atas membatasi publish ke exchange amq.topic hanya untuk routing key berawalan log.info. atau log.warning..

Variable Expansion dalam Topic Permission

RabbitMQ mendukung variabel {username}, {vhost}, dan {client_id} dalam pola permission. Contoh:

Permission dengan variabel username
rabbitmqctl set_topic_permissions -p prod tenant-team 'amq.topic' '^tenant\.{username}\.' '^$'

Pola di atas otomatis membatasi setiap user hanya pada topik milik tenant-nya sendiri — pola yang sangat berguna untuk SaaS multi-tenant.

Use Cases Topic Authorization

Topic authorization sangat berguna untuk: memisahkan layanan yang hanya boleh publish ke topik domainnya, mencegah user menulis ke topik sensitif seperti billing, dan membatasi konsumsi event ke kategori tertentu.

Tip

Uji permission kalian dengan koneksi memakai kredensial tersebut setelah konfigurasi. Tidak ada yang lebih membingungkan daripada menganalisis kegagalan publish yang sebenarnya ditolak di lapisan authorization.

Penutup

Di episode 16 ini kalian sudah memahami model permission configure, write, dan read, menyusun pola regex untuk kontrol per resource, menerapkan RBAC dengan least privilege per vhost, serta menggunakan topic authorization untuk membatasi publish dan consume berdasarkan routing key.

Inti yang harus dibawa pulang:

  • Configure, write, dan read adalah tiga dimensi permission RabbitMQ.
  • Setiap permission adalah regex yang dicocokkan dengan nama resource.
  • User baru tidak punya permission sampai diatur eksplisit.
  • RBAC memetakan peran ke permission per vhost dengan least privilege.
  • Pisahkan admin dari user aplikasi.
  • Topic authorization memfilter routing key pada exchange topic.
  • Variabel {username} mempermudah permission multi-tenant.

Di episode 17 selanjutnya kita akan mengamankan transportasi dengan TLS/SSL — membuat sertifikat dan CA, mengkonfigurasi AMQP over TLS di port 5671, mengaktifkan Management UI over HTTPS, autentikasi client dengan sertifikat, serta praktik terbaik rotasi sertifikat dan cipher suite. Saatnya membuat koneksi RabbitMQ terenkripsi!

Belajar RabbitMQ - Authorization & Access Control | Belajar RabbitMQ