Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Mengkonfigurasi metode otentikasi cluster Amazon MSK di Lambda
Lambda memerlukan izin untuk mengakses cluster Amazon MSK Anda, mengambil catatan, dan melakukan tugas lainnya. Amazon MSK mendukung beberapa cara untuk mengotentikasi dengan cluster MSK Anda.
Metode otentikasi cluster
Akses yang tidak diautentikasi
Jika tidak ada klien yang mengakses cluster melalui internet, Anda dapat menggunakan akses yang tidak diautentikasi.
SASL/SCRAM otentikasi
Lambda mendukung otentikasi Sim ple Authentication dan Security Layer/Salted Challenge Response SASL/SCRAM Authen tication Mechanism (), dengan fungsi SHA-512 hash dan enkripsi Transport Layer Security (TLS). Agar Lambda terhubung ke cluster, simpan kredentif otentikasi (nama pengguna dan kata sandi) dalam rahasia Manajer Rahasia, dan referensi rahasia ini saat mengonfigurasi pemetaan sumber acara Anda.
Untuk informasi selengkapnya tentang menggunakan Secrets Manager, lihat autenti Sign-in kasi kredenSIAL dengan Secrets Manager di Panduan Pengembang Amazon Managed Streaming untuk Apache Kafka.
catatan
Amazon MSK tidak mendukung SASL/PLAIN otentikasi.
Autentikasi TLS bersama
Mutual TLS (MTLS) menyediakan otentikasi dua arah antara klien dan server. Klien mengirimkan sertifikat ke server agar server memverifikasi klien. Server juga mengirimkan sertifikat ke klien untuk klien untuk memverifikasi server.
Untuk integrasi Amazon MSK dengan Lambda, cluster MSK Anda bertindak sebagai server, dan Lambda bertindak sebagai klien.
-
Agar Lambda dapat memverifikasi cluster MSK Anda, Anda mengonfigurasi sertifikat klien sebagai rahasia di Secrets Manager, dan mereferensikan sertifikat ini dalam konfigurasi pemetaan sumber acara Anda. Sertifikat klien harus ditandatangani oleh otoritas sertifikat (CA) di penyimpanan kepercayaan server.
-
Cluster MSK juga mengirimkan sertifikat server ke Lambda. Sertifikat server harus ditandatangani oleh otoritas sertifikat (CA) di AWS penyimpanan kepercayaan.
Amazon MSK tidak mendukung sertifikat server yang ditandatangani sendiri. Semua broker di Amazon MSK menggunakan sertifikat publik yang ditandatangani oleh CA Amazon Trust Services
Rahasia CLIENT_CERTIFICATE_TLS_AUTH memerlukan bidang sertifikat dan bidang kunci pribadi. Untuk kunci pribadi terenkripsi, rahasia memerlukan kata sandi kunci pribadi. Sertifikat dan kunci pribadi harus dalam format PEM.
catatan
Lambda mendukung algoritma enkripsi kunci pribadi PBES1
Bidang sertifikat harus berisi daftar sertifikat, dimulai dengan sertifikat klien, diikuti oleh sertifikat perantara, dan diakhiri dengan sertifikat root. Setiap sertifikat harus dimulai pada baris baru dengan struktur berikut:
-----BEGIN CERTIFICATE----- <certificate contents> -----END CERTIFICATE-----
Secrets Manager mendukung rahasia hingga 65.536 byte, yang merupakan ruang yang cukup untuk rantai sertifikat yang panjang.
Kunci pribadi harus dalam format
-----BEGIN PRIVATE KEY----- <private key contents> -----END PRIVATE KEY-----
Untuk kunci pribadi terenkripsi, gunakan struktur berikut:
-----BEGIN ENCRYPTED PRIVATE KEY----- <private key contents> -----END ENCRYPTED PRIVATE KEY-----
Contoh berikut menunjukkan isi rahasia untuk otentikasi MTL menggunakan kunci pribadi terenkripsi. Untuk kunci pribadi terenkripsi, Anda menyertakan kata sandi kunci pribadi di rahasia.
{ "privateKeyPassword": "testpassword", "certificate": "-----BEGIN CERTIFICATE----- MIIE5DCCAsygAwIBAgIRAPJdwaFaNRrytHBto0j5BA0wDQYJKoZIhvcNAQELBQAw ... j0Lh4/+1HfgyE2KlmII36dg4IMzNjAFEBZiCRoPimO40s1cRqtFHXoal0QQbIlxk cmUuiAii9R0= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIFgjCCA2qgAwIBAgIQdjNZd6uFf9hbNC5RdfmHrzANBgkqhkiG9w0BAQsFADBb ... rQoiowbbk5wXCheYSANQIfTZ6weQTgiCHCCbuuMKNVS95FkXm0vqVD/YpXKwA/no c8PH3PSoAaRwMMgOSA2ALJvbRz8mpg== -----END CERTIFICATE-----", "privateKey": "-----BEGIN ENCRYPTED PRIVATE KEY----- MIIFKzBVBgkqhkiG9w0BBQ0wSDAnBgkqhkiG9w0BBQwwGgQUiAFcK5hT/X7Kjmgp ... QrSekqF+kWzmB6nAfSzgO9IaoAaytLvNgGTckWeUkWn/V0Ck+LdGUXzAC4RxZnoQ zp2mwJn2NYB7AZ7+imp0azDZb+8YG2aUCiyqb6PnnA== -----END ENCRYPTED PRIVATE KEY-----" }
Untuk informasi selengkapnya tentang MTL untuk Amazon MSK, dan petunjuk tentang cara membuat sertifikat klien, lihat Otentikasi klien TLS bersama untuk Amazon MSK di Panduan Pengembang Amazon Managed Streaming untuk Apache Kafka.
Autentikasi IAM
Anda dapat menggunakan AWS Identity and Access Management (IAM) untuk mengotentikasi identitas klien yang terhubung ke cluster MSK. Dengan autentikasi IAM, Lambda bergantung pada izin dalam peran eksekusi fungsi Anda untuk terhubung ke cluster, mengambil catatan, dan melakukan tindakan lain yang diperlukan. Untuk kebijakan sampel yang berisi izin yang diperlukan, lihat Membuat kebijakan otorisasi untuk peran IAM di Panduan Pengembang Amazon Managed Streaming untuk Apache Kafka.
Jika autentikasi IAM aktif di cluster MSK Anda, dan Anda tidak memberikan rahasia, Lambda secara otomatis akan menggunakan autentikasi IAM secara default.
Untuk informasi selengkapnya tentang otentikasi IAM di Amazon MSK, lihat Kontrol akses IAM.
Bagaimana Lambda memilih broker bootstrap
Lambda memilih broker bootstrap berdasarkan metode otentikasi yang tersedia di cluster Anda, dan apakah Anda memberikan rahasia untuk otentikasi. Jika Anda memberikan rahasia untuk MTL atau SASL/SCRAM, Lambda secara otomatis memilih metode autentikasi tersebut. Jika Anda tidak memberikan rahasia, Lambda memilih metode autentikasi terkuat yang aktif di cluster Anda. Berikut ini adalah urutan prioritas di mana Lambda memilih broker, dari auth terkuat hingga terlemah:
MTL (rahasia disediakan untuk MTL)
SASL/SCRAM (rahasia disediakan untuk SASL/SCRAM)
SASL IAM (tidak ada rahasia yang disediakan, dan autentikasi IAM aktif)
TLS tidak diautentikasi (tidak ada rahasia yang disediakan, dan autentikasi IAM tidak aktif)
Plainteks (tidak ada rahasia yang disediakan, dan autentikasi IAM dan TLS yang tidak diautentikasi tidak aktif)
catatan
Jika Lambda tidak dapat terhubung ke jenis broker yang paling aman, Lambda tidak mencoba untuk terhubung ke jenis broker yang berbeda (lebih lemah). Jika Anda ingin Lambda memilih jenis broker yang lebih lemah, nonaktifkan semua metode autentikasi yang lebih kuat di cluster Anda.
