June 3, 2026
[RedPanda] Securing Redpanda with SASL and TLS in Docker Compose
Implementing authenticated and encrypted event streaming for local development environments.
Andrian Tri Putra
17 min read
Implementing authenticated and encrypted event streaming for local development environments.
1. Introduction
Pada artikel sebelumnya, kita sudah berhasil membangun local event streaming stack menggunakan Redpanda dengan authentication berbasis SASL. Setup tersebut sudah cukup baik untuk membatasi siapa saja yang dapat terhubung ke broker.
Namun, ada satu hal penting yang masih belum terlindungi: komunikasi antar client dan broker masih berjalan dalam bentuk plaintext.
Artinya, walaupun username dan password sudah digunakan, data yang dikirim tetap berpotensi disadap jika berjalan di network yang tidak aman. Dalam environment development lokal hal ini mungkin terlihat sepele, tetapi ketika mulai mensimulasikan arsitektur production, encryption menjadi bagian yang sangat penting.
Di sinilah TLS (Transport Layer Security) mulai berperan.
Dengan menambahkan TLS, komunikasi antara producer, consumer, dan Redpanda broker akan dienkripsi sehingga:
- credential SASL tidak dikirim dalam plaintext
- payload event menjadi lebih aman
- koneksi antar service menjadi lebih production-like
- local environment dapat mensimulasikan secure distributed system secara lebih realistis
Pada artikel ini kita akan membangun secure local streaming stack menggunakan:
- Redpanda
- Docker Compose
- SASL Authentication
- TLS Encryption
- Rust Kafka Client
Kita juga akan membuat producer dan consumer menggunakan Rust untuk memastikan koneksi Kafka-compatible berjalan aman melalui SASL + TLS.
Target akhirnya adalah memiliki local environment yang:
- authenticated
- encrypted
- reproducible
- mendekati setup production modern
Karena di banyak distributed system modern, keamanan komunikasi bukan lagi optional layer, tetapi sudah menjadi bagian fundamental dari arsitektur sistem itu sendiri.
2. Architecture Overview
Sebelum mulai melakukan konfigurasi TLS, mari kita lihat terlebih dahulu gambaran arsitektur yang akan kita bangun.
Pada setup ini, Redpanda akan bertindak sebagai event broker utama yang menerima dan mendistribusikan event dari producer ke consumer. Semua komunikasi akan diamankan menggunakan kombinasi:
- SASL untuk authentication
- TLS untuk encrypted transport
Secara sederhana, alur komunikasinya akan terlihat seperti ini:
+-------------------+
| Rust Producer |
| SASL + TLS Auth |
+---------+---------+
|
|
v
+-------------------+
| Redpanda |
| Kafka API Broker |
| SASL + TLS Active |
+---------+---------+
|
|
v
+-------------------+
| Rust Consumer |
| SASL + TLS Auth |
+-------------------++-------------------+
| Rust Producer |
| SASL + TLS Auth |
+---------+---------+
|
|
v
+-------------------+
| Redpanda |
| Kafka API Broker |
| SASL + TLS Active |
+---------+---------+
|
|
v
+-------------------+
| Rust Consumer |
| SASL + TLS Auth |
+-------------------+Selain producer dan consumer, kita juga akan menjalankan Redpanda Console untuk membantu observability dan mempermudah monitoring topic, message, dan consumer group secara visual.
Arsitektur final yang akan kita bangun terdiri dari:
- Redpanda Broker
- Menyimpan dan mendistribusikan event
- Menggunakan Kafka-compatible API
- SASL authentication enabled
- TLS encryption enabled
- Redpanda Console
- Web UI untuk observability
- Terhubung secara secure ke broker
- Rust Producer
- Mengirim event ke Redpanda
- Menggunakan koneksi SASL + TLS
- Rust Consumer
- Mengonsumsi event dari topic
- Menggunakan koneksi SASL + TLS
Flow koneksinya akan berjalan seperti berikut:
- Rust producer melakukan authentication menggunakan SASL
- Koneksi diamankan menggunakan TLS handshake
- Event dikirim ke Redpanda broker
- Rust consumer melakukan secure connection yang sama
- Consumer menerima event melalui encrypted channel
Dengan pendekatan ini, local environment tidak lagi hanya sekadar sandbox development biasa, tetapi mulai menyerupai secure event streaming architecture yang umum digunakan pada production system modern.
3. Prerequisites
Sebelum mulai melakukan setup SASL + TLS pada Redpanda, ada beberapa tools dan dependency yang perlu dipastikan sudah tersedia di local environment.
Pada artikel ini saya menggunakan:
- Docker Compose untuk menjalankan infrastructure
- OpenSSL untuk membuat certificate TLS
- Rust untuk membangun producer dan consumer
- Redpanda sebagai Kafka-compatible event broker
Docker & Docker Compose
Pastikan Docker dan Docker Compose sudah terinstall.
Verifikasi dengan:
docker --version
docker compose versiondocker --version
docker compose versionKarena seluruh stack akan dijalankan menggunakan container, Docker menjadi komponen utama dalam setup ini.
Rust & Cargo
Untuk membuat producer dan consumer, kita akan menggunakan Rust.
Install Rust melalui:
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | shcurl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | shLalu verifikasi:
rustc --version
cargo --versionrustc --version
cargo --versionPada artikel ini kita akan menggunakan:
- tokio
- rdkafka
- serde
untuk membangun Kafka client asynchronous dengan koneksi secure.
OpenSSL
OpenSSL digunakan untuk:
- membuat Certificate Authority (CA)
- generate TLS certificate
- signing certificate
- verifikasi certificate chain
Cek apakah OpenSSL tersedia:
openssl versionopenssl versionBasic Kafka Concepts
Walaupun Redpanda kompatibel dengan Kafka API, ada beberapa konsep dasar yang sebaiknya sudah familiar:
- broker
- topic
- producer
- consumer
- consumer group
- listener
- advertised listener
Selain itu, memahami perbedaan berikut juga akan sangat membantu:
FeatureFungsiSASLAuthenticationTLSEncryptionSASL + TLSAuthentication + Secure Transport
Sederhananya:
- SASL memastikan siapa yang boleh masuk
- TLS memastikan komunikasi tidak bisa disadap
Resource Recommendation
Karena setup ini berjalan secara lokal, spesifikasi minimal yang direkomendasikan:
- 2 CPU Core
- 4 GB RAM
- Docker Engine aktif
Walaupun Redpanda cukup ringan dibanding Kafka tradisional, TLS handshake dan encryption tetap menambah overhead tambahan pada broker maupun client.
Pada tahap berikutnya kita akan mulai membuat Certificate Authority dan TLS certificate untuk mengamankan komunikasi antar service.
4. Project Structure
Clone git ini
git clone https://github.com/andriantp/redpanda-sasl_tls.git redpandagit clone https://github.com/andriantp/redpanda-sasl_tls.git redpandaDirectory certificate akan disimpan di:
docker/certsdocker/certsStruktur project yang digunakan pada artikel ini:
├── docker
│ └── sasl.tls.docker-compose.yml
├── Makefile
├── README.md
└── rust
├── Cargo.lock
├── Cargo.toml
├── .env
└── src
├── main.rs
└── redpanda
├── config.rs
├── consumer_async.rs
├── mod.rs
└── producer_async.rs├── docker
│ └── sasl.tls.docker-compose.yml
├── Makefile
├── README.md
└── rust
├── Cargo.lock
├── Cargo.toml
├── .env
└── src
├── main.rs
└── redpanda
├── config.rs
├── consumer_async.rs
├── mod.rs
└── producer_async.rsPenjelasan singkat setiap directory:
Karena kita akan menggunakan TLS untuk mengamankan komunikasi antara client dan broker, kita juga perlu menyiapkan:
- Certificate Authority (CA)
- broker certificate
- private key
- certificate signing process
Daripada menjalankan command OpenSSL satu per satu secara manual, saya menambahkan automation langsung ke dalam Makefile agar proses generate certificate menjadi reproducible dan lebih mudah diulang kapan saja.
Makefile Automation
Agar workflow development lebih praktis, saya menggunakan Makefile untuk menjalankan:
- container management
- monitoring
- topic management
- SASL user management
- cluster health checking
Perhaikan Makefile yang digunakan.
Dengan setup seperti ini, workflow local development menjadi jauh lebih sederhana karena hampir seluruh operasional infrastructure dapat dijalankan melalui command Makefile tanpa perlu mengetik Docker command secara manual berulang kali.
Dengan automation ini, seluruh certificate dapat dibuat hanya dengan satu command:
make generate-certsmake generate-certsHasil akhirnya akan menghasilkan:
ca.crtca.keybroker.crtbroker.key
yang nantinya akan digunakan oleh Redpanda dan Rust client untuk membangun koneksi TLS yang aman.
5. Generating TLS Certificates
Setelah project structure dan automation selesai disiapkan, langkah berikutnya adalah membuat TLS certificate yang akan digunakan untuk mengamankan komunikasi antara:
- Redpanda broker
- Rust producer
- Rust consumer
- Redpanda Console
Pada setup ini kita akan menggunakan:
- self-signed Certificate Authority (CA)
- broker certificate yang ditandatangani oleh CA tersebut
Pendekatan ini sangat umum digunakan untuk:
- local development
- staging environment
- internal infrastructure
- testing secure connection
Walaupun menggunakan self-signed certificate, flow trust dan encryption yang digunakan tetap sama seperti production environment.
5.1 Certificate Authority (CA)
Certificate Authority bertugas sebagai root of trust.
Ketika Rust client mencoba melakukan koneksi TLS ke Redpanda broker, client akan memverifikasi bahwa certificate broker benar-benar ditandatangani oleh CA yang dipercaya.
Pada setup ini, kita akan membuat CA sendiri secara lokal.
Generate CA menggunakan:
make generate-camake generate-caCommand tersebut akan menghasilkan:
docker/certs/
├── ca.crt
└── ca.keydocker/certs/
├── ca.crt
└── ca.keyPenjelasan file:
ca.keyca.key- private key milik Certificate Authority
- digunakan untuk signing certificate
- tidak boleh dibagikan
ca.crtca.crt- public certificate dari CA
- digunakan client untuk memverifikasi broker certificate
5.2 Broker Certificate
Setelah CA selesai dibuat, langkah berikutnya adalah membuat certificate untuk Redpanda broker.
Generate broker certificate menggunakan:
make generate-broker-certmake generate-broker-certHasil akhirnya:
docker/certs/
├── broker.crt
├── broker.csr
├── broker.ext
├── broker.key
├── ca.crt
└── ca.keydocker/certs/
├── broker.crt
├── broker.csr
├── broker.ext
├── broker.key
├── ca.crt
└── ca.keyPenjelasan tambahan:
broker.keybroker.key- private key milik broker
broker.csrbroker.csr- Certificate Signing Request
- digunakan saat proses signing oleh CA
broker.crtbroker.crt- certificate final milik broker
- digunakan Redpanda untuk TLS listener
broker.extbroker.ext- berisi Subject Alternative Name (SAN)
5.3 Subject Alternative Name (SAN)
Salah satu bagian paling penting pada TLS setup modern adalah Subject Alternative Name atau SAN.
Pada setup ini kita menambahkan:
DNS:localhost
IP:127.0.0.1DNS:localhost
IP:127.0.0.1Kenapa ini penting?
Karena saat Rust client melakukan koneksi ke:
localhost:19092localhost:19092TLS layer akan memverifikasi apakah hostname tersebut cocok dengan SAN yang terdapat di dalam certificate broker.
Jika SAN tidak sesuai, biasanya akan muncul error seperti:
- hostname mismatch
- certificate verify failed
- TLS handshake failed
Ini adalah salah satu error TLS yang paling sering terjadi saat local development.
5.4 Generating Everything at Once
Karena seluruh proses sudah di-automation melalui Makefile, kita sebenarnya cukup menjalankan:
make generate-certsmake generate-certsCommand tersebut akan:
- membuat Certificate Authority
- membuat broker private key
- membuat CSR
- melakukan signing certificate
- menghasilkan broker certificate final
Dengan pendekatan ini, proses regenerate TLS certificate menjadi jauh lebih mudah dan reproducible.
5.5 Verifying Certificates
Sebelum certificate digunakan oleh Redpanda, ada baiknya kita memastikan certificate chain sudah valid.
Verifikasi broker certificate menggunakan:
make verifymake verifyJika berhasil, output yang muncul biasanya:
docker/certs/broker.crt: OKdocker/certs/broker.crt: OK
Artinya:
- broker certificate valid
- certificate ditandatangani oleh CA yang benar
- trust chain berhasil diverifikasi
Pada tahap berikutnya kita akan mulai mengintegrasikan certificate ini ke dalam konfigurasi Redpanda dan mengaktifkan listener SASL + TLS pada Docker Compose.5. Configuring Redpanda with SASL + TLS
6. Configuring Redpanda with SASL + TLS
Setelah TLS certificate selesai dibuat, langkah berikutnya adalah mengintegrasikan certificate tersebut ke dalam konfigurasi Redpanda.
Pada tahap ini kita akan:
- mengaktifkan SASL authentication
- mengaktifkan TLS encryption
- menambahkan secure Kafka listener
- menghubungkan Redpanda Console menggunakan koneksi secure
Target akhirnya adalah seluruh komunikasi Kafka berjalan melalui:
- SASL authentication
- TLS encrypted transport
6.1 Mount TLS Certificates
Pertama, certificate yang sudah dibuat perlu dimount ke dalam container Redpanda.
Directory berikut:
docker/certsdocker/certsakan di-mount ke:
/etc/redpanda/certs/etc/redpanda/certsdi dalam container.
6.2 Configure Kafka TLS Listener
Sebelumnya kita menggunakan:
SASL_PLAINTEXTSASL_PLAINTEXTyang berarti:
- authentication aktif
- tetapi traffic masih tidak terenkripsi
Sekarang kita akan menggantinya menjadi:
SASL_SSLSASL_SSLyang berarti:
- SASL untuk authentication
- TLS untuk encryption
6.3 Final Docker Compose
Berikut konfigurasi final docker/sasl.tls.docker-compose.yml yang digunakan pada artikel ini.
6.4 Important TLS Notes
Ada beberapa konfigurasi penting yang perlu diperhatikan:
Pada artikel ini kita hanya mengaktifkan:
- server-side TLS
- encrypted transport
- SASL authentication
Client belum diwajibkan memiliki certificate sendiri.
Karena itu:
require_client_auth=falserequire_client_auth=falsedigunakan untuk menonaktifkan mutual TLS (mTLS).
6.5 Why This Matters
Dengan konfigurasi ini:
- credential SASL tidak lagi dikirim plaintext
- payload Kafka terenkripsi
- broker identity dapat diverifikasi
- local environment menjadi lebih production-like
Ini adalah fondasi penting sebelum masuk ke:
- multi-node cluster
- ACL authorization
- mTLS
- service mesh
- secure distributed systems architecture
Pada tahap berikutnya kita akan menjalankan stack dan memverifikasi bahwa koneksi SASL + TLS berhasil aktif.
7. Starting the Stack
Setelah seluruh konfigurasi SASL + TLS selesai disiapkan, sekarang saatnya menjalankan infrastructure dan memastikan seluruh service dapat berjalan dengan benar.
Pada tahap ini kita akan:
- generate TLS certificate
- menjalankan Redpanda
- menjalankan Redpanda Console
- membuat SASL user
- memverifikasi broker health
- memastikan TLS listener aktif
7.1 Generate TLS Certificates
Jika sebelumnya belum menjalankan certificate generation, generate seluruh TLS assets menggunakan:
make generate-certsmake generate-certsPastikan directory berikut sudah terisi:
docker/certs/
├── broker.crt
├── broker.key
├── ca.crt
└── ca.keydocker/certs/
├── broker.crt
├── broker.key
├── ca.crt
└── ca.keyPermission file:
make permissionmake permission7.2 Start Redpanda
Jalankan Redpanda broker menggunakan:
make up-redpandamake up-redpandaJika berhasil, container Redpanda akan berjalan di background.
Verifikasi menggunakan:
make psmake psOutput kurang lebih akan terlihat seperti:
CONTAINER ID IMAGE STATUS
xxxxxxxxxxxx docker.redpanda.com/redpandadata/redpanda UpCONTAINER ID IMAGE STATUS
xxxxxxxxxxxx docker.redpanda.com/redpandadata/redpanda Up7.3 Create SASL User
Karena SASL authentication sudah aktif, kita perlu membuat user terlebih dahulu sebelum client dapat melakukan koneksi.
Buat user menggunakan:
make create-usermake create-userUser yang dibuat:
- username:
admin - password:
admin-password - mechanism:
SCRAM-SHA-256
7.4 Start Redpanda Console
Setelah broker berhasil berjalan, jalankan Redpanda Console:
make up-consolemake up-consoleConsole akan tersedia di:
http://localhost:8080http://localhost:8080Jika konfigurasi TLS dan SASL berhasil, Console akan otomatis terhubung ke broker secara secure.
7.5 Verify Cluster Health
Sekarang kita perlu memastikan broker dapat menerima koneksi SASL + TLS dengan benar.
Jalankan:
make healthmake healthJika berhasil, output akan menampilkan informasi cluster Redpanda.
Jika muncul error seperti:
tls: failed to verify certificatetls: failed to verify certificateatau:
x509: certificate signed by unknown authorityx509: certificate signed by unknown authoritybiasanya penyebabnya:
- CA certificate belum digunakan client
- SAN tidak sesuai
- broker certificate invalid
- volume certs belum termount dengan benar
Cek kembali:
broker.crtca.crtbroker.ext- mount path Docker Compose
7.7 Checking Redpanda Logs
Untuk memastikan TLS listener aktif, cek logs Redpanda:
make logs-redpandamake logs-redpandaBiasanya akan terlihat listener Kafka berjalan di:
0.0.0.0:9092
0.0.0.0:190920.0.0.0:9092
0.0.0.0:19092dan TLS subsystem berhasil diinisialisasi.
7.8 What We Have Now
Pada titik ini kita sudah memiliki:
- secure Kafka-compatible broker
- SASL authentication
- TLS encrypted transport
- secure Redpanda Console
- reusable certificate infrastructure
Artinya local environment sekarang sudah jauh lebih mendekati secure production architecture dibanding setup development biasa yang masih menggunakan plaintext connection.
Pada tahap berikutnya kita akan mulai membangun Rust producer yang dapat terhubung ke Redpanda menggunakan koneksi SASL + TLS secara aman.
8. Verifying TLS Encryption
Setelah seluruh stack berhasil berjalan menggunakan SASL_SSL, langkah berikutnya adalah memastikan bahwa komunikasi antara client dan broker benar-benar terenkripsi.
Pada distributed system modern, service yang berhasil startup belum tentu berarti koneksinya sudah aman. Karena itu, validasi TLS menjadi bagian penting untuk memastikan:
- encrypted transport benar-benar aktif
- certificate broker valid
- trust chain berjalan dengan benar
- client dan broker menggunakan protocol yang sesuai
Pada tahap ini kita akan melakukan beberapa verifikasi menggunakan OpenSSL dan observasi langsung terhadap TLS handshake.
8.1 Verifying TLS Handshake
Cara paling sederhana untuk memverifikasi TLS listener adalah menggunakan openssl s_client.
Jalankan:
make handshakemake handshakeJika TLS berhasil aktif, output akan menampilkan:
- certificate chain
- broker certificate
- TLS negotiation
- cipher suite yang digunakan
Biasanya akan muncul bagian seperti:
SSL handshake has read ...
Verify return code: 0 (ok)SSL handshake has read ...
Verify return code: 0 (ok)
Artinya:
- broker certificate valid
- CA berhasil dipercaya
- TLS handshake berhasil dilakukan
- koneksi terenkripsi berhasil dibangun
8.2 Inspecting Broker Certificate
Pada output OpenSSL kita juga dapat melihat detail certificate broker.
Contoh:
subject=CN = localhost
issuer=CN = redpanda-casubject=CN = localhost
issuer=CN = redpanda-caPenjelasan:
subject
identitas broker certificate
issuer
Certificate Authority yang melakukan signing
Karena pada artikel ini kita menggunakan self-signed CA lokal, issuer akan mengarah ke:
redpanda-caredpanda-ca8.3 Subject Alternative Name (SAN)
Salah satu bagian paling penting dalam TLS modern adalah Subject Alternative Name (SAN).
Pada setup ini kita menambahkan:
DNS:localhost
DNS:redpanda
IP:127.0.0.1DNS:localhost
DNS:redpanda
IP:127.0.0.1SAN digunakan client untuk memverifikasi bahwa hostname broker benar-benar cocok dengan certificate yang diberikan saat TLS handshake berlangsung.
Tanpa SAN yang benar, biasanya akan muncul error seperti:
certificate is valid for localhost, not redpandacertificate is valid for localhost, not redpandaIni adalah salah satu masalah paling umum saat setup TLS pada Docker environment karena:
- internal hostname Docker berbeda
- external hostname berbeda
- certificate hanya mengenali sebagian hostname
8.4 Common TLS Misconfiguration
Selama proses setup secure distributed systems, ada beberapa error TLS yang cukup sering muncul.
TLS Listener Mismatch
Contoh:
client is using TLS when the broker is not expecting itclient is using TLS when the broker is not expecting itBiasanya terjadi karena:
- broker masih menggunakan plaintext listener
- protocol listener mismatch
- listener belum attach TLS configuration
Unknown Certificate Authority
Contoh:
certificate signed by unknown authoritycertificate signed by unknown authorityBiasanya terjadi karena:
- CA certificate belum digunakan client
- truststore belum dikonfigurasi
Hostname Verification Failed
Contoh:
hostname mismatchhostname mismatchBiasanya terjadi karena:
- SAN tidak sesuai
- Docker internal hostname berbeda dengan external hostname
- certificate dibuat hanya untuk
localhost
8.5 Why TLS Verification Matters
Pada production environment, TLS bukan hanya sekadar fitur tambahan.
TLS membantu memastikan:
- credential tidak dikirim plaintext
- payload event terenkripsi
- broker identity dapat diverifikasi
- komunikasi antar service lebih aman
Walaupun setup pada artikel ini masih menggunakan self-signed certificate, proses trust dan encryption yang digunakan tetap sama seperti production-grade secure infrastructure modern.
Pada tahap berikutnya kita akan mulai membangun Rust producer yang dapat terhubung ke Redpanda menggunakan koneksi SASL + TLS secara aman.
9. Building Secure Rust Kafka Clients
Setelah secure Redpanda stack berhasil berjalan, langkah berikutnya adalah menghubungkan Rust application menggunakan koneksi:
- SASL authentication
- TLS encryption
- Kafka-compatible API
Pada artikel sebelumnya, producer dan consumer masih menggunakan:
SASL_PLAINTEXTSASL_PLAINTEXTyang berarti authentication aktif tetapi komunikasi masih belum terenkripsi.
Sekarang kita akan mengubah Rust client agar menggunakan:
SASL_SSLSASL_SSLsehingga seluruh komunikasi Kafka berjalan melalui encrypted transport.
9.1 Environment Configuration
Agar konfigurasi lebih fleksibel dan tidak hardcoded di source code, seluruh credential dan TLS configuration disimpan di .env.
Berikut environment configuration yang digunakan:
REDPANDA_BROKER=localhost:19092
REDPANDA_TOPIC=rust-sasl_tls
REDPANDA_GROUP_ID=group-1
REDPANDA_USER=admin
REDPANDA_PASSWORD=admin-password
REDPANDA_TLS=../docker/certs/ca.crtREDPANDA_BROKER=localhost:19092
REDPANDA_TOPIC=rust-sasl_tls
REDPANDA_GROUP_ID=group-1
REDPANDA_USER=admin
REDPANDA_PASSWORD=admin-password
REDPANDA_TLS=../docker/certs/ca.crtPenjelasan:
REDPANDA_BROKER- broker address dengan TLS listener aktif
REDPANDA_TLS- path menuju CA certificate
- digunakan client untuk memverifikasi broker certificate
Dengan pendekatan ini, environment dapat diganti tanpa perlu mengubah source code Rust secara langsung.
9.2 Secure Producer Configuration
Pada producer, perubahan utama berada pada connection layer.
Sebelumnya:
SASL_PLAINTEXT
Sekarang:
SASL_SSL
Producer configuration:
let producer: FutureProducer = ClientConfig::new()
// --- connection ---
.set("bootstrap.servers", &config.broker)
// --- TLS + SASL ---
.set("security.protocol", "SASL_SSL")
.set("sasl.mechanism", "SCRAM-SHA-256")
.set("sasl.username", &config.username)
.set("sasl.password", &config.password)
// --- TLS ---
.set("ssl.ca.location", &config.tls)
.create()?;let producer: FutureProducer = ClientConfig::new()
// --- connection ---
.set("bootstrap.servers", &config.broker)
// --- TLS + SASL ---
.set("security.protocol", "SASL_SSL")
.set("sasl.mechanism", "SCRAM-SHA-256")
.set("sasl.username", &config.username)
.set("sasl.password", &config.password)
// --- TLS ---
.set("ssl.ca.location", &config.tls)
.create()?;Konfigurasi penting:
SASL_SSL
mengaktifkan TLS + SASL sekaligus
ssl.ca.location
memberitahu client CA mana yang dipercaya untuk memverifikasi broker certificate
Tanpa CA certificate ini, Rust client akan menolak self-signed certificate yang digunakan broker.
9.3 Secure Consumer Configuration
Consumer menggunakan konfigurasi secure yang hampir sama dengan producer.
Perbedaannya hanya pada:
- consumer group
- offset handling
- commit behavior
Consumer configuration:
let consumer: StreamConsumer = ClientConfig::new()
// --- connection ---
.set("bootstrap.servers", &config.broker)
// --- TLS + SASL ---
.set("security.protocol", "SASL_SSL")
.set("sasl.mechanism", "SCRAM-SHA-256")
.set("sasl.username", &config.username)
.set("sasl.password", &config.password)
// --- TLS ---
.set("ssl.ca.location", &config.tls)
// --- consumer group ---
.set("group.id", &config.group_id)
// --- earliest offset ---
.set("auto.offset.reset", "earliest")
// --- manual commit ---
.set("enable.auto.commit", "false")
.create()?;let consumer: StreamConsumer = ClientConfig::new()
// --- connection ---
.set("bootstrap.servers", &config.broker)
// --- TLS + SASL ---
.set("security.protocol", "SASL_SSL")
.set("sasl.mechanism", "SCRAM-SHA-256")
.set("sasl.username", &config.username)
.set("sasl.password", &config.password)
// --- TLS ---
.set("ssl.ca.location", &config.tls)
// --- consumer group ---
.set("group.id", &config.group_id)
// --- earliest offset ---
.set("auto.offset.reset", "earliest")
// --- manual commit ---
.set("enable.auto.commit", "false")
.create()?;Karena producer dan consumer menggunakan security layer yang sama, debugging dan configuration management menjadi jauh lebih konsisten.
9.4 Why This Matters
Dengan perubahan ini, Rust Kafka client sekarang:
- menggunakan encrypted transport
- melakukan broker certificate verification
- mengirim credential melalui secure channel
- mendukung production-like secure communication
Walaupun setup ini masih menggunakan self-signed certificate, flow TLS yang digunakan tetap sama seperti production environment modern.
Perbedaannya hanya pada Certificate Authority yang digunakan.
Pada tahap berikutnya kita akan melakukan end-to-end testing untuk memastikan producer dan consumer dapat saling berkomunikasi melalui koneksi SASL + TLS secara aman.
10. End-to-End Secure Messaging
Setelah seluruh secure configuration selesai diimplementasikan, langkah terakhir adalah memastikan producer dan consumer dapat saling berkomunikasi melalui koneksi:
- SASL authenticated
- TLS encrypted
- Kafka-compatible
Pada tahap ini kita akan menjalankan Rust producer dan consumer secara langsung untuk memverifikasi bahwa secure event streaming berjalan end-to-end.
Create topic
Masuk ke ui console http://localhost:8080/
Pilih menu:
TopicsTopicslalu klik:
Create TopicCreate TopicForm pembuatan topic akan muncul seperti berikut:
Konfigurasi Topic
Pada artikel ini, saya menggunakan konfigurasi sederhana:
lalu klik:
CreateCreate
Sekarang topic-nya sudah muncul
Bisa juga cek dengan :
make list-topicsmake list-topics
10.1 Running the Consumer
Pertama, jalankan consumer terlebih dahulu.
$ cd rust
$ cargo run -- async-consumer$ cd rust
$ cargo run -- async-consumerJika TLS dan SASL berhasil dikonfigurasi dengan benar, consumer akan berhasil:
- melakukan TLS handshake
- memverifikasi broker certificate
- melakukan SASL authentication
- subscribe ke topic Kafka
Biasanya log akan menunjukkan bahwa consumer berhasil connect ke broker.
10.2 Running the Producer
Setelah consumer aktif, jalankan producer untuk mengirim event ke Redpanda.
Jalankan producer.
$ cd rust
$ cargo run -- async-producer$ cd rust
$ cargo run -- async-producer
Saat producer mengirim message:
- TLS handshake dilakukan terlebih dahulu
- broker certificate diverifikasi menggunakan CA
- SASL authentication dijalankan
- payload event dikirim melalui encrypted channel
Karena seluruh komunikasi sekarang menggunakan:
SASL_SSLSASL_SSLcredential dan payload tidak lagi berjalan dalam plaintext.
10.3 Verifying Message Flow
Jika semuanya berjalan dengan benar:
- producer berhasil publish message
- consumer menerima event
- offset consumer bertambah
- topic dapat terlihat di Redpanda Console
Kita juga dapat memverifikasi activity topic melalui:
http://localhost:8080http://localhost:8080
Pada tahap ini, local environment sudah berhasil menjalankan:
- secure Kafka-compatible broker
- authenticated connection
- encrypted event streaming
- Rust async producer
- Rust async consumer
Di consumer :
10.4 What Happens Under the Hood
Walaupun producer dan consumer terlihat sederhana dari sisi code, sebenarnya ada beberapa proses penting yang terjadi saat koneksi dibuat.
Secara sederhana flow-nya seperti berikut:
Rust Client
│
├── TLS Handshake
│
├── Verify Broker Certificate
│
├── SASL Authentication
│
├── Establish Secure Channel
│
└── Publish / Consume Kafka MessagesRust Client
│
├── TLS Handshake
│
├── Verify Broker Certificate
│
├── SASL Authentication
│
├── Establish Secure Channel
│
└── Publish / Consume Kafka MessagesArtinya:
- broker identity diverifikasi terlebih dahulu
- credential dikirim melalui encrypted transport
- Kafka payload berjalan di atas secure connection
Ini adalah pola yang umum digunakan pada production-grade event streaming systems modern.
10.5 Final Result
Pada titik ini kita sudah berhasil membangun:
- secure Redpanda stack
- SASL authentication
- TLS encryption
- secure Rust Kafka client
- end-to-end encrypted event streaming
Walaupun setup ini masih berjalan secara lokal menggunakan self-signed certificate, arsitektur dan flow security yang digunakan tetap sangat mirip dengan production environment modern.
12. Common Issues
Saat melakukan setup secure Kafka-compatible infrastructure menggunakan SASL + TLS, ada beberapa error yang cukup sering muncul, terutama saat menggunakan self-signed certificate dan Docker-based environment.
Pada artikel ini saya juga mengalami beberapa issue yang cukup umum terjadi pada distributed systems berbasis TLS.
Berikut beberapa masalah yang paling sering ditemui beserta penyebabnya.
12.1 Client Using TLS While Broker Expects Plaintext
Contoh error:
client is using TLS when the broker is not expecting itclient is using TLS when the broker is not expecting itatau:
broker closed the connection immediately during api versions negotiationbroker closed the connection immediately during api versions negotiationBiasanya terjadi karena:
- broker masih menggunakan plaintext listener
- protocol listener mismatch
- client menggunakan
SASL_SSL - broker masih berjalan di
SASL_PLAINTEXT
Solusi:
- pastikan listener menggunakan:
SASL_SSL- pastikan TLS listener benar-benar aktif pada Redpanda
12.2 Hostname Verification Failed
Contoh error:
certificate is valid for localhost, not redpandacertificate is valid for localhost, not redpandaBiasanya terjadi karena:
- SAN certificate tidak sesuai
- hostname internal Docker berbeda dengan hostname external
Pada setup ini:
- external hostname:
localhost
internal hostname:
redpanda
Solusi: tambahkan SAN seperti:
DNS:localhost
DNS:redpanda
IP:127.0.0.1DNS:localhost
DNS:redpanda
IP:127.0.0.112.3 Unknown Certificate Authority
Contoh:
certificate signed by unknown authoritycertificate signed by unknown authorityBiasanya terjadi karena:
- client belum menggunakan CA certificate
- truststore belum dikonfigurasi
Solusi: pastikan Rust client menggunakan:
.set("ssl.ca.location", &config.tls).set("ssl.ca.location", &config.tls)dan:
config.tlsconfig.tlsmengarah ke:
ca.crtca.crt12.4 Permission Denied on TLS Certificate
Contoh:
Permission denied ["/etc/redpanda/certs/broker.key"]Permission denied ["/etc/redpanda/certs/broker.key"]Biasanya terjadi karena:
- Docker container tidak memiliki permission membaca private key
- OpenSSL generate file dengan permission terlalu restrictive
Solusi:
chmod 644 docker/certs/*.key
chmod 644 docker/certs/*.crtchmod 644 docker/certs/*.key
chmod 644 docker/certs/*.crtUntuk production environment biasanya permission akan dikelola lebih ketat menggunakan:
- Docker secrets
- Kubernetes secrets
- Vault
- dedicated secret management system
12.5 TLS Handshake Failed
Contoh:
tls: failed to verify certificatetls: failed to verify certificateBiasanya terjadi karena:
- certificate invalid
- trust chain rusak
- CA mismatch
- SAN mismatch
Verifikasi certificate menggunakan:
openssl verify \
-CAfile docker/certs/ca.crt \
docker/certs/broker.crtopenssl verify \
-CAfile docker/certs/ca.crt \
docker/certs/broker.crt12.6 Why These Problems Are Common
TLS setup pada distributed system memang sering menjadi salah satu bagian paling tricky karena melibatkan:
- certificate trust
- hostname verification
- listener configuration
- protocol negotiation
- Docker networking
- internal vs external hostname
Terutama pada local development environment, banyak issue muncul bukan karena servicenya rusak, tetapi karena:
- hostname mismatch
- certificate mismatch
- protocol mismatch
Dan sebagian besar error TLS biasanya terlihat mirip walaupun akar masalahnya berbeda.
Karena itu, memahami flow TLS handshake dan trust verification sangat membantu saat melakukan debugging secure distributed systems.
13. Production Considerations
Walaupun setup pada artikel ini berjalan secara lokal menggunakan Docker Compose dan self-signed certificate, arsitektur security yang digunakan sebenarnya sudah cukup mendekati production environment modern.
Namun, sebelum digunakan pada real production system, ada beberapa hal penting yang perlu diperhatikan.
13.1 Avoid Self-Signed Certificates in Production
Pada artikel ini kita menggunakan self-signed Certificate Authority untuk mempermudah local development.
Pendekatan ini cukup baik untuk:
- local environment
- staging
- internal testing
- learning purpose
Tetapi pada production environment, biasanya certificate akan dikeluarkan oleh:
- trusted internal CA
- enterprise PKI
- cloud certificate manager
- public Certificate Authority
Tujuannya agar:
- trust management lebih terpusat
- certificate rotation lebih mudah
- security policy lebih konsisten
13.2 Enable Mutual TLS (mTLS)
Pada setup ini kita menggunakan:
require_client_auth=falserequire_client_auth=falseArtinya:
- hanya broker yang memiliki certificate
- client belum diwajibkan memiliki certificate sendiri
Pada production system, banyak organisasi menggunakan:
mTLSmTLSatau mutual TLS.
Dengan mTLS:
- broker memverifikasi client
- client memverifikasi broker
- authentication menjadi dua arah
Ini sangat umum digunakan pada:
- internal microservices
- financial systems
- service mesh architecture
- zero-trust environment
13.3 Secret Management
Pada artikel ini credential masih disimpan di:
.env- Docker Compose
- local configuration
Untuk production environment, sebaiknya gunakan dedicated secret management seperti:
- HashiCorp Vault
- Kubernetes Secrets
- AWS Secrets Manager
- GCP Secret Manager
Tujuannya:
- menghindari hardcoded credential
- mempermudah credential rotation
- membatasi akses secret
13.4 Multi-Broker Redpanda Cluster
Setup pada artikel ini hanya menggunakan:
single-node Redpandasingle-node RedpandaPada production environment biasanya cluster terdiri dari beberapa broker untuk:
- high availability
- fault tolerance
- replication
- better scalability
Contoh:
- 3-node cluster
- replication factor > 1
- distributed partition placement
13.5 Observability and Monitoring
Pada distributed system modern, observability menjadi bagian yang sangat penting.
Selain Redpanda Console, production environment biasanya menambahkan:
- Prometheus
- Grafana
- Loki
- OpenTelemetry
- centralized logging
Tujuannya:
- monitoring throughput
- consumer lag tracking
- broker health monitoring
- debugging distributed workloads
13.6 Access Control and Authorization
Pada artikel ini kita hanya menggunakan:
- SASL authentication
Namun production system biasanya juga menambahkan:
- ACL (Access Control List)
- role-based authorization
- topic-level permission
Tujuannya agar:
- producer tidak bisa mengakses seluruh topic
- consumer hanya dapat membaca topic tertentu
- access lebih granular
13.7 Certificate Rotation
TLS certificate memiliki masa berlaku.
Karena itu production environment biasanya memiliki mekanisme:
- certificate renewal
- automatic rotation
- truststore update
- zero-downtime certificate replacement
Hal ini penting untuk menghindari:
- expired certificate
- broker outage
- failed TLS handshake
13.8 Beyond Local Development
Walaupun setup pada artikel ini terlihat sederhana, fondasi yang dibangun sebenarnya sudah mencakup banyak konsep penting pada secure distributed systems:
- encrypted transport
- authenticated messaging
- trust verification
- secure event streaming
- infrastructure automation
Dan konsep-konsep ini tetap relevan saat berpindah ke:
- Kubernetes
- cloud-native infrastructure
- multi-region event streaming
- production event-driven architecture
Karena pada akhirnya, keamanan komunikasi antar service bukan lagi sekadar tambahan, tetapi sudah menjadi bagian fundamental dari desain distributed system modern.
14. Closing
Pada artikel ini kita berhasil membangun secure local event streaming stack menggunakan:
- Redpanda
- Docker Compose
- SASL authentication
- TLS encryption
- Rust Kafka client
Kita juga berhasil menghubungkan Rust producer dan consumer menggunakan:
SASL_SSLSASL_SSLsehingga komunikasi Kafka tidak lagi berjalan dalam plaintext.
Sepanjang proses setup, kita juga membahas beberapa aspek penting pada secure distributed systems seperti:
- TLS handshake
- certificate verification
- Subject Alternative Name (SAN)
- hostname mismatch
- secure listener configuration
- trust chain validation
Walaupun environment yang digunakan masih bersifat lokal dan menggunakan self-signed certificate, pola arsitektur yang dibangun tetap sangat mirip dengan production-grade secure messaging systems modern.
Dan justru di sinilah local development menjadi menarik: kita bisa memahami bagaimana security layer bekerja secara langsung sebelum masuk ke environment production yang jauh lebih kompleks.
Pada akhirnya, secure event streaming bukan hanya tentang membuat broker dapat berjalan, tetapi juga memastikan:
- identity dapat diverifikasi
- credential tidak bocor
- payload terenkripsi
- komunikasi antar service berjalan aman
Karena di distributed system modern, security bukan lagi optional feature, tetapi bagian fundamental dari desain sistem itu sendiri.
Beberapa eksplorasi berikutnya yang menarik untuk dicoba:
- Mutual TLS (mTLS)
- ACL authorization
- Multi-node Redpanda cluster
- Schema Registry
- Kafka Connect
- OpenTelemetry integration
- Distributed tracing
- Kubernetes deployment
- Production secret management
Semoga artikel ini membantu memahami bagaimana membangun secure Kafka-compatible event streaming environment secara lebih praktikal menggunakan Redpanda dan Rust.