[RedPanda] Securing Redpanda with SASL and TLS in Docker Compose

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 version

docker --version
docker compose version

Karena 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 | sh

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Lalu verifikasi:

rustc --version
cargo --version

rustc --version
cargo --version

Pada 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 version

openssl version

Basic 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 redpanda

git clone https://github.com/andriantp/redpanda-sasl_tls.git redpanda

Directory certificate akan disimpan di:

docker/certs

docker/certs

Struktur 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.rs

Penjelasan 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-certs

make generate-certs

Hasil akhirnya akan menghasilkan:

ca.crt
ca.key
broker.crt
broker.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-ca

make generate-ca

Command tersebut akan menghasilkan:

docker/certs/
├── ca.crt
└── ca.key

docker/certs/
├── ca.crt
└── ca.key

Penjelasan file:

ca.key

ca.key

private key milik Certificate Authority
digunakan untuk signing certificate
tidak boleh dibagikan

ca.crt

ca.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-cert

make generate-broker-cert

Hasil akhirnya:

docker/certs/
├── broker.crt
├── broker.csr
├── broker.ext
├── broker.key
├── ca.crt
└── ca.key

docker/certs/
├── broker.crt
├── broker.csr
├── broker.ext
├── broker.key
├── ca.crt
└── ca.key

Penjelasan tambahan:

broker.key

broker.key

private key milik broker

broker.csr

broker.csr

Certificate Signing Request
digunakan saat proses signing oleh CA

broker.crt

broker.crt

certificate final milik broker
digunakan Redpanda untuk TLS listener

broker.ext

broker.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.1

DNS:localhost
IP:127.0.0.1

Kenapa ini penting?

Karena saat Rust client melakukan koneksi ke:

localhost:19092

localhost:19092

TLS 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-certs

make generate-certs

Command 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 verify

make verify

Jika berhasil, output yang muncul biasanya:

docker/certs/broker.crt: OK

docker/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/certs

docker/certs

akan di-mount ke:

/etc/redpanda/certs

/etc/redpanda/certs

di dalam container.

6.2 Configure Kafka TLS Listener

Sebelumnya kita menggunakan:

SASL_PLAINTEXT

SASL_PLAINTEXT

yang berarti:

authentication aktif
tetapi traffic masih tidak terenkripsi

Sekarang kita akan menggantinya menjadi:

SASL_SSL

SASL_SSL

yang 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=false

require_client_auth=false

digunakan 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-certs

make generate-certs

Pastikan directory berikut sudah terisi:

docker/certs/
├── broker.crt
├── broker.key
├── ca.crt
└── ca.key

docker/certs/
├── broker.crt
├── broker.key
├── ca.crt
└── ca.key

Permission file:

make permission

make permission

7.2 Start Redpanda

Jalankan Redpanda broker menggunakan:

make up-redpanda

make up-redpanda

Jika berhasil, container Redpanda akan berjalan di background.

Verifikasi menggunakan:

make ps

make ps

Output kurang lebih akan terlihat seperti:

CONTAINER ID   IMAGE                                          STATUS
xxxxxxxxxxxx   docker.redpanda.com/redpandadata/redpanda      Up

CONTAINER ID   IMAGE                                          STATUS
xxxxxxxxxxxx   docker.redpanda.com/redpandadata/redpanda      Up

7.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-user

make create-user

User 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-console

make up-console

Console akan tersedia di:

http://localhost:8080

http://localhost:8080

Jika 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 health

make health

Jika berhasil, output akan menampilkan informasi cluster Redpanda.

Jika muncul error seperti:

tls: failed to verify certificate

tls: failed to verify certificate

atau:

x509: certificate signed by unknown authority

x509: certificate signed by unknown authority

biasanya penyebabnya:

CA certificate belum digunakan client
SAN tidak sesuai
broker certificate invalid
volume certs belum termount dengan benar

Cek kembali:

broker.crt
ca.crt
broker.ext
mount path Docker Compose

7.7 Checking Redpanda Logs

Untuk memastikan TLS listener aktif, cek logs Redpanda:

make logs-redpanda

make logs-redpanda

Biasanya akan terlihat listener Kafka berjalan di:

0.0.0.0:9092
0.0.0.0:19092

0.0.0.0:9092
0.0.0.0:19092

dan 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 handshake

make handshake

Jika 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-ca

subject=CN = localhost
issuer=CN = redpanda-ca

Penjelasan:

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-ca

redpanda-ca

8.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.1

DNS:localhost
DNS:redpanda
IP:127.0.0.1

SAN 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 redpanda

certificate is valid for localhost, not redpanda

Ini 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 it

client is using TLS when the broker is not expecting it

Biasanya terjadi karena:

broker masih menggunakan plaintext listener
protocol listener mismatch
listener belum attach TLS configuration

Unknown Certificate Authority

Contoh:

certificate signed by unknown authority

certificate signed by unknown authority

Biasanya terjadi karena:

CA certificate belum digunakan client
truststore belum dikonfigurasi

Hostname Verification Failed

Contoh:

hostname mismatch

hostname mismatch

Biasanya 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_PLAINTEXT

SASL_PLAINTEXT

