Halaman ini menjelaskan metode autentikasi yang didukung untuk aplikasi klien yang terhubung ke broker Google Cloud Managed Service for Apache Kafka.
Untuk aplikasi klien Google Cloud Managed Service for Apache Kafka yang berjalan di layanan Google Cloud seperti Google Kubernetes Engine, Compute Engine, Cloud Run, atau Cloud Run Functions, Anda memiliki opsi autentikasi berikut:
SASL/OAUTHBEARER (direkomendasikan): ini adalah metode yang paling lancar dan aman untuk klien dalam Google Cloud. Aplikasi ini menggunakan Kredensial Default Aplikasi (ADC) untuk menemukan identitas akun layanan yang terkait dengan lingkungan secara otomatis. Dengan demikian, Anda tidak perlu mengelola dan mendistribusikan file kredensial statis seperti kunci akun layanan.
SASL/PLAIN: metode ini berguna untuk pengembangan awal. Klien melakukan autentikasi menggunakan kunci akun layanan yang berlaku lama.
mTLS: ini adalah opsi jika standar organisasi Anda adalah autentikasi berbasis sertifikat. Aplikasi Anda di Google Cloud dikonfigurasi dengan sertifikat dan kunci klien.
Untuk aplikasi klien yang berjalan di luar Google Cloud, seperti di pusat data lokal atau di penyedia cloud lain, pertimbangkan metode autentikasi berikut. Pilih metode terbaik berdasarkan postur keamanan dan infrastruktur identitas yang ada di organisasi Anda.
Workload Identity Federation dengan SASL/OAUTHBEARER (direkomendasikan): ini adalah metode paling aman untuk klien eksternal. Dengan fitur ini, Anda dapat memberikan kemampuan kepada identitas dari sistem eksternal, seperti AWS, Microsoft Azure, atau penyedia identitas lokal seperti ADFS, untuk meniru identitas akun layananGoogle Cloud . Daripada mengelola kunci akun layanan yang memiliki masa aktif yang lama, klien menggunakan kredensial pilihannya untuk mendapatkan token akses Google Cloud yang memiliki masa aktif singkat. Kemudian, klien menggunakan token ini untuk autentikasi, yang secara signifikan mengurangi risiko keamanan yang terkait dengan file kredensial statis.
mTLS: metode ini tidak bergantung pada penyedia dan cocok jika organisasi Anda sudah menggunakan Infrastruktur Kunci Publik (PKI) untuk mengelola sertifikat TLS untuk identitas layanan. Hal ini memungkinkan klien melakukan autentikasi tanpa identitas khusus Google Cloud. Namun, mirip dengan penggunaan kunci akun layanan, pendekatan ini mengharuskan Anda mengelola siklus proses dan distribusi kredensial yang aktif dalam waktu lama, seperti sertifikat klien.
SASL/PLAIN dengan kunci akun layanan: metode ini menyediakan cara langsung bagi klien eksternal untuk melakukan autentikasi sebagai identitas Google Cloud . Anda mendownload file JSON kunci akun layanan dan menggunakannya dalam konfigurasi SASL/PLAIN klien Anda. Metode ini umumnya tidak disarankan untuk beban kerja produksi karena memerlukan pengelolaan dan pengamanan kredensial statis yang aktif dalam jangka waktu lama di sisi klien.
Perbandingan fitur antara SASL dan mTLS
Mekanisme autentikasi utama untuk Managed Service for Apache Kafka adalah SASL (Simple Authentication and Security Layer), yang terintegrasi langsung dengan layanan identitasGoogle Cloud. Sebagai dasar, SASL mengautentikasi klien menggunakan akun utama IAM, seperti akun layanan. Google Cloud Untuk otorisasi, SASL memberikan fleksibilitas: Anda dapat mengelola akses ke cluster menggunakan peran IAM terperinci dan Daftar Kontrol Akses (ACL) Kafka.
Sebaliknya, mTLS menawarkan metode autentikasi independen penyedia yang tidak bergantung pada IAM. Google Cloud Sebagai gantinya, mTLS mengautentikasi klien berdasarkan sertifikat TLS-nya, dengan identitas diperoleh dari Nama Subjek sertifikat.
Perbedaan ini menyebabkan perbedaan utama dalam cara penanganan otorisasi. Tidak seperti principal SASL, principal mTLS harus diotorisasi menggunakan ACL Kafka secara eksklusif; principal ini tidak dapat dikelola dengan peran IAM Google Cloud .
Sebaiknya konfigurasi ACL Kafka untuk cluster Anda. Jika tidak ada ACL yang ditetapkan, perilaku Kafka default memberikan akses penuh ke cluster kepada semua principal yang diautentikasi—baik menggunakan SASL maupun mTLS. Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi ACL Kafka, lihat Membuat ACL Managed Service for Apache Kafka.
Managed Service for Apache Kafka mendukung autentikasi mTLS dengan sertifikat klien yang diterbitkan oleh Certificate Authority yang ditemukan di CA Service. Jika organisasi Anda menggunakan root of trust eksternal, Anda dapat mengintegrasikannya dengan membuat CA subordinat dalam Layanan CA yang terhubung ke CA eksternal Anda.
Tabel berikut membandingkan fitur metode autentikasi.
| Fitur | SASL/OAUTHBEARER | SASL/PLAIN | mTLS |
|---|---|---|---|
| Identitas utama | Google Cloud Akun Utama IAM | Google Cloud Akun Utama IAM | Nama Subjek Sertifikat |
| Jenis kredensial | Kredensial Default Aplikasi (ADC) atau token OAuth 2.0 | Kunci akun layanan berenkode Base64 | Sertifikat klien dan kunci pribadi |
| Metode otorisasi | Google Cloud Peran IAM atau ACL Kafka | Google Cloud Peran IAM atau ACL Kafka | Khusus ACL Kafka |
| Kasus penggunaan | Klien di Google Cloud; klien eksternal menggunakan Workload Identity Federation | Klien sederhana, skenario pengujian, atau sistem lama yang memerlukan penggunaan kunci akun layanan. | Agnostik terhadap penyedia; ideal untuk aplikasi PKI lokal, multi-cloud, atau yang sudah ada. |
| Konfigurasi klien | Konfigurasi JAAS dengan class handler login khusus (Java) atau server autentikasi lokal (non-Java) | Konfigurasi JAAS dengan PlainLoginModule standar (Java) | Properti keystore dan truststore (Misalnya—security.protocol=SSL) |
| Ketersediaan cluster | Semua cluster | Semua cluster | Klaster yang dibuat setelah 24 Juni 2025 |
Memilih SASL versus mTLS
Pilihan metode autentikasi Anda dipandu oleh kebijakan keamanan dan infrastruktur yang ada di organisasi Anda. Untuk sebagian besar kasus penggunaan, sebaiknya gunakan SASL dengan Google Cloud IAM.
SASL dengan Google Cloud IAM atau Workload Identity Federation memberikan pengalaman autentikasi dan otorisasi yang paling fleksibel dan terintegrasi. IAM menggunakan sistem identitas Google Cloud sebagai satu sumber tepercaya untuk mengelola izin. Pilih jalur ini jika Anda ingin:
Kelola izin secara terpusat untuk klien Kafka Anda menggunakan Google Cloud peran IAM yang sudah dikenal.
Hindari pengelolaan kredensial statis di klien.
Aktifkan klien dari cloud lain seperti AWS, Azure, atau penyedia identitas lokal seperti Okta atau ADFS untuk mengautentikasi menggunakan Workload Identity Federation. Metode ini menyediakan solusi identitas yang aman dan agnostik terhadap cloud tanpa perlu beralih ke protokol autentikasi yang berbeda.
Pilih mTLS jika organisasi Anda memiliki persyaratan ketat untuk autentikasi berbasis sertifikat. Kebutuhan ini muncul saat Anda memigrasikan deployment Kafka lokal yang sudah menggunakan sertifikat TLS untuk identitas, atau saat kebijakan perusahaan mewajibkan sertifikat klien untuk semua aplikasi. Meskipun mTLS memberikan keamanan tingkat transportasi yang kuat, ingatlah bahwa otorisasi untuk klien mTLS harus dikelola secara eksklusif dengan ACL Kafka, yang terpisah dari IAM. Google Cloud
Alur kerja untuk mengonfigurasi SASL/PLAIN atau SASL/OAUTHBEARER
Mengonfigurasi klien untuk menggunakan autentikasi SASL dengan Managed Service for Apache Kafka melibatkan pemberian izin ke identitas klien, lalu mengonfigurasi aplikasi klien berdasarkan mekanisme SASL yang dipilih. Berikut adalah ringkasan alur kerja yang diperlukan. Untuk mengetahui petunjuk mendetail tentang cara mengonfigurasi SASL, lihat Mengonfigurasi autentikasi SASL.
Berikan izin IAM. Anda harus memberikan peran Managed Kafka Client (
roles/managedkafka.client) terlebih dahulu ke akun layanan yang digunakan klien untuk autentikasi. Peran ini memberikan izinmanagedkafka.clusters.connectyang diperlukan untuk terhubung ke cluster Kafka dalam project.Konfigurasi klien Kafka. Konfigurasi klien tertentu bergantung pada apakah Anda menggunakan mekanisme SASL/OAUTHBEARER atau SASL/PLAIN.
Untuk SASL/OAUTHBEARER (direkomendasikan): mekanisme ini menggunakan Kredensial Default Aplikasi (ADC). Konfigurasi bergantung pada bahasa klien Anda:
Klien Java: tambahkan library Google Cloud autentikasi khusus ke classpath aplikasi Anda. Kemudian, konfigurasi properti klien Kafka untuk menggunakan class
GcpLoginCallbackHandleryang disediakan, yang secara otomatis menangani autentikasi menggunakan ADC.GcpLoginCallbackHandleradalah class yang digunakan dengan mekanisme autentikasi OAUTHBEARER Kafka, yang dirancang khusus untuk digunakan dengan Managed Service for Apache Kafka. Proses ini menangani proses mendapatkan Token Web JSON (JWT) dari penyedia identitas Google, sehingga memungkinkan klien Kafka melakukan autentikasi dengan layanan menggunakan ADC.Klien non-Java: jalankan server autentikasi lokal yang disediakan di mesin klien. Server ini menggunakan ADC untuk mengambil kredensial dan memberikannya ke klien Kafka. Klien kemudian dikonfigurasi untuk mendapatkan token autentikasinya dari endpoint server lokal ini.
Untuk SASL/PLAIN
Mekanisme ini menggunakan kombinasi nama pengguna dan sandi. Aplikasi klien harus dikonfigurasi untuk menggunakan protokol keamanan SASL_SSL, mekanisme PLAIN, dan konfigurasi JAAS yang menentukan class
PlainLoginModule.Nama penggunanya adalah alamat email akun layanan. Sandi dapat dibuat dengan salah satu dari dua cara berikut:
Dengan mengenkode file JSON kunci akun layanan menggunakan base64.
Dengan mendapatkan token akses berjangka pendek.
Konfigurasi otorisasi. Setelah klien berhasil melakukan autentikasi menggunakan SASL, aksesnya dikontrol oleh izin yang ditentukan dalam peran IAM atau ACL Kafka di cluster.
Batasan SASL
Metode autentikasi SASL memiliki batasan berikut:
Autentikasi SASL secara inheren terkait dengan principal IAM. Fitur ini tidak cocok untuk organisasi yang memerlukan pemisahan ketat dari identitasGoogle Cloud atau yang menggunakan identitas non-Google, kecuali jika Anda mengonfigurasi Workload Identity Federation.
SASL tidak menggunakan sertifikat klien untuk autentikasi. Fitur ini tidak cocok secara langsung untuk organisasi yang mengandalkan PKI yang ada untuk mengidentifikasi aplikasi.
Alur kerja untuk mengonfigurasi mTLS
Mengonfigurasi mTLS untuk Managed Service for Apache Kafka melibatkan konfigurasi otoritas sertifikat, cluster Kafka, dan klien Kafka Anda. Untuk petunjuk mendetail tentang cara mengonfigurasi mTLS, lihat Mengonfigurasi autentikasi mTLS.
Mengonfigurasi Otoritas Sertifikat (CA). Anda harus membuat dan mengonfigurasi kumpulan CA terlebih dahulu di Certificate Authority Service (CA Service). Jika Anda membuat kumpulan CA yang berada di project yang berbeda, pastikan untuk memberikan izin agen layanan Managed Service untuk Apache Kafka (
service-PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com) untuk mengakses kumpulan ini. Anda harus membuat sertifikat root dan subordinat di dalam kumpulan CA.Konfigurasi cluster Kafka. Buat atau update cluster Anda untuk mengaktifkan mTLS dengan memberikan ID resource kumpulan CA yang dikonfigurasi. Kami juga merekomendasikan konfigurasi properti broker
ssl.principal.mapping.rulesuntuk membuat nama entity utama yang disederhanakan untuk digunakan dalam ACL. Anda dapat melakukannya menggunakan perintah Google Cloud CLI.Konfigurasi klien Kafka. Dapatkan sertifikat klien dari CA Anda dan instal di lingkungan klien Anda, misalnya, di keystore Java. Aplikasi klien kemudian harus dikonfigurasi dengan protokol keamanan (SSL) yang benar dan lokasi keystore-nya untuk terhubung ke port bootstrap mTLS khusus cluster, yaitu
9192.Pantau mTLS. Setelah penyiapan, pantau metrik
managedkafka.googleapis.com/mtls_truststore_update_countuntuk memverifikasi bahwa cluster berhasil memperbarui sertifikat CA dari kumpulan Layanan CA, yang diupayakan secara berkala. Anda juga dapat menggunakan Cloud Logging.
Batasan mTLS
Fitur mTLS memiliki batasan berikut:
Anda hanya dapat menggunakan fitur mTLS di cluster Managed Service for Apache Kafka yang dibuat setelah 24 Juni 2025.
Anda harus mengonfigurasi otorisasi untuk principal mTLS menggunakan ACL Kafka. Anda tidak dapat menggunakan binding peran IAM untuk mengizinkan klien mTLS.
Layanan ini hanya mengautentikasi klien yang memberikan sertifikat yang dikelola oleh Layanan CA. Namun, Anda dapat mengintegrasikan root of trust eksternal dengan membuat CA subordinat dalam Layanan CA yang terhubung ke CA eksternal Anda.
Anda dapat mengonfigurasi cluster untuk mempercayai maksimal 10 kumpulan CA.