yang berarti authentication aktif tetapi komunikasi masih belum terenkripsi.

Sekarang kita akan mengubah Rust client agar menggunakan:

SASL_SSL

SASL_SSL

sehingga 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.crt

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.crt

Penjelasan:

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:

Topics

Topics

lalu klik:

Create Topic

Create Topic

Form pembuatan topic akan muncul seperti berikut:

Konfigurasi Topic

Pada artikel ini, saya menggunakan konfigurasi sederhana:

lalu klik:

Create

Create

Sekarang topic-nya sudah muncul

Bisa juga cek dengan :

make list-topics

make list-topics

10.1 Running the Consumer

Pertama, jalankan consumer terlebih dahulu.

$ cd rust
$ cargo run -- async-consumer

$ cd rust
$ cargo run -- async-consumer

Jika 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_SSL

SASL_SSL

credential 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:8080

http://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 Messages

Rust Client
    │
    ├── TLS Handshake
    │
    ├── Verify Broker Certificate
    │
    ├── SASL Authentication
    │
    ├── Establish Secure Channel
    │
    └── Publish / Consume Kafka Messages

Artinya:

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 it

client is using TLS when the broker is not expecting it

atau:

broker closed the connection immediately during api versions negotiation

broker closed the connection immediately during api versions negotiation

Biasanya 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 redpanda

certificate is valid for localhost, not redpanda

Biasanya 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.1

DNS:localhost
DNS:redpanda
IP:127.0.0.1

12.3 Unknown Certificate Authority

Contoh:

certificate signed by unknown authority

certificate signed by unknown authority

Biasanya 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.tls

config.tls

mengarah ke:

ca.crt

ca.crt

12.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/*.crt

chmod 644 docker/certs/*.key
chmod 644 docker/certs/*.crt

Untuk 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 certificate

tls: failed to verify certificate

Biasanya terjadi karena:

certificate invalid
trust chain rusak
CA mismatch
SAN mismatch

Verifikasi certificate menggunakan:

openssl verify \
  -CAfile docker/certs/ca.crt \
  docker/certs/broker.crt

openssl verify \
  -CAfile docker/certs/ca.crt \
  docker/certs/broker.crt

12.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=false

require_client_auth=false

Artinya:

hanya broker yang memiliki certificate
client belum diwajibkan memiliki certificate sendiri

Pada production system, banyak organisasi menggunakan:

mTLS

mTLS

atau 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 Redpanda

single-node Redpanda

Pada 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_SSL

SASL_SSL

sehingga 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.

Playlist :

Getting Started Guide for Beginners -> here
Advanced Broker Behavior -> here
Rust Performance & Backpressure Engineering -> here
Observability Stack untuk Redpanda -> here
CDC Pipeline dengan Redpanda -> here
Stream Processing Native -> here
SASL -> here
SASL-TLS -> here

Contents

1. Introduction

2. Architecture Overview

3. Prerequisites

Docker & Docker Compose

Rust & Cargo

OpenSSL

Basic Kafka Concepts

Resource Recommendation

4. Project Structure

Makefile Automation

5. Generating TLS Certificates

5.1 Certificate Authority (CA)

5.2 Broker Certificate

5.3 Subject Alternative Name (SAN)

5.4 Generating Everything at Once

5.5 Verifying Certificates

6. Configuring Redpanda with SASL + TLS

6.1 Mount TLS Certificates

6.2 Configure Kafka TLS Listener

6.3 Final Docker Compose

6.4 Important TLS Notes

6.5 Why This Matters

7. Starting the Stack

7.1 Generate TLS Certificates

7.2 Start Redpanda

7.3 Create SASL User

7.4 Start Redpanda Console

7.5 Verify Cluster Health

7.7 Checking Redpanda Logs

7.8 What We Have Now

8. Verifying TLS Encryption

8.1 Verifying TLS Handshake

8.2 Inspecting Broker Certificate

8.3 Subject Alternative Name (SAN)

8.4 Common TLS Misconfiguration

TLS Listener Mismatch

Unknown Certificate Authority

Hostname Verification Failed

8.5 Why TLS Verification Matters

9. Building Secure Rust Kafka Clients

9.1 Environment Configuration

9.2 Secure Producer Configuration

9.3 Secure Consumer Configuration

9.4 Why This Matters

10. End-to-End Secure Messaging

Create topic

10.1 Running the Consumer

10.2 Running the Producer

10.3 Verifying Message Flow

10.4 What Happens Under the Hood

10.5 Final Result

12. Common Issues

12.1 Client Using TLS While Broker Expects Plaintext

12.2 Hostname Verification Failed

12.3 Unknown Certificate Authority

12.4 Permission Denied on TLS Certificate

12.5 TLS Handshake Failed

12.6 Why These Problems Are Common

13. Production Considerations

13.1 Avoid Self-Signed Certificates in Production

13.2 Enable Mutual TLS (mTLS)

13.3 Secret Management

13.4 Multi-Broker Redpanda Cluster

13.5 Observability and Monitoring

13.6 Access Control and Authorization

13.7 Certificate Rotation

13.8 Beyond Local Development

14. Closing

Playlist :